*countable infinities only

Gregory Maxwell gmaxwell at gmail.com
Tue Jun 12 19:49:44 UTC 2012

On Tue, Jun 12, 2012 at 2:27 PM, Peter Jones <pjones at redhat.com> wrote:
> No, they literally cannot do that. Having a special debugging key that
> chains to a CA key that's in the key database (DB), which would allow the
> ability to do kernel debugging activities which could, for example, write
> to arbitrary memory, would completely obviate the ability of Secure Boot
> to be effective at all.
> The scenario you describe /cannot/ work.

Here is one fairly simple way, as an example— When you register as a
developer with Microsoft you run a tool on the your target system to
extract the trusted boot identity and they return to you signed
certificate that says this particular piece of hardware is allowed to
boot unconfined.  You give this certificate to your Secure Boot signed
bootloader and it lets you choose to boot an unprotected debugging
enabled kernel— but only on the hardware you've registered.

Because many though not all systems shipping _now_ are trusted boot
compatible I expect this to be even more true in the post UEFI world.
Developers haven't found needing special hardware for hardware
virtualization to be a big deal, so requiring TXT extensions doesn't
sound like much more to me.

There are also many other less good options, e.g. requiring special
developer hardware as has been done at times in the mobile space,  but
I don't really need to invoke them because the standard commodity
hardware will have all the required components if not in the
immediately coming generation then in the next product cycle.  There
is nothing contrived in this argument— executing this kind of control,
for good or bad purposes, is exactly what this technology is being
developed for.

(And, of course, Microsoft has been using signed drivers for some
time— at least partially because the ecosystem around windows has been
a bit too free wheeling for their tastes and ability to support)

The notion that locking down the systems is incompatible with enabling
(at least some kinds of) development is simply disproven by the
vigorous development we see on locked down devices. As as been argued
here to excuse the lockdown of Fedora, developers are often willing
and able to take some additional steps— especially in the context of
commercial development for the worlds most popular platform.

More information about the devel mailing list