- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
“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
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.