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.
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.
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.