From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2FE011FBA for ; Tue, 12 Apr 2022 13:08:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D39BBC385B7 for ; Tue, 12 Apr 2022 13:08:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649768917; bh=YcaQr1zTfjSLiNUXAkZxfTTaYuHy1HUaeyyk2AqglB8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=n2OtpAQoq+qrG0TzI0l8iMD7eTq2ktrCDTJaTsthrBjJGpRfw0n36ACC43KhSFYu8 elNas01Yi2U5Rv8K+NDjzfQsCkpaDm77HkjCagq6lPDc9ljaAa3VRIq/wuZTG3SLBq K7L/rzQhQeMNykf6ALNmVK9+I+bT0i9qH3heMPIZjOpkXxcDKPEL2igyK8nH1YkotE k0pLawXRBkjoL5TAeKQDM3ZdZonfp7BASJv33whnsUke9OFr+MLeQ4nNX7LQ/6N3I+ eSObTl3WDbkHxia2LPOQrWj4htFdaDqp4WD21mFStupsAe913FSkyp8rOXmwGRZUFK ITzadpcQeC75g== Received: by mail-oa1-f46.google.com with SMTP id 586e51a60fabf-ddfa38f1c1so20641078fac.11 for ; Tue, 12 Apr 2022 06:08:37 -0700 (PDT) X-Gm-Message-State: AOAM531gepghspPcFRHKaCV4cnFH1uqw3cs9ZYbumpSYgvEogI5z0OiO qkPDTgmi26v7Y0KCBx5X5U9dbyykjrzIgLicIpg= X-Google-Smtp-Source: ABdhPJwsT60EZGzvKxLvuDXi5RTXFmmCpZlzEo7mi7tnDG3CFikUWPsyoP9BI1LgcHDyPOnKWDH0WJEtwRAPvF8XgIc= X-Received: by 2002:a05:6870:b027:b0:de:7fcd:fabf with SMTP id y39-20020a056870b02700b000de7fcdfabfmr2016587oae.126.1649768916454; Tue, 12 Apr 2022 06:08:36 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20220228114254.1099945-1-dovmurik@linux.ibm.com> <20220228114254.1099945-4-dovmurik@linux.ibm.com> <38daffb6-a72a-87f4-d927-0b857b7b6833@linux.ibm.com> In-Reply-To: <38daffb6-a72a-87f4-d927-0b857b7b6833@linux.ibm.com> From: Ard Biesheuvel Date: Tue, 12 Apr 2022 15:08:25 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 3/4] efi: Load efi_secret module if EFI secret area is populated To: Dov Murik Cc: linux-efi , Gerd Hoffmann , Borislav Petkov , Ashish Kalra , Brijesh Singh , Tom Lendacky , James Morris , "Serge E. Hallyn" , Andi Kleen , Greg KH , Andrew Scull , Dave Hansen , "Dr. David Alan Gilbert" , Lenny Szubowicz , Peter Gonda , Matthew Garrett , James Bottomley , Tobin Feldman-Fitzthum , Jim Cadden , Daniele Buono , linux-coco@lists.linux.dev, linux-security-module@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" On Thu, 31 Mar 2022 at 11:05, Dov Murik wrote: > > Hello Ard, > > On 28/02/2022 15:15, Ard Biesheuvel wrote: > > On Mon, 28 Feb 2022 at 14:07, Dov Murik wrote: > >> > >> > >> > >> On 28/02/2022 14:49, Ard Biesheuvel wrote: > >>> On Mon, 28 Feb 2022 at 12:43, Dov Murik 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 /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 > >>>> Reviewed-by: Gerd Hoffmann > >>> > >>> 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) > > I finally got to implement this, it seems like it makes the code simple. > Thanks for the advice. > > Just making sure I understand correctly: in this approach this we rely > on udev to load the efi_secret module (aliased as "platform:efi_secret") > and call its .probe() function? If there's no udev, the module will not > be loaded automatically. Did I understand that correctly? > Apologies, I am swamped in email and only spotted this now. This looks good to me: is this what you implemented in the end?