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. -- Peter
