On Mon, 25 Jun 2012, Peter Jones <pjones@xxxxxxxxxx> wrote:
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.
Is there a hardware switch or jumper that can be set so that no
modification of the firmware is possible? My question here is:
if I have gross physical possession of the hardware can I disable
firmware updates done just via code running on the x86/UEFI
chips?
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.
Will the UEFI be able to send and receive information over a
local network, say via Ethernet? That is, without an old
fashioned "kernel" being booted. By "old fashioned" I mean
something like the Linux kernel, which, I think runs, usually, in
a "space" different from the space where UEFI code runs?
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.
I will attempt to think about this.
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().
So, if I have understood (part of) your explanation, the x86
processor must run in order to modify the contents of the flash
memory used by the UEFI to hold various tables, including the DBX
table.
I will attempt to think about this.
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.
Ah, here a long and bulbous discussion threatens to obtrude.
--
Peter
One more question today:
I know that UEFI hardware is available.
Which hardware do you recommend, if I want to actually see the
UEFI and perhaps try it out?
Thank you, Peter!
oo--JS.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
