linux-kernel - Re: [PATCH v7 13/17] KEYS: link secondary_trusted

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e0e704761d5929f73e5e53ac99cd4935ea268cc5.camel@linux.ibm.com>
Date:   Thu, 18 Nov 2021 07:32:31 -0500
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Eric Snowberg <eric.snowberg@...cle.com>, keyrings@...r.kernel.org,
        linux-integrity@...r.kernel.org, dhowells@...hat.com,
        dwmw2@...radead.org, herbert@...dor.apana.org.au,
        davem@...emloft.net, jarkko@...nel.org, jmorris@...ei.org,
        serge@...lyn.com
Cc:     keescook@...omium.org, torvalds@...ux-foundation.org,
        weiyongjun1@...wei.com, nayna@...ux.ibm.com, ebiggers@...gle.com,
        ardb@...nel.org, nramas@...ux.microsoft.com, lszubowi@...hat.com,
        jason@...c4.com, linux-kernel@...r.kernel.org,
        linux-crypto@...r.kernel.org, linux-efi@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        James.Bottomley@...senPartnership.com, pjones@...hat.com,
        konrad.wilk@...cle.com
Subject: Re: [PATCH v7 13/17] KEYS: link secondary_trusted_keys to machine
 trusted keys

Hi Eric,

Is the subject line left over from the original patch?   Shouldn't it
be "link machine trusted keys to secondary_trusted_keys".

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.

thanks,

Mimi

[1] Refer to the section "Separate your changes" in
Documentation/process/submitting-patches.rst.