
The current state of kernel page-table isolation - jsnell
https://lwn.net/SubscriberLink/741878/eb6c9d3913d7cb2b/
======
justincormack
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.

~~~
Pyxl101
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.

~~~
0xcde4c3db
> 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...](https://en.wikipedia.org/wiki/Stack_buffer_overflow#Exploiting_stack_buffer_overflows)

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

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

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

~~~
Pyxl101
Thanks. That was a very helpful explanation!

------
madez
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).

~~~
jabl
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.

~~~
jabl
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...](https://groups.google.com/a/groups.riscv.org/d/msg/isa-
dev/JU0M_vug4R0/YELX92fIBwAJ)

------
stevemk14ebr
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.

~~~
ithkuil
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.

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

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

