The current state of kernel page-table isolation | Hacker News Reader

The current state of kernel page-table isolation

lwn.net

81 pointsjsnell13 comments

TLDR "all existing x86 processors are seemingly affected by information-disclosure vulnerabilities" plus arm64 too. This appears to be severe enough for Linus to accept a 5% slowdown in user code (which in previous security cases he would not have), although future processors may have this disabled again.

Why is mere information disclosure about kernel layout severe enough to warrant a slowdown and patch like this? I suppose it's gated behind a feature flag? I'm wondering because I thought just knowing the layout isn't enough to attack the kernel. Don't you need other vulnerabilities too, that let you actually access the memory?

Address randomization is nice, but if an attacker can write to arbitrary pages, potentially including the kernel, isn't it game over no matter what? I'm not an expert on this and would be interested to know more.

Also, do these activities imply that there may be significant known but embargoed vulnerabilities? In particular, Linux accepting a patch like this so late into the release cycle.

The patch itself is only going into 4.16, these are just preconditions. But yes it is all rather odd.

I’d suppose there’s at least rowhammer to worry about.

> I'm wondering because I thought just knowing the layout isn't enough to attack the kernel. Don't you need other vulnerabilities too, that let you actually access the memory?

NB: My understanding of this is purely arm's-length. I've never actually done exploit development.

Short version: you need to know the layout of the code in order to actually exploit those other vulnerabilities.

Longer version:

Attackers: We can inject machine code into the stack and execute it [1].

Developers: Not anymore; stack pages aren't executable [2].

Attackers: We can turn your own code against you by manipulating the stack to "return" to an arbitrary sequence of pre-existing functions with arguments of our choosing [3].

Developers: Not anymore; we randomize the address space every time we load the code, so now you don't know where those functions are. You could guess, but you're going to be wrong and just crash the system almost all of the time [4].

Attackers: For the kernel on x86/amd64 systems, we have a way of reading the page table from an exploited user process, which we can then parse to discover where you located those functions. <---- you are here

[1] https://en.wikipedia.org/wiki/Stack_buffer_overflow#Exploiti...

[2] https://en.wikipedia.org/wiki/NX_bit

[3] https://en.wikipedia.org/wiki/Return-oriented_programming

[4] https://en.wikipedia.org/wiki/Address_space_layout_randomiza...

Thanks. That was a very helpful explanation!

I wonder what else is in x86/arm64/common processors we don't know but would care about.

In situations like these it really pays of to have at least some parts of the system developed as free software. In a dystopian alternative reality where free software never happenend, people would hardly ever hear about these issues, even though issues like these would still be there, and maybe even worse.

Waiting for affordable open/free hardware single board computers like for example lowRISC is aiming to offer is becoming harder and harder. I'm already sitting on my hands (and pocket).

Speaking of lowRISC, does RISC-V also suffer from this? Apparently SPARC and s390 are immune, since they already have separated user and kernel address spaces, maybe somehow enforced at the ISA level.

Having the benefit of hindsight, I hope they have avoided this issue.

Replying to myself, it seems they haven't avoided it, and here is a recent proposal to fix it: https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/J...

I'd like to hear more about the processor bugs in question. Are these purposefully introduced flaws? If the bug(s) in question extend across all x86 processors that begs the question, was it intentional. Why would the flaw have not been fixed in subsequent generations.

Well this can happen when you keep a very old architecture for a long time and only add new features while keeping backwards compatibility forever. Even then switch to 64-bit involved several missed opportunities to clean things up properly.

It would be interesting to know whether any Itanium processors ever suffered from these (now disclosed) bugs.

Waiting for spender to show up and break it :-)

Reply on news.ycombinator.com