As the commenter under that article stated, it’s odd that AMD designed SEV in a way that the initial value is enough to pass the authentication.
This is incorrect, the “default value” is a poorly translated example from the german article - this exploit does NOT rely on resetting any SEV-specific memory or similar.
I re-read the article and the original ComputerBase article, and I think I have a better understanding of it now. You can read my update and let me know if I’m still misunderstanding it.
Yes, you understood correctly.
This is also not a rare occurence, you can programmatically find locations in a binary where un-doing a cached write allows manipulating control flow - there are more examples in the paper.
You will likely find these locations (called gadgets) in just about every binary - not because all devs are stupid and set the default to the “exploitable” case, but because this is how compiler code generation pans out in the grand scheme of things.
cmon, thats quite normal
- the NSA, probably
It’s similar to when Mac OS accepted an empty password at login.
Pretty sure this sub will use the same defense as /r/apple did.
I haven’t seen anyone defend AMD with this, so I think we’re doing okay for now.
For those that are inevitably too lazy to click
The vulnerability affects first through third generation EPYC CPUs (Naples, Rome, and Milan), but AMD has only made a microcode patch for third generation Milan chips.
“SEV not intended to be protective” is the biggest load of horseshit I’ve heard, even intel didn’t beat around the bush with actually admitting they had flaws and patching them.
Amd didn’t patch the take-a-way or prefetch+TLB bleed either, because shipping a secure processor would have hurt their benchmark scores too much. So they just continued to ship insecure-by-default (and recommend against enabling the mitigations by default) those other times too.
very good presentation
I was waiting for this to resurface in my recommendations