lkml.org 
[lkml]   [2012]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC] Second attempt at kernel secure boot support
Jiri Kosina <jkosina@suse.cz> writes:

> On Fri, 2 Nov 2012, Vivek Goyal wrote:
>
>> > With secure boot enabled, then the kernel should refuse to let an
>> > unsigned kexec load new images, and kexec itself should refuse to
>> > load unsigned images.
>>
>> Yep, good in theory. Now that basically means reimplementing kexec-tools
>> in kernel.
>
> Why is "when kernel has been securely booted, the in-kernel kexec
> mechanism has to verify the signature of the supplied image before
> kexecing it" not enough? (basically the same thing we are doing for signed
> modules already).

For modules the only untrusted part of their environment are the command
line parameters, and several of those have already been noted for
needing to be ignored in a non-trusted root scenario.

For kexec there is a bunch of glue code and data that takes care of
transitioning from the environment provided by kexec and the environment
that the linux kernel or memtest86 or whatever we are booting is
expecting.

Figuring out what glue code and data we need and supplying that glue
code and data is what kexec-tools does. The situation is a bit like
dealing with the modules before most of the work of insmod was moved
into the kernel.

For kexec-tools it is desirable to have glue layers outside of the
kernel because every boot system in existence has a different set of
parameter passing rules.

So signing in the kernel gets us into how do we sign the glue code and
how dow we verify the glue code will jump to our signed and verified
kernel image.

I will be happy to review patches for that don't through the baby out
with the bath water.

Eric



\
 
 \ /
  Last update: 2012-11-05 08:23    [W:0.547 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site