From: Ard Biesheuvel <ardb@kernel.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Morten Linderud <morten@linderud.pw>,
Eric Snowberg <eric.snowberg@oracle.com>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
Mimi Zohar <zohar@linux.ibm.com>,
David Howells <dhowells@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>,
Jarkko Sakkinen <jarkko@kernel.org>,
"jmorris@namei.org" <jmorris@namei.org>,
"serge@hallyn.com" <serge@hallyn.com>,
"keescook@chromium.org" <keescook@chromium.org>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"weiyongjun1@huawei.com" <weiyongjun1@huawei.com>,
Nayna Jain <nayna@linux.ibm.com>,
Eric Biggers <ebiggers@google.com>,
Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
"lszubowi@redhat.com" <lszubowi@redhat.com>,
"jason@zx2c4.com" <jason@zx2c4.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"pjones@redhat.com" <pjones@redhat.com>,
Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH v8 16/17] integrity: Trust MOK keys if MokListTrustedRT found
Date: Thu, 10 Nov 2022 16:30:19 +0100 [thread overview]
Message-ID: <CAMj1kXEv3raFtwMmA4gYX=Z5YBfJ5f9GP0L0Zo4FBabwTfhn8Q@mail.gmail.com> (raw)
In-Reply-To: <47ae05f8d3a67ee5e1607ab8e718cc4b3e95cebb.camel@HansenPartnership.com>
On Thu, 10 Nov 2022 at 16:27, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Thu, 2022-11-10 at 16:06 +0100, Morten Linderud wrote:
> > I'm not really sure what Peter means with "much more reliable"
> > though.
>
> It's that in-head knowledge you referred to. You can't see the true
> MoK variables because they're BootServices, meaning they're not visible
> in the RunTime, which is why the shadow RT variables exist (this is a
> security property: BS only variables can only be altered by trusted,
> signed entities). However lots of things can create RT variables so
> you have to run through a sequence of checks on the RT shadows to try
> to defeat clever attackers (like verifying the variable attributes),
> because the chain of custody from BS to RT is not guaranteed. If you
> use a configuration table instead, that is BS only, the kernel (which
> is also a trusted entity) has to pick it out before ExitBootServices,
> so if the kernel has the table, you have a reliable chain of custody
> for the entries.
>
No config table are always accessible, also at runtime under the OS.
But they are volatile so they can only have been created since the
last reset of the system, so in that sense they are similar to the
volatile RT variables aliases.
The reason for preferring config tables is that you can access them
much earlier, and without mapping the EFI runtime memory regions etc
etc
next prev parent reply other threads:[~2022-11-10 15:32 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-24 4:41 [PATCH v8 00/17] Enroll kernel keys thru MOK Eric Snowberg
2021-11-24 4:41 ` [PATCH v8 01/17] KEYS: Create static version of public_key_verify_signature Eric Snowberg
2021-11-24 4:41 ` [PATCH v8 02/17] integrity: Fix warning about missing prototypes Eric Snowberg
2021-11-24 4:41 ` [PATCH v8 03/17] integrity: Introduce a Linux keyring called machine Eric Snowberg
2021-11-25 2:49 ` Mimi Zohar
2021-11-29 22:50 ` Eric Snowberg
2021-11-27 0:39 ` Jarkko Sakkinen
2021-11-24 4:41 ` [PATCH v8 04/17] integrity: Do not allow machine keyring updates following init Eric Snowberg
2021-11-27 0:42 ` Jarkko Sakkinen
2021-11-24 4:41 ` [PATCH v8 05/17] X.509: Parse Basic Constraints for CA Eric Snowberg
2021-11-27 0:43 ` Jarkko Sakkinen
2021-11-24 4:41 ` [PATCH v8 06/17] KEYS: CA link restriction Eric Snowberg
2021-11-27 0:44 ` Jarkko Sakkinen
2021-11-24 4:41 ` [PATCH v8 07/17] integrity: restrict INTEGRITY_KEYRING_MACHINE to restrict_link_by_ca Eric Snowberg
2022-02-14 12:42 ` Darren Kenny
2021-11-24 4:41 ` [PATCH v8 08/17] integrity: add new keyring handler for mok keys Eric Snowberg
2021-11-27 0:46 ` Jarkko Sakkinen
2021-11-24 4:41 ` [PATCH v8 09/17] KEYS: Rename get_builtin_and_secondary_restriction Eric Snowberg
2021-11-27 0:49 ` Jarkko Sakkinen
2021-11-30 17:21 ` Eric Snowberg
2021-12-01 10:27 ` Jarkko Sakkinen
2021-12-01 13:46 ` Mimi Zohar
2021-12-04 17:39 ` Jarkko Sakkinen
2021-12-15 18:14 ` Eric Snowberg
2021-12-15 19:54 ` Mimi Zohar
2021-11-24 4:41 ` [PATCH v8 10/17] KEYS: add a reference to machine keyring Eric Snowberg
2022-02-14 12:18 ` Darren Kenny
2021-11-24 4:41 ` [PATCH v8 11/17] KEYS: Introduce link restriction for machine keys Eric Snowberg
2022-02-14 12:23 ` Darren Kenny
2021-11-24 4:41 ` [PATCH v8 12/17] KEYS: integrity: change link restriction to trust the machine keyring Eric Snowberg
2021-11-24 4:41 ` [PATCH v8 13/17] integrity: store reference to " Eric Snowberg
2022-02-14 12:27 ` Darren Kenny
2021-11-24 4:41 ` [PATCH v8 14/17] KEYS: link machine trusted keys to secondary_trusted_keys Eric Snowberg
2022-02-14 12:28 ` Darren Kenny
2021-11-24 4:41 ` [PATCH v8 15/17] efi/mokvar: move up init order Eric Snowberg
2022-02-14 12:29 ` Darren Kenny
2021-11-24 4:41 ` [PATCH v8 16/17] integrity: Trust MOK keys if MokListTrustedRT found Eric Snowberg
2022-02-14 12:31 ` Darren Kenny
2022-11-10 0:01 ` Morten Linderud
2022-11-10 0:54 ` Eric Snowberg
2022-11-10 15:06 ` Morten Linderud
2022-11-10 15:27 ` James Bottomley
2022-11-10 15:30 ` Ard Biesheuvel [this message]
2022-11-10 7:42 ` Ard Biesheuvel
2022-11-10 14:27 ` Morten Linderud
2022-11-10 14:15 ` James Bottomley
2021-11-24 4:41 ` [PATCH v8 17/17] integrity: Only use machine keyring when uefi_check_trust_mok_keys is true Eric Snowberg
2022-02-14 12:37 ` Darren Kenny
2022-02-20 23:23 ` [PATCH v8 00/17] Enroll kernel keys thru MOK Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMj1kXEv3raFtwMmA4gYX=Z5YBfJ5f9GP0L0Zo4FBabwTfhn8Q@mail.gmail.com' \
--to=ardb@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=ebiggers@google.com \
--cc=eric.snowberg@oracle.com \
--cc=herbert@gondor.apana.org.au \
--cc=jarkko@kernel.org \
--cc=jason@zx2c4.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=keyrings@vger.kernel.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lszubowi@redhat.com \
--cc=morten@linderud.pw \
--cc=nayna@linux.ibm.com \
--cc=nramas@linux.microsoft.com \
--cc=pjones@redhat.com \
--cc=serge@hallyn.com \
--cc=torvalds@linux-foundation.org \
--cc=weiyongjun1@huawei.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).