On Tue, Jun 12, 2012 at 2:27 PM, Peter Jones <pjones@xxxxxxxxxx> 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
