Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1023677pxk; Fri, 18 Sep 2020 01:32:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwTCNyGbw4amaVv5A8BlJofEQ7RDHaVJ189V8ZS3at+bB/3StQ5yU3yMzSfZr6uG24czTZX X-Received: by 2002:a50:ce4e:: with SMTP id k14mr12918796edj.177.1600417965214; Fri, 18 Sep 2020 01:32:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600417965; cv=none; d=google.com; s=arc-20160816; b=ANLMaAE8zBszcJJPF4+NPKf+wEKuNuiuwkWy5PLvZgdOxfI1dE3X0PgQ2Xf3Z3r7FY t2ZTSIDddyeVwoyEqNjdMRIHHux1cBVBGchF/cOTqUL9sesod9D4If5JTSB2dlVIpUeB KITlsnf8Mst+6hziHGEsxrOAfdbt0Ml2/fHo4aB94uPHtjg2jPvC9QL6EFvrm+ktcBfj 3DQCMDMYoKgIEmIEgUsyXHuJGQ4ERE+g9XO0uD3lXMX86a2cHyMx1XZth/MTrHyC6Itw iJTBr4C7LwLcRa7y8Zsq0PDCLHE1A0qSB/81XQ0x+efeVFDKfNAhk90CmTORHQ0hMq99 hrGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:robot-unsubscribe :robot-id:message-id:mime-version:references:in-reply-to:cc:subject :to:reply-to:from:dkim-signature:dkim-signature:date; bh=bu8hCDfmfONQdGPMFOoROjhn29gXANXvs04IakJ+o8g=; b=Po41kEHpV0UZFmCSWmxawrn76bvfLgAf++jypDCbUa18+om3IiXDw3abICq0A//zZ2 VvmvdVA7ffRIvNXjnevHSoqufP9Jdo/FgI/u++eXRAKWF7rJrZV8ejYA3l1SPTQOAAvU bDuEHG9MoUS1J5r+p/MfgT9DRHdZvEl4UM+N+4zSzsRjYw8pTDvJptEpUbxM65yRLw8D EHbSqHX5qxG+vGB3iOfcFtQY1Xi9fBIabNw8hO6WabiX//ZznCnfpsxNKutC/ex43+0I rN+RIzyPaKElPBp8d2+p+lis507EhFHHdunBIykFCzG6asi60SNsZ5lEoC/dwgJluFUg WDrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@linutronix.de header.s=2020 header.b="mGj/65zS"; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=v321Kd9G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g1si1643543ejz.637.2020.09.18.01.32.21; Fri, 18 Sep 2020 01:32:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@linutronix.de header.s=2020 header.b="mGj/65zS"; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=v321Kd9G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726427AbgIRIa7 (ORCPT + 99 others); Fri, 18 Sep 2020 04:30:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726434AbgIRIa4 (ORCPT ); Fri, 18 Sep 2020 04:30:56 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1D80C061756; Fri, 18 Sep 2020 01:30:55 -0700 (PDT) Date: Fri, 18 Sep 2020 08:30:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1600417854; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bu8hCDfmfONQdGPMFOoROjhn29gXANXvs04IakJ+o8g=; b=mGj/65zSbf3czpGOgOWBhCOv/T0cEIlOHKzIwIZdQqnir348KIhh3AC0VgvuvNVpqraOR3 hUMTx1C3z1DrFGYeI+pyqedXJyVe7rj+FYSM4m91bT3xJfixLrQ/o4eiyXiCmPs9juEDFR xlZI6YTSDuiw85e3OxnfYirRn+J168ymoYSvdphk8Oa/bdeD7l6NWMF2NjT4avGql5loIk hZnTXqkj4x8xa/rMoONiEYiCiosNTHU8OhnssApLna704gh4Th0Fri255XjITXSCojw/zE WVxZFTt0Jo6ERa5/03Tp9ZlSjDm+27rGN2iKKqF/Y4yJnpGvSnPY8xxRHic7TA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1600417854; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bu8hCDfmfONQdGPMFOoROjhn29gXANXvs04IakJ+o8g=; b=v321Kd9GbGgX1CW/QgJBT/O8ykC5I+2EK2Fj9q+uRBtZeu+13KcZqRx5/5b8sPhm0CJsqX hsu2SJHrMo5TaWCw== From: "tip-bot2 for Lenny Szubowicz" Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: efi/core] integrity: Load certs from the EFI MOK config table Cc: Lenny Szubowicz , Ard Biesheuvel , x86 , LKML In-Reply-To: <20200905013107.10457-4-lszubowi@redhat.com> References: <20200905013107.10457-4-lszubowi@redhat.com> MIME-Version: 1.0 Message-ID: <160041785349.15536.8943726923312699440.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the efi/core branch of tip: Commit-ID: 726bd8965a5f112d9601f7ce68effa1e46e02bf2 Gitweb: https://git.kernel.org/tip/726bd8965a5f112d9601f7ce68effa1e46e02bf2 Author: Lenny Szubowicz AuthorDate: Fri, 04 Sep 2020 21:31:07 -04:00 Committer: Ard Biesheuvel CommitterDate: Wed, 16 Sep 2020 18:53:42 +03:00 integrity: Load certs from the EFI MOK config table Because of system-specific EFI firmware limitations, EFI volatile variables may not be capable of holding the required contents of the Machine Owner Key (MOK) certificate store when the certificate list grows above some size. Therefore, an EFI boot loader may pass the MOK certs via a EFI configuration table created specifically for this purpose to avoid this firmware limitation. An EFI configuration table is a much more primitive mechanism compared to EFI variables and is well suited for one-way passage of static information from a pre-OS environment to the kernel. This patch adds the support to load certs from the MokListRT entry in the MOK variable configuration table, if it's present. The pre-existing support to load certs from the MokListRT EFI variable remains and is used if the EFI MOK configuration table isn't present or can't be successfully used. Signed-off-by: Lenny Szubowicz Link: https://lore.kernel.org/r/20200905013107.10457-4-lszubowi@redhat.com Signed-off-by: Ard Biesheuvel --- security/integrity/platform_certs/load_uefi.c | 22 ++++++++++++++++++- 1 file changed, 22 insertions(+) diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c index c1c622b..ee4b4c6 100644 --- a/security/integrity/platform_certs/load_uefi.c +++ b/security/integrity/platform_certs/load_uefi.c @@ -71,16 +71,38 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid, * Load the certs contained in the UEFI MokListRT database into the * platform trusted keyring. * + * This routine checks the EFI MOK config table first. If and only if + * that fails, this routine uses the MokListRT ordinary UEFI variable. + * * Return: Status */ static int __init load_moklist_certs(void) { + struct efi_mokvar_table_entry *mokvar_entry; efi_guid_t mok_var = EFI_SHIM_LOCK_GUID; void *mok; unsigned long moksize; efi_status_t status; int rc; + /* First try to load certs from the EFI MOKvar config table. + * It's not an error if the MOKvar config table doesn't exist + * or the MokListRT entry is not found in it. + */ + mokvar_entry = efi_mokvar_entry_find("MokListRT"); + if (mokvar_entry) { + rc = parse_efi_signature_list("UEFI:MokListRT (MOKvar table)", + mokvar_entry->data, + mokvar_entry->data_size, + get_handler_for_db); + /* All done if that worked. */ + if (!rc) + return rc; + + pr_err("Couldn't parse MokListRT signatures from EFI MOKvar config table: %d\n", + rc); + } + /* Get MokListRT. It might not exist, so it isn't an error * if we can't get it. */