On Fri, Dec 20, 2013 at 03:20:16PM -0800, Kees Cook wrote:
> On Fri, Dec 20, 2013 at 3:11 PM, Eric W. Biederman
> <[email protected]> wrote:
> > Vivek Goyal <[email protected]> writes:
> >
> >> On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote:
> >>> On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote:
> >
> >>> IMO it's up to user land to search lists of certificates, and present
> >>> only the final chain of trust to the kernel for checking.
> >>>
> >>> ELF is the preferred format for most sane OSes and firmware, and a detached
> >>> signature would probably be simplest to check. If we have the choice,
> >>> without restrictions from braindead boot loaders, ELF should be first.
> >>> And if the pesigning isn't usable and another sig is needed anyway,
> >>> why not apply that to vmlinux(.gz) ?
> >>
> >> I have yet to look deeper into it that if we can sign elf images and
> >> just use elf loader. And can use space extract the elf image out of
> >> a bzImage and pass it to kernel.
> >>
> >> Even if it is doable, one disadvantage seemed to be that extracted
> >> elf images will have to be written to a file so thta it's file descriptor
> >> can be passed to kernel. And that assumed writable root and we chrome
> >> folks seems to have setups where root is not writable.
> >
> > In that case the chrome folks would simply have to use an ELF format
> > kernel and not a bzImage.
>
> If we're doing fd origin verification (not signatures), can't we
> continue to use a regular bzImage?
If secureboot is enabled, it enforces module signature verification. I
think similar will happen for kexec too. How would kernel know that on
a secureboot platform fd original verification will happen and it is
sufficient.
I personally want to support bzImage as well (apart from ELF) because
distributions has been shipping bzImage for a long time and I don't
want to enforce a change there because of secureboot. It is not necessary.
Right now I am thinking more about storing detached bzImage signatures
and passing those signatures to kexec system call.
Thanks
Vivek
On 01/02/2014 12:39 PM, Vivek Goyal wrote:
>
> If secureboot is enabled, it enforces module signature verification. I
> think similar will happen for kexec too. How would kernel know that on
> a secureboot platform fd original verification will happen and it is
> sufficient.
>
> I personally want to support bzImage as well (apart from ELF) because
> distributions has been shipping bzImage for a long time and I don't
> want to enforce a change there because of secureboot. It is not necessary.
> Right now I am thinking more about storing detached bzImage signatures
> and passing those signatures to kexec system call.
>
Since the secureboot scenario probably means people will be signing
those kernels, and those kernels are going to be EFI images, that in
order to have "one kernel, one signature" there will be a desire to
support signed PE images. Yes, PE is ugly but it shouldn't be too bad.
However, it is probably one of those things that can be dealt with one
bit at a time.
-hpa
On Thu, Jan 2, 2014 at 3:56 PM, H. Peter Anvin <[email protected]> wrote:
> On 01/02/2014 12:39 PM, Vivek Goyal wrote:
>>
>> If secureboot is enabled, it enforces module signature verification. I
>> think similar will happen for kexec too. How would kernel know that on
>> a secureboot platform fd original verification will happen and it is
>> sufficient.
>>
>> I personally want to support bzImage as well (apart from ELF) because
>> distributions has been shipping bzImage for a long time and I don't
>> want to enforce a change there because of secureboot. It is not necessary.
>> Right now I am thinking more about storing detached bzImage signatures
>> and passing those signatures to kexec system call.
>>
>
> Since the secureboot scenario probably means people will be signing
> those kernels, and those kernels are going to be EFI images, that in
> order to have "one kernel, one signature" there will be a desire to
> support signed PE images. Yes, PE is ugly but it shouldn't be too bad.
> However, it is probably one of those things that can be dealt with one
> bit at a time.
David Howells posted patches to support signed PE binaries early last
year. They were rejected rather quickly.
https://lkml.org/lkml/2013/2/21/196
That was for loading keys via PE binaries, but the parser is needed
either way. Unless I'm misunderstanding what you're suggesting?
josh
On 01/06/2014 01:33 PM, Josh Boyer wrote:
> On Thu, Jan 2, 2014 at 3:56 PM, H. Peter Anvin <[email protected]> wrote:
>> On 01/02/2014 12:39 PM, Vivek Goyal wrote:
>>>
>>> If secureboot is enabled, it enforces module signature verification. I
>>> think similar will happen for kexec too. How would kernel know that on
>>> a secureboot platform fd original verification will happen and it is
>>> sufficient.
>>>
>>> I personally want to support bzImage as well (apart from ELF) because
>>> distributions has been shipping bzImage for a long time and I don't
>>> want to enforce a change there because of secureboot. It is not necessary.
>>> Right now I am thinking more about storing detached bzImage signatures
>>> and passing those signatures to kexec system call.
>>>
>>
>> Since the secureboot scenario probably means people will be signing
>> those kernels, and those kernels are going to be EFI images, that in
>> order to have "one kernel, one signature" there will be a desire to
>> support signed PE images. Yes, PE is ugly but it shouldn't be too bad.
>> However, it is probably one of those things that can be dealt with one
>> bit at a time.
>
> David Howells posted patches to support signed PE binaries early last
> year. They were rejected rather quickly.
>
> https://lkml.org/lkml/2013/2/21/196
>
> That was for loading keys via PE binaries, but the parser is needed
> either way. Unless I'm misunderstanding what you're suggesting?
>
I know. I think the kexec is a better motivation, though.
-hpa