[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02B8A5B0-1284-4DC5-A844-21265129C417@oracle.com>
Date: Thu, 18 Nov 2021 21:37:00 +0000
From: Eric Snowberg <eric.snowberg@...cle.com>
To: Mimi Zohar <zohar@...ux.ibm.com>
CC: "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
"linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
"dhowells@...hat.com" <dhowells@...hat.com>,
"dwmw2@...radead.org" <dwmw2@...radead.org>,
"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
"davem@...emloft.net" <davem@...emloft.net>,
Jarkko Sakkinen <jarkko@...nel.org>,
"jmorris@...ei.org" <jmorris@...ei.org>,
"serge@...lyn.com" <serge@...lyn.com>,
"keescook@...omium.org" <keescook@...omium.org>,
"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
"weiyongjun1@...wei.com" <weiyongjun1@...wei.com>,
"nayna@...ux.ibm.com" <nayna@...ux.ibm.com>,
"ebiggers@...gle.com" <ebiggers@...gle.com>,
"ardb@...nel.org" <ardb@...nel.org>,
"nramas@...ux.microsoft.com" <nramas@...ux.microsoft.com>,
"lszubowi@...hat.com" <lszubowi@...hat.com>,
"jason@...c4.com" <jason@...c4.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"James.Bottomley@...senpartnership.com"
<James.Bottomley@...senPartnership.com>,
"pjones@...hat.com" <pjones@...hat.com>,
Konrad Wilk <konrad.wilk@...cle.com>
Subject: Re: [PATCH v7 13/17] KEYS: link secondary_trusted_keys to machine
trusted keys
> On Nov 18, 2021, at 5:32 AM, Mimi Zohar <zohar@...ux.ibm.com> wrote:
>
> Hi Eric,
>
> Is the subject line left over from the original patch? Shouldn't it
> be "link machine trusted keys to secondary_trusted_keys".
Yes, you are right, this was left over from the original patch. I’ll update
the heading in the next round.
> On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
>> Allow the .machine keyring to be linked to the secondary_trusted_keys.
>> After the link is created, keys contained in the .machine keyring will
>> automatically be searched when searching secondary_trusted_keys.
>>
>> Signed-off-by: Eric Snowberg <eric.snowberg@...cle.com>
>> ---
>> v3: Initial version
>> v4: Unmodified from v3
>> v5: Rename to machine keyring
>> v7: Unmodified from v5
>> ---
>> certs/system_keyring.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
>> index ba732856ebd0..2a2dc70b126c 100644
>> --- a/certs/system_keyring.c
>> +++ b/certs/system_keyring.c
>> @@ -101,6 +101,9 @@ static __init struct key_restriction *get_secondary_restriction(void)
>> void __init set_machine_trusted_keys(struct key *keyring)
>> {
>> machine_trusted_keys = keyring;
>> +
>> + if (key_link(secondary_trusted_keys, machine_trusted_keys) < 0)
>> + panic("Can't link (machine) trusted keyrings\n");
>> }
>>
>> /**
>
> In general is the ordering of the patches "bisect safe"[1]? Only in
> the next patch is machine_trusted_keys set. In this case, either
> merge the two patches or reverse their order.
I’ll also reverse the ordering in the next round too. Thanks.
Powered by blists - more mailing lists