Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <bee0ebc354a651ea5b263897f9b155dc604fa7c5.camel@kernel.org>
Subject: Re: [PATCH v6 00/13] Enroll kernel keys thru MOK
From:   Jarkko Sakkinen <jarkko@kernel.org>
To:     Eric Snowberg <eric.snowberg@oracle.com>, keyrings@vger.kernel.org,
        linux-integrity@vger.kernel.org, zohar@linux.ibm.com,
        dhowells@redhat.com, dwmw2@infradead.org,
        herbert@gondor.apana.org.au, davem@davemloft.net,
        jmorris@namei.org, serge@hallyn.com
Cc:     keescook@chromium.org, gregkh@linuxfoundation.org,
        torvalds@linux-foundation.org, scott.branden@broadcom.com,
        weiyongjun1@huawei.com, nayna@linux.ibm.com, ebiggers@google.com,
        ardb@kernel.org, nramas@linux.microsoft.com, lszubowi@redhat.com,
        linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        James.Bottomley@HansenPartnership.com, pjones@redhat.com,
        konrad.wilk@oracle.com
Date:   Wed, 15 Sep 2021 20:57:39 +0300
In-Reply-To: <20210914211416.34096-1-eric.snowberg@oracle.com>
References: <20210914211416.34096-1-eric.snowberg@oracle.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.36.5-0ubuntu1 
MIME-Version: 1.0
Precedence: bulk

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=20
> ability "to add their own keys and sign modules they trust". This was
> his *second* order outlined here [1]. There have been many attempts=20
> over the years to solve this problem, all have been rejected.  Many=20
> of the failed attempts loaded all preboot firmware keys into the kernel,
> including the Secure Boot keys. Many distributions carry one of these=20
> rejected attempts [2], [3], [4]. This series tries to solve this problem=
=20
> with a solution that takes into account all the problems brought up in=
=20
> the previous attempts.
>=20
> On UEFI based systems, this series introduces a new Linux kernel keyring=
=20
> 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=
=20
> if they want to load MOK keys into the machine keyring. Mimi has suggeste=
d=20
> that only CA keys contained within the MOK be loaded into the machine=20
> keyring. All other certs will load into the platform keyring instead.
>=20
> By default, nothing changes; MOK keys are not loaded into the machine
> keyring.  They are only loaded after the end-user makes the decision=20
> themselves.  The end-user would set this through mokutil using a new=20
> --trust-mok option [5]. This would work similar to how the kernel uses=
=20
> MOK variables to enable/disable signature validation as well as use/ignor=
e=20
> the db. Any kernel operation that uses either the builtin or secondary=
=20
> trusted keys as a trust source shall also reference the new machine=20
> keyring as a trust source.
>=20
> 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=
=20
> to load one, they would need to enroll it into the MOK.
>=20
> Steps required by the end user:
>=20
> 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
>=20
> Import the key into the MOK
> $ mokutil --import machine_signing_key.x509
>=20
> Setup the kernel to load MOK keys into the .machine keyring
> $ mokutil --trust-mok
>=20
> 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 kerne=
l
> module will load.
>=20
> 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)?

I'm all my SGX testing already with TianoCore and QEMU so I
thought it might not be that huge stretch to get testing env
for this.

/Jarkko