On Wed, 31 Oct 2012, Matthew Garrett wrote: > > Reading stored memory image (potentially tampered before reboot) from disk > > is basically DMA-ing arbitrary data over the whole RAM. I am currently not > > able to imagine a scenario how this could be made "secure" (without > > storing private keys to sign the hibernation image on the machine itself > > which, well, doesn't sound secure either). > > 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? > 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? Obvious step towards solving this is making the variable inaccessible after ExitBootServices() has been called (by not setting runtime access flag on it). Now how about this scenario: - 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 - 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 - he/she reboots the machine in a way that shim+distro kernel+hacker's S4 image is used to resume - distro kernel verifies the signature of the S4 image against the attacker's public key stored in the variable; the signature is OK - he/she has won, as he has managed to run an arbitrary kernel code (stored in the S4 image) in a trusted mode No? Basically, once the machine is already populated with the "secure" version of Linux, this can't happen, as we will (as far as I understand) set the variable for storing the public key in a way that it can't be accessed from runtime environment. But how can we prevent it being *created* before the machine is ever touched by Linux? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
