151–160 of 245 posts
Earlier quoted context omitted.
https://lkml.org/lkml/2017/12/27/2 It makes reference to the nature of the bug and explains why AMD's chips are not affected (from an AMD engineer).
I was making reference to this [1]. The original fix had a comment that literally said, "/* Assume for now that ALL x86 CPUs are insecure */" They've since added a check to exclude AMD processors. [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip...
This is probably one of the poorest and most defensive PR pieces I've read from a company in a long time, and it does not really make me sympathetic to them at all. > Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operat…
Intel should now recall the affected CPUs and ship new fixed CPUs without Intel "ME" for Management Engine, another well known open flaw. In the end, hardware and software devs in the 1970s were right. Operating systems like MULTICS and computers like PDP-11 got it right. MULTICS supported 16 rings and has many advanced features that almost everyone forgot and never implemented in newer OS - shame on all of us! Intel…
You think they have the tooling to manufacture drop-in replacements for up to decade old CPUs, even if they wanted to?
Earlier quoted context omitted.
Would not be the first time vendor X knows vendor Y is vulnerable even as vendor Y denies it.
Now my interest is piqued: what instances of `vendor X` and `vendor Y` do you know of?
I think that's sort of a pattern. Vendor X is affected by a POC, so they fix the issue. They then develop more tests. Vendor Y concludes they are not affected, perhaps based on a false negative test, and fails to investigate further. Now X understands more about the true scope of the problem than Y and they have tests to demonstrate on Y, but Y does not.
Earlier quoted context omitted.
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 f…
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.
Earlier quoted context omitted.
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 f…
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.
But, I mean: that's what that dude is doing in that tweet, is all I'm saying. :)
Earlier quoted context omitted.
“Workload dependent” clearly implies (despite the spin they are trying to put on it) that some users will be worse off than others. What isn’t my at all clear (to me) is what they mean by ”will be mitigated over time”. Are they implying that when we buy new professors (from them) there’ll be a hardware fix that won’t require the performance-sapping patch? Quoting ARM and AMD is really a bit pathetic too, IMHO, especi…
> Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw. The official fix for this in the Linux kernel has a comment that literally says to assume all x86 processors suffer from the same issue and will disable KPTI for all x86 processors, including AMD. There's an AMD-specific patch that I saw floating around that keeps the setting enabled for AMD pro…
Not yet on the mainline AFAIK, but I'd guess that whole branch will be merged soon (before the next release candidate).
Earlier quoted context omitted.
“Workload dependent” clearly implies (despite the spin they are trying to put on it) that some users will be worse off than others. What isn’t my at all clear (to me) is what they mean by ”will be mitigated over time”. Are they implying that when we buy new professors (from them) there’ll be a hardware fix that won’t require the performance-sapping patch? Quoting ARM and AMD is really a bit pathetic too, IMHO, especi…
Process Context ID for TLB entries to make the flipping efficient - if results in constant time failures, will solve the perf issue. PCID is in Intels since Westmere.
So Intel might make out OK on this, since people will have to update their servers, and right now there are many more x86 server hardware choices which use Intel chips. The truly scary thing from Intel's perspective is if people decide to use this as an opportunity to move to AMD, or worse for them, completely outside the x86 ecosystem, to ARM64 or PPC64LE systems. I have heard accusations that Intel has strong-armed motherboard manufacturers so there are't that many choices for those other platforms --- at least so far. But of course, everything can change over time.
Intel thinks this will need firmware and operating system updates to fully mitigate.
[1] https://www.intc.com/investor-relations/investor-education-a...
Earlier quoted context omitted.
> Hearing echos of Intel's early FDIV response along the lines of "the average computer user doesn't need perfectly accurate division"... Has to be pointed out that they were correct. Public outrage forced them to change their tune, but their original summary was still on point. That said, it of course could majorly impact a select few.
Quite possibly, but it still a bad omen for Intel. This sounds a lot worse than a slightly off division.
It actually doesn't even sound comparable to me, let alone worse. A wrong division is an operation producing incorrect results contrary to the specifications, plain and simple. What we have is a CPU producing correct results, and simply refusing to provide a guarantee about caching or timing. In particular it makes no guarantee that caching or timing behavior is data-independent. So it's not exactly hard to argue that it is not malfunctioning at all, and that people were (rightly or wrongly) simply assuming more about the CPUs than they were guaranteed.
Mind you, I don't like the bug any more than you do, and I would obviously like this to get fixed too. But it seems pretty hard to compare this with the division bug.
Do we know the actual bug yet? I sort of assumed it was a timing attack on KASLR rather than a leak of traditional kernel data. Although I guess that there would have been cheaper mitigations like mapping an empty page to all of the other KASLR slots rather than doing a full world switch in that case...