Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp287231pxk; Wed, 2 Sep 2020 00:56:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxBP7GOWc3uWWxG6Wbp8cebRx0k4qoKeqpIs7RBen4y0tqZyqv9rI4gGLppFrvJYcD7Ox1C X-Received: by 2002:a50:bb26:: with SMTP id y35mr5493088ede.234.1599033404018; Wed, 02 Sep 2020 00:56:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599033404; cv=none; d=google.com; s=arc-20160816; b=HvoYlowB2iuOSkLKVMDzHead+Z9dvtjndICfSqTnuYcmn+Tt1OEyGwLoQze5jS+xZl fyYAl8zF4Hnz++rKZ2hdgF8cMR4/lxABHxHnRZmlDzacCk33pcgs3rFKfTHwgpfhqw+4 UnGKgHEt81jakzqivGl2lOp6pzx30xcZcnh1Z4zMMIbiukJNgH2+Mvt4h93vZ8I6rTPL 4w3RtvMISc3bcMeV4rSQQj3X3zaXWn9MrNOHGBzM2Yr390CsKqG2FCrJBlWqGfyPG6SR PfWg752r2Ks6QvudrQY3XMtx1wFjszAr8MDO8QDrAXgNhrACYue11DPblvwjS6uQGTxn LNmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Vv9wafYlcRndezilwjOVw+Uvg14avW3QcJVd3Hrp9X0=; b=wmjXyF7UR2A9FdYEaOPrNpT3B6xNveIXStHGaX3uUT7JwSj8GMkZ9Dbak9E2jdoWqR 5zmUBr0NvEtsjnlpY5DzaEgxuEsrx3FRuRZCFClBMSrfJTwhxx93JFW7Pbnv6QNv0vWO V2StFIDLI8VKQ/TGmj/9cHPjyk9nun1pd//kmStIEf6CAFAiw8IsPPD74xfnuN7lWQH+ bQWKIi6VTe17UmKph4ELrv97H6TnEIUwRIT8+8Dt2eRqTRC+mZ4oNFUluS7U/Ou7K1L+ QH7tizJQNKEKb+C3v2qG5M9p6qde0895/rwtUWpprUagkElMkK0Qe6P3kYSYXaS+QnFk nl/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dUhRbwVR; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j7si2254608ejm.538.2020.09.02.00.56.21; Wed, 02 Sep 2020 00:56:44 -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=pass header.i=@gmail.com header.s=20161025 header.b=dUhRbwVR; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726913AbgIBHzo (ORCPT + 99 others); Wed, 2 Sep 2020 03:55:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36632 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726167AbgIBHzi (ORCPT ); Wed, 2 Sep 2020 03:55:38 -0400 Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 802EAC061244; Wed, 2 Sep 2020 00:55:38 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id q3so1906061pls.11; Wed, 02 Sep 2020 00:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vv9wafYlcRndezilwjOVw+Uvg14avW3QcJVd3Hrp9X0=; b=dUhRbwVRhGDqCmPDJulA9D1NH7C7y9XHVxD2cCdGOWci+8hb5IympO9z/mRng67H8/ EdOTtIbOUtlS0mzLi//6vD4CigO1owTjoWyCjHgRxEoqhFi1zxwgFApN05D3L06ODh+s AVvnjlPrW+HYJTAL/8YojwCSWZA0hmWlOyI4Z0ujWxLb7QaZJHPkmOvkknBkjULMUk8O vZCA+YksoU5lSSMLMuTxe0RWE+SopR/Bz0y9IzEH472wSI8+jrXlqe5BwxCUUpZ/v2qU 95IpUaWjKi1whSEN6uAGZZ96PnIq+fl78D9OB6zeF8Yss0rzX0NdmyXMSAg8XGrUO6+9 /VDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vv9wafYlcRndezilwjOVw+Uvg14avW3QcJVd3Hrp9X0=; b=IRLT6+5EpSjhCNN2Y+fuqxvT2I7RU50cwxBbtEOS8deSGrJwEGlRdPApKzPES+ZLyO SFnp5iWtdGg8iIFlyjQXPH++EoPKxfbxZv5RGcYNc0oEYbru4GZwC/1QqaogidogrYgh gABgTyJvETFXBA65OhtSvaPW08EmiHELT5adZqNP267l2b6+KAkFfUNQ7bj3YP0JJoVN pXQh0FaX2pI/zblAIl+lz24ALGt6c38x1X9kL7nNmYpanp8pZDEM2bG9dEvD8i0VQtZ6 CpZBvw1AObVOEwFuoUxmH7dGSMQo51ZXaFY2WMeSept7X+IBO3t+sg1IftDnDOoziV0T O/ZQ== X-Gm-Message-State: AOAM532Gw5cmG/vr2kwCptWuwxHS4t3hqvTTpVUb3dnMSu6fyjGqjIxc RAVGU/Z2oW5Fzh/AIiF60mnxwt+NnnH5bZuPAWkmNH2bPx8= X-Received: by 2002:a17:902:b715:: with SMTP id d21mr1104159pls.92.1599033338028; Wed, 02 Sep 2020 00:55:38 -0700 (PDT) MIME-Version: 1.0 References: <20200826034455.28707-1-lszubowi@redhat.com> <20200826034455.28707-3-lszubowi@redhat.com> In-Reply-To: <20200826034455.28707-3-lszubowi@redhat.com> From: Andy Shevchenko Date: Wed, 2 Sep 2020 10:55:21 +0300 Message-ID: Subject: Re: [PATCH 2/3] integrity: Move import of MokListRT certs to a separate routine To: Lenny Szubowicz Cc: Linux Kernel Mailing List , linux-efi , Platform Driver , linux-security-module , Ard Biesheuvel , James Morris , "Serge E. Hallyn" , Kees Cook , Mimi Zohar , Borislav Petkov , Peter Jones , David Howells , Prarit Bhargava Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 26, 2020 at 6:45 AM Lenny Szubowicz wrote: > > Move the loading of certs from the UEFI MokListRT into a separate > routine to facilitate additional MokList functionality. > > There is no visible functional change as a result of this patch. > Although the UEFI dbx certs are now loaded before the MokList certs, > they are loaded onto different key rings. So the order of the keys > on their respective key rings is the same. ... > /* > + * load_moklist_certs() - Load MokList certs > + * > + * Returns: Summary error status > + * > + * Load the certs contained in the UEFI MokListRT database into the > + * platform trusted keyring. > + */ Hmm... Is it intentionally kept out of kernel doc format? > +static int __init load_moklist_certs(void) > +{ > + efi_guid_t mok_var = EFI_SHIM_LOCK_GUID; > + void *mok = NULL; > + unsigned long moksize = 0; > + efi_status_t status; > + int rc = 0; Redundant assignment (see below). > + /* Get MokListRT. It might not exist, so it isn't an error > + * if we can't get it. > + */ > + mok = get_cert_list(L"MokListRT", &mok_var, &moksize, &status); > + if (!mok) { Why not positive conditional? Sometimes ! is hard to notice. > + if (status == EFI_NOT_FOUND) > + pr_debug("MokListRT variable wasn't found\n"); > + else > + pr_info("Couldn't get UEFI MokListRT\n"); > + } else { > + rc = parse_efi_signature_list("UEFI:MokListRT", > + mok, moksize, get_handler_for_db); > + if (rc) > + pr_err("Couldn't parse MokListRT signatures: %d\n", rc); > + kfree(mok); kfree(...) if (rc) ... return rc; And with positive conditional there will be no need to have redundant 'else' followed by additional level of indentation. > + } > + return rc; return 0; > +} P.S. Yes, I see that the above was in the original code, so, consider my comments as suggestions to improve the code. -- With Best Regards, Andy Shevchenko