On Wed, 2021-09-08 at 19:03 +0300, Jarkko Sakkinen wrote: > On Tue, 2021-09-07 at 12:00 -0400, Eric Snowberg wrote: > > Many UEFI Linux distributions boot using shim. The UEFI shim provides > > what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure > > Boot DB and MOK keys to validate the next step in the boot chain. The > > MOK facility can be used to import user generated keys. These keys can > > be used to sign an end-user development kernel build. When Linux boots, > > pre-boot keys (both UEFI Secure Boot DB and MOK keys) get loaded in the > > Linux .platform keyring. > > > > Currently, pre-boot keys are not trusted within the Linux trust boundary > > [1]. These platform keys can only be used for kexec. If an end-user > > What exactly is "trust boundary"? And what do you mean when you say that > Linux "trusts" something? AFAIK, software does not have feelings. Please, > just speak about exact things. > > That's the whole point of the cover letter. It's better to not have cover > letter at all, than a confusing cover letter that reads like a white paper. > Code changes at least tell the exact story, and not speak about feelings. > > > wants to use their own key within the Linux trust boundary, they must > > either compile it into the kernel themselves or use the insert-sys-cert > > script. Both options present a problem. Many end-users do not want to > > compile their own kernels. With the insert-sys-cert option, there are > > missing upstream changes [2]. Also, with the insert-sys-cert option, > > the end-user must re-sign their kernel again with their own key, and > > then insert that key into the MOK db. Another problem with > > insert-sys-cert is that only a single key can be inserted into a > > compressed kernel. > > I use a pre-compiled kernel in my desktop: https://liquorix.net/. When > a new version comes up it requires a sbsign one-liner to sign it for > secure boot. I'm wondering what is the problem I'm facing because I do > not see it. > > If there are something missing changes that you use as a rationale for > this large patch set, you should at least broadly explain what we are > missing. How I conclude this paragraph is that, since there is only an > xref, they are not really "that important" changes, which are missing. > > > Having the ability to insert a key into the Linux trust boundary opens > > up various possibilities. The end-user can use a pre-built kernel and > > sign their own kernel modules. It also opens up the ability for an > > Which both can be done by end-user as of today, or I'm misreading this. > > > end-user to more easily use digital signature based IMA-appraisal. To > > get a key into the ima keyring, it must be signed by a key within the > > Linux trust boundary. > > What is IMA appraisal? I just don't know it because I don't use IMA. > Again, this trust boundary is really something I do not. Looking at > code changes, you could just speak about exact assets in the kernel. > > > Downstream Linux distros try to have a single signed kernel for each > > architecture. Each end-user may use this kernel in entirely different > > ways. Some downstream kernels have chosen to always trust platform keys > > within the Linux trust boundary for kernel module signing. These > > kernels have no way of using digital signature base IMA appraisal. > > > > This series introduces a new Linux kernel keyring containing the Machine > > Owner Keys (MOK) called .machine. It also adds a new MOK variable to shim. > > This variable allows the end-user to decide if they want to trust keys > > enrolled in the MOK within the Linux trust boundary. By default, > > nothing changes; MOK keys are not trusted within the Linux kernel. They > > are only trusted after the end-user makes the decision themselves. The > > end-user would set this through mokutil using a new --trust-mok option > > [3]. This would work similar to how the kernel uses MOK variables to > > enable/disable signature validation as well as use/ignore the db. > > OK, changes are described here (again speaking about trusting tho). The > motivation part is missing. The text before this is more like confusion > part. When you describe motivation to do something you should really be in > grass roots, e.g. "when you have this feature in the kernel, look, I can > do now this". It's not that hard. E.g. with an usage example it is quite > quick accomplish this. The code changes overally make sense but this motivotional part is the problem. E.g. if you do a pull request, it is completely *unusable* in that context. In that case I would have to write something that should have been the cover letter. It's 12 patches, so it is perfectly sensible to ask a better one. /Jarkko
