lkml.org 
[lkml]   [2018]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot
From
Date
On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote:
> On 15.08.2018 22:47, Linus Torvalds wrote:
> > It basically says: we don't allow modules that weren't built with
> > the kernel. Adding a new key later and signing a module with it
> > violates that premise.
>
> Considering the following scenario:
> A user is running a distro kernel, which is built by the distro, and
> has the distro signing key builtin (i.e. fedora). Now, the user has
> taken ownership of their system and provisioned their own platform
> key. Accordingly, the user signs the distro kernel with their own
> key.
>
> If I understand you correctly, modules signed by the users own key,
> but not signed with the distro key, will stop working in this case?

They never actually would have worked, but yes.

> IMO, this is not okay. The layer of trust should extend from the
> bottom (user-provisioned platform key) up. Only trusting the kernel
> builtin key later on (wrt. kernel modules) contradicts this
> principal.

The kernel can't tell whether the UEFI user has taken ownership or not
so it has no basis on which to make a decision to trust the UEFI keys
or not, so we should *always* not trust them.

Consider a UEFI system for which a user has taken ownership, but which
has some signed ROMs which are UEFI secure boot verified. Simply to
get their system to boot the user will be forced to add the ODM key to
the UEFI db ... and I'm sure in that situation the user wouldn't want
to trust the ODM key further than booting.

James

\
 
 \ /
  Last update: 2018-08-15 23:13    [W:0.496 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site