271–280 of 378 posts
It's worth noting that the FSF consider that supporting microcode updates makes software "un-free". This is a great example of what an inordinately stupid and harmful position that is.
Earlier quoted context omitted.
SMT is relevant in the VM case of this bug because it determines whether this bug is restricted to data outside the VM or not. Providers usually won't disable SMT completely, they'd run a scheduler which only allows 1 VM to use both SMT threads of a core. Ultra cheap VPS providers may still find that not worth the pennies though as if you sell a majority of single core VPS then the majority of your SMT threads are st…
> Fully dedicated cores aren't necessarily required because in the timesliced case the registers are unloaded and reloaded when different VMs are shuffled on and off the core. That said, they definitely prevent the cross-vm-data-leak case of this bug. Registers are unloaded and reloaded when different processes / threads are scheduled within a running VM too. That should protect the register contents, but because of…
On the other hand, "context switching" for VMs is done via hardware commands like VMSAVE/VMLOAD or VMWRITE/VMREAD which do save/load the entire guest register context, including the hidden context not accessible by software which this CVE is relying on. Not that it isn't impossible for this to be broken as well, but it's a completely different procedure and one the hardware is actually responsible for completely clearing instead of "supposed to be reset by software".
So while the CVE still affects processes inside of VMs the loading/unloading behavior inter VM should actually behave as a working sandbox and protect against cross-VM leaks, barring the note by lieg on SMT still possibly being a problem (I don't know enough about how the hardware maintains the register table between SMT threads of different VMs to say for sure but I'm willing to guess it's still vulnerable on register remappings).
There may well be other reasons I'm completely mistaken here but they'd have to explain why the inter-VM context restore is broken not why it works for inter-process restore. The article already explains why the latter happens, but it doesn't make a claim about the former.
One thing I don't get though, if amd64 is affected, shouldn't the complementary instructions in X64/intel also be affected? Does intel move around RAT referenced values instead of just setting/unsetting the z-bit?
Earlier quoted context omitted.
Looking at the IBM's tech from the sixties is somehow weirdly depressing: it's unbelievable how much of the architectural stuff they've invented already by the 1970.
I remember seeing VMware for the first time and thinking that the PC world had finally entered the 1970s.
Earlier quoted context omitted.
It's funny that it's "always" mentioned, yet it's not familiar to me. Also curious the Wikipedia article for CPU design doesn't mention it, since it's "always" referenced. Just because something is familiar to you, or even large swaths of a given population, doesn't mean everyone should be expected to know it. I love learning new things. I love discovering topics I know nothing about, and I love picking the brains of…
> It's funny that it's "always" mentioned, yet it's not familiar to me. Also curious the Wikipedia article for CPU design doesn't mention it, since it's "always" referenced. you're not going to convince others that microcode is some kind of foreign concept to CPUs just because you yourself were unfamiliar. Yes, it can be a downer to discover that you're more naive in a subject than you had previously thought you were…
> At this point in history I think that if someone wants to consider themselves to be well-versed or knowledgeable about consumer CPUs then learning about microcode is a hard requirement.
This statement strikes me as hyperbolic. A CPU/hardware engineer, or even security-conscious software engineer, sure. But I can't understand why there is a reason for a consumer to care.
Earlier quoted context omitted.
I remember seeing VMware for the first time and thinking that the PC world had finally entered the 1970s.
Close, but not quite -- you can't nest the VMs the way you can on "big iron"
Earlier quoted context omitted.
Pinning doesn’t help either, since there will always be more threads than cores. Scheduling all those threads and even blocking on IO will cause context switches.
I do not know how that is done in Windows, but in Linux it is possible to reserve some cores to be used only for the threads that you assign to them and for no other threads. This is done frequently for high-performance applications.
Earlier quoted context omitted.
How do you build the POC? I get "No such file or directory" and error 127 on Ubuntu.
I had to run make on the uncompressed folder. Perhaps the build-essential package doesn't come with NASM in Ubuntu? I'll need a bit more info on the error if you want me to try and help you :)
Earlier quoted context omitted.
This is because VM means two different things and has for a long time: IBM's VM was and is a hypervisor. It dates to the mid 1960s, in the form of CP-40, and it didn't run opcodes in software, but in hardware. https://en.wikipedia.org/wiki/IBM_CP-40 p-code machines, which interpret bytecode, date back almost as far, such as the O-code machine for BCPL. https://en.wikipedia.org/wiki/BCPL Getting people to distinguish…
> Getting people to distinguish between these concepts is probably a lost cause. I think people here of all places should distinguish between these concepts. There are big performance and security implications of the two approaches.
This is super cool. This exploit will be one of the canonical examples that just running something in a VM does not mean it's safe. We've always known about VM breakout, but this is a no-breakout massive exploit that is simple to execute and gives big payoffs. Remember: just because this one bug gets fixed in microcode doesn't mean there's not another one of these waiting to be discovered. Many (most?) 0-days are kno…
Running untrusted code whether in a sandbox, container, or VM, has not been safe since at least Rowhammer, maybe before. I believe a lot of these exploits are down to software and hardware people not talking. Software people make assumptions about the isolation guarantees, hardware people don't speak up when said assumptions are made.