linux-kernel - Re: [PATCH v8 3/4] efi: Load efi_secret module if EFI secret area is populated

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]

Date:   Mon, 28 Feb 2022 14:15:38 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Dov Murik <dovmurik@...ux.ibm.com>
Cc:     linux-efi <linux-efi@...r.kernel.org>,
        Gerd Hoffmann <kraxel@...hat.com>,
        Borislav Petkov <bp@...e.de>,
        Ashish Kalra <ashish.kalra@....com>,
        Brijesh Singh <brijesh.singh@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andrew Scull <ascull@...gle.com>,
        Dave Hansen <dave.hansen@...el.com>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        Lenny Szubowicz <lszubowi@...hat.com>,
        Peter Gonda <pgonda@...gle.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        James Bottomley <jejb@...ux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@...ux.ibm.com>,
        Jim Cadden <jcadden@....com>,
        Daniele Buono <dbuono@...ux.vnet.ibm.com>,
        linux-coco@...ts.linux.dev, linux-security-module@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8 3/4] efi: Load efi_secret module if EFI secret area is populated

On Mon, 28 Feb 2022 at 14:07, Dov Murik <dovmurik@...ux.ibm.com> wrote:
>
>
>
> On 28/02/2022 14:49, Ard Biesheuvel wrote:
> > On Mon, 28 Feb 2022 at 12:43, Dov Murik <dovmurik@...ux.ibm.com> wrote:
> >>
> >> If the efi_secret module is built, register a late_initcall in the EFI
> >> driver which checks whether the EFI secret area is available and
> >> populated, and then requests to load the efi_secret module.
> >>
> >> This will cause the <securityfs>/secrets/coco directory to appear in
> >> guests into which secrets were injected; in other cases, the module is
> >> not loaded.
> >>
> >> Signed-off-by: Dov Murik <dovmurik@...ux.ibm.com>
> >> Reviewed-by: Gerd Hoffmann <kraxel@...hat.com>
> >
> > It would be better to simply expose a platform device and associated
> > driver, instead of hooking into the module machinery directly.
> >
> > We already do something similar for the EFI rtc and the efivars
> > subsystem, using platform_device_register_simple()
> >
>
> Thanks Ard, I'll look into this.
>
> I hope the mechanism you suggest allows me to perform complex check to
> see if the device is really there (in this case: check for an efi
> variable, map memory as encrypted, verify it starts with a specific GUID
> -- everything before request_module() in the code below).
>

There is the device part and the driver part. Some of this belongs in
the core code that registers the platform device, and some of it
belongs in the driver. At this point, it probably does not matter that
much which side does what, as the platform driver simply probes and
can perform whatever check it needs, as long as it can back out
gracefully (although I understand that, in this particular case, there
are reasons why the driver may decide to wipe the secret)