> On Sep 16, 2021, at 4:14 PM, Peter Jones <pjones@xxxxxxxxxx> wrote: > > On Thu, Sep 16, 2021 at 06:15:50PM +0300, Jarkko Sakkinen wrote: >> On Wed, 2021-09-15 at 15:28 -0600, Eric Snowberg wrote: >>>> On Sep 15, 2021, at 11:57 AM, Jarkko Sakkinen <jarkko@xxxxxxxxxx> 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 >>> >> >> So, my 2nd Q would be: which order these should be upstreamed? >> >> Linux patch set cannot depend on "yet to be upstreamed" things. >> >> Code changes look good enough to me. > > We can carry this support in shim before it's in kernel. Eric's current > patch for shim and mokutil looks mostly reasonable, though I see a few > minor nits we'll have to sort out. Thanks Peter. Previously I had not sent it for a shim review since I wanted to make sure this approach had a path forward. I’ll work on submitting the shim changes for review now.
