lkml.org 
[lkml]   [2021]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v6 00/13] Enroll kernel keys thru MOK
From
Date

> On Sep 15, 2021, at 11:57 AM, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue, 2021-09-14 at 17:14 -0400, Eric Snowberg wrote:
>> Back in 2013 Linus requested a feature to allow end-users to have the
>> ability "to add their own keys and sign modules they trust". This was
>> his *second* order outlined here [1]. There have been many attempts
>> over the years to solve this problem, all have been rejected. Many
>> of the failed attempts loaded all preboot firmware keys into the kernel,
>> including the Secure Boot keys. Many distributions carry one of these
>> rejected attempts [2], [3], [4]. This series tries to solve this problem
>> with a solution that takes into account all the problems brought up in
>> the previous attempts.
>>
>> On UEFI based systems, this series introduces a new Linux kernel keyring
>> containing the Machine Owner Keys (MOK) called machine. It also defines
>> a new MOK variable in shim. This variable allows the end-user to decide
>> if they want to load MOK keys into the machine keyring. Mimi has suggested
>> that only CA keys contained within the MOK be loaded into the machine
>> keyring. All other certs will load into the platform keyring instead.
>>
>> By default, nothing changes; MOK keys are not loaded into the machine
>> keyring. They are only loaded after the end-user makes the decision
>> themselves. The end-user would set this through mokutil using a new
>> --trust-mok option [5]. This would work similar to how the kernel uses
>> MOK variables to enable/disable signature validation as well as use/ignore
>> the db. Any kernel operation that uses either the builtin or secondary
>> trusted keys as a trust source shall also reference the new machine
>> keyring as a trust source.
>>
>> Secure Boot keys will never be loaded into the machine keyring. They
>> will always be loaded into the platform keyring. If an end-user wanted
>> to load one, they would need to enroll it into the MOK.
>>
>> Steps required by the end user:
>>
>> Sign kernel module with user created key:
>> $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 \
>> machine_signing_key.priv machine_signing_key.x509 my_module.ko
>>
>> Import the key into the MOK
>> $ mokutil --import machine_signing_key.x509
>>
>> Setup the kernel to load MOK keys into the .machine keyring
>> $ mokutil --trust-mok
>>
>> Then reboot, the MokManager will load and ask if you want to trust the
>> MOK key and enroll the MOK into the MOKList. Afterwards the signed kernel
>> module will load.
>>
>> I have included links to both the mokutil [5] and shim [6] changes I
>> have made to support this new functionality.
>
> How hard it is to self-compile shim and boot it with QEMU (I
> do not know even the GIT location of Shim)?

It is not hard, that is the setup I use for my testing. Upstream shim
is located here [1]. Or you can use my repo which contains the necessary
changes [2].

[1] https://github.com/rhboot/shim
[2] https://github.com/esnowberg/shim/tree/mokvars-v2

\
 
 \ /
  Last update: 2021-09-15 23:30    [W:0.167 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site