[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiTRwf0+j7AZGfURup2PqE-QG2WiWmKnmc0d8N8G7MAASPhiA@mail.gmail.com>
Date: Fri, 7 Feb 2025 00:04:00 +0100
From: trinity pointard <trinity.pointard@...il.com>
To: oss-security@...ts.openwall.com, "jcb62281@...il.com" <jcb62281@...il.com>
Subject: Re: AMD Microcode Signature Verification Vulnerability
> If an attacker is able to control the hypervisor (necessary to load
> rogue microcode) and the processor microcode, how can the VM trust that
> it is actually verifying that attestation and not being sent down a "oh
> yes it is exactly what you want it to be" garden path?
Attestations are cryptographically signed by the cpu, and meant to be sent
elsewhere and verified remotely. The key used to sign (VCEK) are dependent on
the microcode version, so it shouldn't be possible to forge new-looking
signature with old microcodes (i would hope this hold would someone be able to
decrypt a microcode, though i couldn't find information on that subject).
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
