From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E54C3C433E2 for ; Wed, 2 Sep 2020 07:55:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C2A822084C for ; Wed, 2 Sep 2020 07:55:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dUhRbwVR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726882AbgIBHzn (ORCPT ); Wed, 2 Sep 2020 03:55:43 -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-Google-Smtp-Source: ABdhPJxNZ9O3Sj7OvHiGloTdmPJ7LxTz4zR2Er8HbAv/pmqjuckAEtpUdzJasMFcDiKbP+NTn6IiUaUkABxel3cBWdE= 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: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: 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