Yes, that's exactly my point. Your point that KASLR isn't relevant in a lot of situations only reinforces how much more serious the Intel bug is compared to the DrK-like attacks on KASLR.
Then why did you say:
the only FEASIBLE direct attack on KASLR (and the one which promoted the KAISER work to be initiated) requires an Intel processor with TSX.
This is not even remotely true.
Let's get back to basics:
The randomization is just an attempt to hide the map
: For a spy, it doesn't get you over the border or tell you where the enemy actually is. But, of course, to a spy, a map is incredibly useful
: should you manage to get across the border
, would you rather randomly choose coordinates and potentially wander around deserts, swamps or tundra, or would you like to have a list of interesting places like military bases, air strips, and transportation hubs to visit?
The first problem we have in regards to randomization, the map
, is that every time we shuffle our troops around or change our infrastructure (i.e. develop the kernel and release new versions), we leave clues that enemy can discover to figure out that map. We keep hoping that we'll stop leaving obvious clues, but we're not so good at that.
The second problem is that, inherent to topographical landscape of our country, the enemy can hear the echos of what we do through a variety of means and deduce the map that way (i.e. hardware side-channels). That's stupendous expensive to modify (we have change the valleys & mountains), will take a lot of time (can't move that much earth overnight) and we're not entirely sure what configurations of land features will prevent the hearing of those echoes, we just know about some rather obvious ones. In fact, it's likely that different configurations would impose productivity & transportation delays: It seems that easiest way to stop echoes means putting mountains & rivers in inconvenient places (i.e. the clearest way to stop covert-channels into speculative activity is to not fully do that speculation
--since execution, however spurious, has a cost, it is almost certainly being done [and thus potentially detectable] because stopping it has even greater
power/performance implications. This is not trivial.)
The new problem is that now they've got a spy satellite that can stream video in real-time: They don't just see the map however we change it, but they also see everything on it. They know where all our planes, troops and ships are. Our only hope is to build an gigantic box around our country, which won't just hide the map, but everything on it. That's just, you know, really inconvenient.
This was all known. And it's not just the TSX attack you alluded to in the previous post (which is the DrK thing you specify now, right?), it's a bunch of things
: The Introduction in the KAISER paper lists *THREE* different *HARDWARE ATTACKS* (among other things) that reveal address information, and since they are hardware, the jig's up chaps. I mean, it wasn't looking good before
, but at least we could put our thumb in the dyke and hum really loud.
Anyway, yes, "the Intel bug" is indeed much, much more serious, as you say now, but what you were saying before completely confused me because it's entirely not true. The situations are all-related too, because once people start coming out the woodwork with multiple methods to leak info about addresses in kernel-space via these kinds of micro-architecture side-channel detections, people were openly saying stuff like "It's good that I couldn't manage to actually read kernel memory BUT you know, I got kinda close?
I mean, this happened fast:
I first remember people airing about this possibility vaguely like a year ago, probably not even two.
I'm not sure what part you consider muddled, since you apparently understood everything. I merely attempted to point out that there are two different issues at work and that the KAISER/KPTI patches "just happen" to address the bug. It is, as you point out, a rather nuclear option, though.
If what is embargoed is an eminently practicable arbitrary read of any kernel address, as it increasingly appears to be, this didn't just *happen* to address this situation with the Intel micro-architecture--it is the only solution to it.
My point was that KAISER (which, again, is SIMPLY A PRACTICALLY-MINDED IMPLEMENTATION of a PRE-EXISTING EXTREME IDEA)was in the works, and that spender of grsecurity (to my knowledge) first suggested it *TEN YEARS AGO* because it was clear where this was going: We're gonna have to unmap kernel space dudes.
KAISER isn't the idea, it's just an idea about how to make that idea hurt less because we're gonna have to do it now
. It's simply a method of doing something known to be very bad less badly because we're run out of other options.
It's not *new*, and it's not happenstance or whatever: I've talked this kind of problem HERE ten years ago myself:viewtopic.php?p=607096#p607096
That has nothing to do with the fact x86 doesn't have enough registers, there isn't an ASID for TLB entries, poor virtualization compliance etc...
If the kernel had a different virtual address space that would mean that we'd have to do one of those TLB-flushing context switches each and every time you did a syscall. It would murder performance. This is why Windows XP (and linux, and Mac OS etc...) does a mode transition for syscalls instead of a context switch. You only switch between VASes when you switch between processes! It's the only sane way to code an OS on x86.
The reason I felt this distinction was worth pointing out, is that a lot of people are confusing the two issues to the point where one of the authors of the Black Hat DrK paper came out and said the bug was old news (as in covered in their 2016 paper). Now, I've read the original paper (available here) and the Black Hat talk (slides here) just covered the same.
Well, let's be clear then, clearer than you are because you're saying this is two bugs: the DrK one and the new, more serious, embargoed one.
But it isn't two bugs, it's an entire class of bugs. It's like a new field of bug:
It isn't just that we can use TSX to infoleak address information and defeat randomization (the map), because there are techniques using double page-faulting and prefetching too that were demonstrated to potentially disclose address information. So it was already open season in the tall grass, the only question was how many ducks were in there.
It turns out, since this embargo is almost certainly about an arbitrary read, that the mother of all ducks was in there too (real-time, country-wide video satellite). Oh, and there's probably more than just one or there are multiple ways to catch it.
So we gots to drop the bomb on it. Only way to be sure.