Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Darren Kenny <darren.kenny@oracle.com>
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,
        jarkko@kernel.org, jmorris@namei.org, serge@hallyn.com
Cc:     eric.snowberg@oracle.com, keescook@chromium.org,
        torvalds@linux-foundation.org, weiyongjun1@huawei.com,
        nayna@linux.ibm.com, ebiggers@google.com, ardb@kernel.org,
        nramas@linux.microsoft.com, lszubowi@redhat.com, jason@zx2c4.com,
        linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
        linux-efi@vger.kernel.org, linux-security-module@vger.kernel.org,
        James.Bottomley@HansenPartnership.com, pjones@redhat.com,
        konrad.wilk@oracle.com
Subject: Re: [PATCH v8 16/17] integrity: Trust MOK keys if MokListTrustedRT
 found
In-Reply-To: <20211124044124.998170-17-eric.snowberg@oracle.com>
References: <20211124044124.998170-1-eric.snowberg@oracle.com>
 <20211124044124.998170-17-eric.snowberg@oracle.com>
Date:   Mon, 14 Feb 2022 12:31:05 +0000
Message-ID: <m2a6ettyt2.fsf@oracle.com>
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?RkAvhGgvhKV91gQMy0wtd50xzcoCs8mbz0cFd/NYg/F4V3qb7selq65RDxHP?=
 =?us-ascii?Q?q/xWuryFqXleqqLBJKsM0+l+pkfL1447j2eIhmSQzdAjYavUUw7ya0ec5tDy?=
 =?us-ascii?Q?h5JOXHW+Ve2ADxtHalUGLff1+xAAr4Le4AjgF/PlSlKgnWSO0VsRwxygGtxk?=
 =?us-ascii?Q?y8s1Pp0kPhpZeJTcecZTi2x4/Cj9GilYN71N/mWgF2U2fsFR6h24TKdSzjDl?=
 =?us-ascii?Q?iWNourOpBfX/++wmgIFs8i+3PCnWOCEXndoZcOixobpYWwNgfnjMvvk17+xX?=
 =?us-ascii?Q?tTsvgPYCeH6XDl+OndwRQXoAAxKf8Iwk4xlmE4Lidw6w5yuDK8/+8XRjtPup?=
 =?us-ascii?Q?vFed6QxderzUzjK8u4HJvQgAkSh9QiI8iDBWNNNGvndUkqe4JWztFwG+VM61?=
 =?us-ascii?Q?snVyttuxjIpO/XszlBp2wq4mOaAwBiEe1foJdm22ktYlJq6/gBqln9KZZZRL?=
 =?us-ascii?Q?OpB3dvRieykjjxv5BD7qfSbLs5/xpDAMvjpZB9imIP/wAN+wqn/mkVDfDQvx?=
 =?us-ascii?Q?jOU83ElxPY6ET9GYSR+IGePYuaPZVQLUBTm0M5I5pgaC8W2StR+nVne3c78H?=
 =?us-ascii?Q?3zrJV4LCU6+B5bQjehoiiSNB6UKr/D9WVluZDUQV2nFlzWyWT6nRQs0fBSxR?=
 =?us-ascii?Q?d96W50OnJbzPI3tJEHYZ3Z1XU9NSKvHT3dh5dA+Pcaoear0mu2UZlAo+2x9z?=
 =?us-ascii?Q?c6tLqvM150U34FXuP+vweFsGPVPcd7cWTPVMzW1KfWhaHCztzQrk0na8h0VJ?=
 =?us-ascii?Q?SKG1rr2phaUb5Wqzx0dYP5dN5S8FlQoR3Wxv8PxdUcSkMPFBPDmhNVcfGYCm?=
 =?us-ascii?Q?9h06/GYyNxHs5WRtOcWmKvO4bRmAP6Kaye0Z7GshR2BLeEdivDqocYEHTXKo?=
 =?us-ascii?Q?5C+sQpocIiLMtbCQJN/KWrTLoX7qw+YjQBq6KIMcVABKkItH0aPpiTeIXvDW?=
 =?us-ascii?Q?BAJrOiPWZSrVyA4f+n6Wi8IRnYyTALkwrIxch/4m+iYAsIcFgky10rQ4DjjN?=
 =?us-ascii?Q?/zIJPWiZ3KXVNkpZDCNPozWQGwfcV3Lkp0dWrQ4Xc1fdCnf8bXVmLBEMuYm9?=
 =?us-ascii?Q?bhdMuv1GsdBhDse74TatqNtEKkghomJotxuFsrltOa6cwv+O6HeSG/ecGkzy?=
 =?us-ascii?Q?KE4eRkPBqxd0pdVdeUXTErKnLGkKY7b0ToMovnsLMJY6Y0uSfOdxHfqDve5X?=
 =?us-ascii?Q?PHb9XiDr6JuCujyA4N5zYT4D+KQ/e0Jv21ir8pgMI1Svte9IGJoxVZh+i45Z?=
 =?us-ascii?Q?DYoxZ9aKu+5cX/94VpeJsw9I7EF7ZLMs2JSDMojaPWQJJt/obBLWqtpVz4pf?=
 =?us-ascii?Q?3Zp4YYBuzZwvUqe60HbaQaP6pe/32ekbIuDPG6PBhc3WnpW91u6CMfNagWnb?=
 =?us-ascii?Q?zGQtlsswZ3qpzROHn+KfBg1ITEGjGrAY+9fFS7W/C3tz+cerfJs9ZEQ6mCLb?=
 =?us-ascii?Q?rUVTkiDMk1IVS8vcZ4W85z3LIXdRFoDTCIQ+HQ1w9Gg4q1sKIiZgrL49sN2z?=
 =?us-ascii?Q?Zvx0uIc1Eb5I0A2I41hi5BJpSyBUoWbwBPw68YvGhnQa3g7r/sNN3DXy5Dqj?=
 =?us-ascii?Q?HQ7DzXhKkvtHfZS9oTGtm8NHBab6cJ9eBRnf8ld4ruKV5t1d4E2/+RwZLhIH?=
 =?us-ascii?Q?mRSfu+jrbpxkradFxLgEA8A=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fe46aeaf-b034-49ab-5ace-08d9efb5e184
X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB5138.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2022 12:31:10.5054
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /AIc4+GOK0EwmY4Xxe55zuDwTGRN54MIcXsWMu3+NE8m9ATR07ppmhSsq8Defd2ahOOOGtOmatGq7/l1R2FJAA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR10MB5397
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10257 signatures=673431
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0
 mlxlogscore=999 bulkscore=0 spamscore=0 adultscore=0 mlxscore=0
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2201110000 definitions=main-2202140076
X-Proofpoint-GUID: 2OD3VSLPcMxkbUX7Q_C_TTApwHdP89tw
X-Proofpoint-ORIG-GUID: 2OD3VSLPcMxkbUX7Q_C_TTApwHdP89tw
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On Tuesday, 2021-11-23 at 23:41:23 -05, Eric Snowberg wrote:
> A new Machine Owner Key (MOK) variable called MokListTrustedRT has been
> introduced in shim. When this UEFI variable is set, it indicates the
> end-user has made the decision themselves that they wish to trust MOK keys
> within the Linux trust boundary.  It is not an error if this variable
> does not exist. If it does not exist, the MOK keys should not be trusted
> within the kernel.
>
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

Reviewed-by: Darren Kenny <darren.kenny@oracle.com>

> ---
> v1: Initial version
> v2: Removed mok_keyring_trust_setup function
> v4: Unmodified from v2
> v5: Rename to machine keyring
> v6: Unmodified from v5
> v7: Use mokvar table instead of EFI var (suggested by Peter Jones)
> v8: Unmodified from v7
> ---
>  .../platform_certs/machine_keyring.c          | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/security/integrity/platform_certs/machine_keyring.c b/security/integrity/platform_certs/machine_keyring.c
> index ea2ac2f9f2b5..09fd8f20c756 100644
> --- a/security/integrity/platform_certs/machine_keyring.c
> +++ b/security/integrity/platform_certs/machine_keyring.c
> @@ -5,6 +5,7 @@
>   * Copyright (c) 2021, Oracle and/or its affiliates.
>   */
>  
> +#include <linux/efi.h>
>  #include "../integrity.h"
>  
>  static __init int machine_keyring_init(void)
> @@ -40,3 +41,21 @@ void __init add_to_machine_keyring(const char *source, const void *data, size_t
>  	if (rc)
>  		pr_info("Error adding keys to machine keyring %s\n", source);
>  }
> +
> +/*
> + * Try to load the MokListTrustedRT MOK variable to see if we should trust
> + * the MOK keys within the kernel. It is not an error if this variable
> + * does not exist.  If it does not exist, MOK keys should not be trusted
> + * within the machine keyring.
> + */
> +static __init bool uefi_check_trust_mok_keys(void)
> +{
> +	struct efi_mokvar_table_entry *mokvar_entry;
> +
> +	mokvar_entry = efi_mokvar_entry_find("MokListTrustedRT");
> +
> +	if (mokvar_entry)
> +		return true;
> +
> +	return false;
> +}
> -- 
> 2.18.4