https://www.amd.com/en/resources/product-security/bulletin/a... According to AMD's security bulletin, firmware updates for non-EPYC CPUs won't be released until the end of the year. What should users do until then, disable the chicken bit and take the performance hit?
Are they out of their mind? This is not a "medium".
Under what circumstances is this not a medium? The only case this applies is if you have public runners running completely untrusted code, and if you're doing that I hope you're doing it on EPYC, which is fixed. And if you're doing that, you're probably mining crypto for randoms.
VMs were and always have been a sort of faked out security blanket. The reality is there's shared hardware, shared memory, shared network interfaces, shared storage.
That and these days you can run so much on a single machine its really hard to understand the thinking that colo isn't and wasn't the best option. AWS isn't some mythical devops dream that never fails. It's a highly convoluted (in price as well as function) affair.
I read the article and I really liked that the author tried to make it seem as simple as possible that you don't need a degree or a deep understanding of how CPUs work to understand the issue. However, one thing that bothers me is that the author claims it's possible to retrieve private keys or root passwords by triggering a faulty revert from the instruction that resets the upper bits of a register. Where is the dem…
The only way would be to let the thing run and say, pipe the output to grep looking for your password or something else you're looking for. SIMD instructions are used very often for parsing text so I wouldn't be surprised if sensitive passwords eventually get loaded into an YMM register and the exploit just so happened to dump that.
If POST takes a long time it’s often memory training, backing off on the timings just slightly might make it go a lot quicker. Bios updates also often twiddle knobs in this area.
Doesn't that only happen on the first boot with new memory? As well, I thought it was more of a concern on AMD, and less on Intel. (Z690 is Intel)
Memory training can happen if the CPU detects that current timings don't work at boot. Since GP never shuts down, it's possible that his memory is always hot and performs better on a reboot (when setting new timings) than after a cold boot (this is basically always true since ram chips like to be hot but especially relevant here). If GP is using XMP or has custom timings, I'd suggest easing off on them especially considering the novelty of DDR5.
Isn’t the typical solution here to pin each VM to certain CPUs / cores?
That's not very convenient. I want docker to be able to use all my cores when I build an image.
Even if we pretend docker is a VM, building an image can happen on as many cores as you like in this hypothetical, it's the running of it that should be restricted.
Context switching for processes is done in software (i.e. the OS) via traps because TSS does not store all the registers and it doesn't offer a way to be selective to what the process actually needs to load (=slower). This limits its visibility to what's in the actively mapped registers as well as not guaranteeing the procedure even tries to reload all the registers. In this case, even if the OS does restore certain…
I can't easily find good documentation on the instructions you mentioned; but are you sure those save and load the whole register file, and not just the visible registers? There are some registers that are not typically explicitly visible, that I'd expect to also be saved or at least manipulable in a hypervisor, but just like the cache state isn't saved, I wouldn't expect the register file to be saved. If we assume t…
Reading more the VM* command sets definitely load/save more than just the normally visible registers, the descriptions in the AMD ASM manual are very explicit about that. However, it looks like (outside the encrypted guest case where everything is done in 1 command) the hyper visor still calls the typical XRSTOR for the float registers, which is no different than the normal OS case. If that's true then I can see how the register file is still contaminated in the non SMT case.
I read the article and I really liked that the author tried to make it seem as simple as possible that you don't need a degree or a deep understanding of how CPUs work to understand the issue. However, one thing that bothers me is that the author claims it's possible to retrieve private keys or root passwords by triggering a faulty revert from the instruction that resets the upper bits of a register. Where is the dem…
The exploit will leak more or less random data (data which was accessed recently by the CPU). You cannot target a specific part of the memory, but you can keep fetching data until you get something interesting.
so if I wanted to test if it leaks my root password, I should run the code and open a terminal and say, upgrade packages, or upgrade packages before running the exploit code?
The exploit will leak more or less random data (data which was accessed recently by the CPU). You cannot target a specific part of the memory, but you can keep fetching data until you get something interesting.
so if I wanted to test if it leaks my root password, I should run the code and open a terminal and say, upgrade packages, or upgrade packages before running the exploit code?
Your root password is stored as a hash. It could leak when you type it in sudo for instance.
effort to lie on a text comment << effort to lie with a video
We are on a tech site with highly intelligent individuals who have been programming computers since we've been in diapers. If you don't believe the text then how would you believe the video? Anything can be done in devtools beforehand and I can think of a million different ways to fake the video. Personally, if I didn't trust the text then an easily faked video wouldn't placate me either.
Are they out of their mind? This is not a "medium".
Under what circumstances is this not a medium? The only case this applies is if you have public runners running completely untrusted code, and if you're doing that I hope you're doing it on EPYC, which is fixed. And if you're doing that, you're probably mining crypto for randoms.