On Aug 2, 2016 9:42 PM, "Michael S. Tsirkin" wrote: > > On Tue, Aug 02, 2016 at 09:34:14PM -0700, Andy Lutomirski wrote: > > On Tue, Aug 2, 2016 at 8:32 PM, Matthew Garrett wrote: > > > On Tue, Aug 2, 2016 at 7:58 PM, Andy Lutomirski wrote: > > >> - Appeasing the Secure Boot deities. AFAIK this specifically > > >> requires that we verify the kernel and its modules using a combination > > >> of EFI-supplied and distro keys. > > > > > > Eh not quite. The rules are basically that if a Microsoft-signed > > > object can be used to compromise other operating systems, Microsoft > > > may unilaterally blacklist that object. Allowing arbitrary module > > > loading or arbitrary kexec clearly makes it straightforward to simply > > > use a signed Linux boot chain to then boot a compromised version of > > > any other operating system, defeating the point of Secure Boot. > > > > > Distro > > > keys are used for module signing because that's the easiest way to > > > handle it (sign them during build and then discard the key), > > > > With my module hashing patches, that'll be even simpler. The kernel > > image will contain a list of SHA256 hashes of in-tree .ko files and > > will accept those files. > > Hmm. I kind of like ability to build and add modules to a running > kernel. And I think some distros might use it too, updating modules > without updating the kernel (doesn't work if you discard the key, > obviously). I have no plans to prevent the existing module signature verification scheme from working. I just see no reason that in-tree modules should need to be signed. > > > > UEFI keys > > > are used to appease some manufacturers (they can ship their > > > binary-only drivers signed with a key that's in firmware) and shim > > > keys are used to allow users to sign their own modules. > > > > Hmm. Would it be okay if a physically present user could subvert it? > > For example, if a physically present user typed "insecure" into a > > bootloader command line and thus turned off signature verification? > > Typically already possible with firmware menus. Sure, but I'm trying to understand what types of attacks we need to resist.