On 06/25/2012 09:14 PM, Jay Sulzberger wrote:
[...] I have some questions about what sort of
capabilities the UEFI will have in machines sold later this year:
1. What is the mechanism for remote revocation of signing keys?
There's 2 mechanisms here. The first is a key list called DBX. This is
just a list of public keys that's checked before DB (the allowed key
list). Any key on DBX isn't allowed to boot up.
The second mechanism is a facility for signed updates. Basically, you
can do a SetVariable() call to append to DBX, and the call parameters must
be signed by the KEK. If the appended data isn't signed, or is signed by
a key other than the KEK, you get an error code.
There's actually a third mechanism, of course, which is that the firmware
can add keys, so if you apply a firmware update (which also undergo
cryptographic verification), the firmware could add a key on the next
reboot.
2. In particular, will the UEFI be able to revoke, at the command
of Hardware Key Central, signing keys without a standard (style
of) kernel being booted? That is, can the UEFI receive commands
over the Net using its own network capabilities?
There's no mechanism for automatic network updates or anything like that in
the standard, though a UEFI binary run from the firmware could apply an
update if it's signed by the KEK.
3. If booting a standard style of kernel is required to revoke,
at the command of Hardware Key Central, signing keys, then the
standard kernel must be capable of receiving and interpreting
such commands,
Well, the kernel wouldn't really be the responsible code here. Most
likely we'll make that a package update and use rpm %post scripts to
apply changes.
and also be capable of modifying the memory of the UEFI hardware.
No, we don't have this ability. The spec defines this in some general terms,
but on x86, here's the basic mechanism.
From userland, we set a UEFI variable, using a mechanism such as the
existing "efivars" facility. It has flags set to append to the DBX variable,
and also a flag that says it's an authenticated variable. It also includes
the signed data.
The kernel then calls UEFI's runtime services function "SetVariable()",
at which point in time firmware code is running again. This code calls the
into SMM mode, which is a special processor mode that's always been available
on x86, and has been used in the past for many things.
At this point the processor signals to the chipset that you're in SMM mode,
at which point the chipset makes the flash available. This is also the point
at which the signature is validated. If the signature is valid, the write
happens on the flash. If it's not, it stores a return code and exits SMM,
which as a bi-product blocks our access to the memory in question.
That all propagates back up and we get a success or failure from SetVariable().
How will the Englobulators ensure that every signed-by-Microsoft Red Hat
kernel will take orders from Hardware Key Central? Note I assume here that
Hardware Key Central is controlled by the Englobulators.
I don't know what an Englobulator is.
--
Peter
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
