311–320 of 378 posts
Earlier quoted context omitted.
> AMD unexpectedly publish patches, earlier than an agreed embargo date. > As the fix is now public, we propose privately notifying major distributions that they should begin preparing updated firmware packages. AMD had to drop the ball somewhere didn't it.
It's good that they published patches early, isn't it?
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.
Isn’t the typical solution here to pin each VM to certain CPUs / cores?
Earlier quoted context omitted.
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.
IMO, it’s only a special case for commercial support reasons. Almost every engineer, QE, consultant, solution architect I know runs or has run nested virtualization for one reason or another.
Earlier quoted context omitted.
I see no need for it. Living in Germany, any kind of power outages are exceptionally rare. I remember one in the last 10 years for a few hours and that was very local. If I am in a situation where a power outage occurs, i'll listen to my battery radio for a while and be fine. I work on nothing and rely on nothing that would actually require a UPS.
It's like not having a backup drive. Everything is fine until one day it isn't. A good UPS does more than just protect from outages. It also protects from surges and low-voltage situations that can both damage the equipment severely. A UPS doesn't cost much and will last many years. Buying a new motherboard and GPU because they got fried is much more expensive.
The substation is mandated to trip in that anomaly, btw. Otherwise some very common types of motors (AC induction, single and 3-phase) would burn from the excessive current they draw to compensate for the reduced voltage.
Earlier quoted context omitted.
I'm pretty sure AWS/Azure/GCP don’t assign separate boxes to every customer, and somehow they’re fine.
Not sure if they're actually fine, some researchers have exploited this vulnerability on AWS instances that use affected EPYC CPUs: https://twitter.com/0xdabbad00/status/1683581484337348608
Leaks between different EC2 instances would be far more serious, but I suppose that wouldn't happen unless two tenants / EC2 instances shared SMT cores, or the contents of the microarchitectural register file was persisted across VM context switches in an exploitable manner.
Earlier quoted context omitted.
The big switch statement wouldn't necessarily protect you either.
Why do comments like this just make a bold claim and then wander off as if the claim stands for itself? No explanation. No insight. I mean why should we just take your word for it? 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.
does it require physical access to the machine?
I was able to reproduce the vulnerability using javascript on a webpage. Therefore, no.
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…
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.