lkml.org 
[lkml]   [2012]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Second attempt at kernel secure boot support
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


\
 
 \ /
  Last update: 2012-11-06 14:24    [W:0.269 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site