That's a tweet of someone using the bug to defeat KASLR.

I'm fairly sure he's actually reading from the syscall table. He already defeated KASLR when he typed /proc/kallsyms.

That aside, I don't think KASLR would be important enough to rush KPTI like it has happened now and to even enable it by default, given its drawbacks.

Sorry, I'm being imprecise. Yes, they're reading from kernel memory. But the specific thing they're reading is useful as a KASLR bypass.

I think I understand that the subtext of this thread is: can you only bypass KASLR with it, or can you read pretty much anything from kernel memory? And yeah: it sure seems like you can work out arbitrary kernel values; it's hard to think of a way this bug could work where you can figure out the symbols of specific kernel functions, but not arbitrary values in the kernel.

If you know the specific kernel being used, all you have to figure out is the base address of the kernel to have to whole layout to break KASLR.

So if it had been a timing attack where an unmapped memory reference takes longer to fail than a memory reference with the wrong permissions, then you could scan all of the KASLR slots without actually reading back any data.

Actually reading data is a waaaaayyy bigger deal.

Yeah, that's true. I hadn't considered that the fragility of KASLR meant that there are lots of vectors for breaking it that don't require a huge chip break. Sorry, I'm making the thread dumber.

But, I mean: that's what that dude is doing in that tweet, is all I'm saying. :)

By reading from the actual memory address, yes. Defeating kASLR with side channels is meh. Reading from actual addresses is a different matter entirely.

It looks like he's reading actual data from kernel space.