On Tue, Nov 06, 2012 at 01:51:15PM +0100, Jiri Kosina wrote: > On Wed, 31 Oct 2012, Matthew Garrett wrote: > > shim generates a public and private key. > > It seems to me that this brings quite a huge delay into the boot process > both for "regular" and resume cases (as shim has no way to know what is > going to happen next). Mostly because obtaining enough entropy is > generally very difficult when we have just shim running, right?
pseudorandom keys should be sufficient here. It's intended to deal with the case of an automated attack rather than a deliberate effort to break into a given user's system. > > It hands the kernel the private key in a boot parameter and stores the > > public key in a boot variable. On suspend, the kernel signs the suspend > > image with that private key and discards it. On the next boot, shim > > generates a new key pair and hands the new private key to the kernel > > along with the old public key. The kernel verifies the suspend image > > before resuming it. The only way to subvert this would be to be able to > > access kernel memory directly, which means the attacker has already won. > > I like this protocol, but after some off-line discussions, I still have > doubts about it. Namely: how do we make sure that there is noone tampering > with the variable? The variable has the same level of security as MOK, so that would be a more attractive target. > - consider securely booted win8 (no Linux installed on that machine, so > the variable for storing public key doesn't exist yet), possibly being > taken over by a malicious user > - he/she creates this secure variable from within the win8 and stores > his/her own public key into it You can't create a non-RT variable from the OS. > - he/she supplies a signed shim (as provided by some Linux distro vendor), > signed kernel (as provided by some Linux distro vendor) and specially > crafted resume image, signed by his/her own private key shim detects that the key has the RT bit set and deletes it. > - he/she reboots the machine in a way that shim+distro kernel+hacker's S4 > image is used to resume And so this step can't happen. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
