*countable infinities only

[Jay Sulzberger]

On Mon, 25 Jun 2012, Peter Jones <pjones at redhat.com> 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.