301–310 of 378 posts
Earlier quoted context omitted.
It's good that they published patches early, isn't it?
Yes. It was unexpected, but good. Not a complaint.
Not that I think it's realistic to develop an exploit and gain real value in three days, but theoretically, if all parties had taken more than three days to distribute and apply the patches?
Earlier quoted context omitted.
Yup! I worked at a few companies that would co-mingle Internet facing/DMZ VMs with internal VMs. When pointing this out and recommending we should airgap these VMs to it's own dedicated hypervisor it always fell on deaf ears. Jokes on them I guess.
I'm pretty sure AWS/Azure/GCP don’t assign separate boxes to every customer, and somehow they’re fine.
Earlier quoted context omitted.
I'm pretty sure AWS/Azure/GCP don’t assign separate boxes to every customer, and somehow they’re fine.
Yes but the Firecracker VMs are pinned to specific cores. So no two tenants never share a CPU core. Other than Rowhammer, has there been a hardware vulnerability of this nature that has worked x-core? I don't recall. Still, I think that if your company is handling user data it's worth seriously considering dedicated instances for any service that encounters plaintext user information.
Earlier quoted context omitted.
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.
https://en.wikipedia.org/wiki/Pigeonhole_principle
Earlier quoted context omitted.
The problem is, VMs aren't really "Virtual Machines" anymore. You're not parsing opcodes in a big switch statement, you're running instructions on the actual CPU, with a few hardware flags that the CPU says will guarantee no data or instruction overlap. It promises! But that's a hard promise to make in reality.
The big switch statement wouldn't necessarily protect you either.
I'd like to be educated here why a big switch statement wouldn't necessarily protect us from these CPU vulnerabilities? Anyone willing to help?
Earlier quoted context omitted.
In certain cases isolation and simplicity overlap, I suspect for example that the dangers of SMT implementation complexity are part of why Apple didn't implement it for their respective CPUs. Likely we'll see this elsewhere too, for example Amazon may not ever push to have SMT in their Graviton chips (the early generations are off the shelf cores from ARM where they didn't have a readily available choice).
Eh, as long as you assign both hyper-threads to the same tenant, and schedule them at the same time, you should be fine.
The blog post discusses the discovery of a vulnerability called "Zenbleed" in certain AMD Zen 2 processors. It revolves around the use of AVX2 and the vzeroupper instruction, which zeroes upper bits in vector registers (YMM) to avoid dependencies and stalls during superscalar execution.
The vulnerability arises from a misprediction involving vzeroupper, which can be exploited with precise scheduling and triggering the XMM Register Merge Optimization, leading to a use-after-free-like situation. This allows attackers to monitor operations using vector registers, potentially leaking sensitive information like encryption keys and passwords.
The author found the bug through fuzzing and developed a new approach called Oracle Serialization to detect CPU execution errors during testing. The vulnerability (CVE-2023-20593) affects various AMD Zen 2 processors, but AMD released a microcode update to address the issue. For systems unable to apply the update, a software workaround exists by setting the DE_CFG[9] "chicken bit."
The post concludes with acknowledgments to individuals who contributed to the discovery and analysis of the Zenbleed vulnerability.
Earlier quoted context omitted.
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.
https://en.wikipedia.org/wiki/Pigeonhole_principle
In Linux it's possible to stipulate that, for instance, core 7 can only be used by super secret process PID 1234. If you have 400 other threads, that means the other threads will have to compete for cores 0-6. And if super secret PID 1234 is idle and there are 12 threads that are marked for scheduling, then they get to just wait for cores 0-6 to become available while core 7 stands idle.
I watched a talk several years ago about a HFT firm that ... abused? this principle. They had a big ass monster of a machine. Four sockets, four CPUs with gobs of cores and gobs of cache on each one. But the only thing they cared about was the latency on their HFT trade sniping process. If they could reduce the latency of receiving interesting information to executing a trade on that interesting information from (making up numbers) 1.1ms to 0.9ms, that was potentially thousands, millions of dollars in profit.
So if CPU socket 0 has cores 0-15, CPU socket 1 has cores 16-31, CPU socket 2 has cores 32-47, CPU socket 3 has cores 48-63, they marked cores 17-31,33-47,49-63 to be usable by nothing. Those cores are permanently and forever idle. They will never execute a single instruction. Ever. Core 16 can be used by PID 12345 and only by PID 12345, core 32 can be used by PID 7362 and only PID 7362, and core 48 can be used by PID 8765 and only PID 8765. This ensured that all data and all instructions used by their super high priority HFT process can never, ever be evicted from the cache.
Apparently it made a notable improvement in latency and therefore profit.
Earlier quoted context omitted.
I know Nested Virtualisation is a thing on both KVM and hyper-v, what is different about what you could do on "big iron"
A VM nest in "big iron" isn't a special case. It's a context push with comparatively exhaustively defined costs, side effects, and implications.