Kdump with signed images

[Eric W. Biederman]

Matthew Garrett <mjg at redhat.com> writes:

> On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
>> No.  UEFI secure boot has absolutely nothing todo with this.
>> 
>> UEFI secure boot is about not being able to hijack the code EFI runs
>> directly.  Full stop.
>
> No. It's about ensuring that no untrusted code can be run before any OS 
> kernel, which means that no untrusted code can run *in* any OS kernel.

Hogwash.

- All code has bugs.
- Firmware is particularly susceptible to buggy implementations.
- In the presence of bugs no guarantees can be made.
- All you can do is limit your level of exposure.
- Verifying a signature before you run code seems a reasonable way to
  limit exposure to code that can exploit bugs.

Anything else is policy people build on top of the mechanisms UEFI gives
them.



The statement that no untrusted code can run *in* any OS kernel is
ridiculous on the face of it.  In general all distros ship with patches
that have not received enough review to have been merged into the main
linux kernel.  Aka untrusted code.  Nothing has fixed the UEFI bugs aka
untrusted code.  Not to mention the how many little trust I have in
unreviewable binary blobs that UEFI needs to support to run OS's like
OSX and Windows.


Targeting never running any untrusted code in ring 0 seems like a
reasaonable target, and worth figuring out how to implement.  But don't
justify it by saying UEFI in secure boot mode requires it.  And don't
forget that what people trust are different things.

Eric