Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp2755468pxm; Mon, 28 Feb 2022 05:34:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJyXPVKRwdqgbgNN2SZAKqcN4Er8iwrxQ5ADQWAesdKV5WoDifDfvGgLKuVK/zJYJOKka73l X-Received: by 2002:a17:906:3583:b0:6d1:c07:fac0 with SMTP id o3-20020a170906358300b006d10c07fac0mr15202949ejb.749.1646055295768; Mon, 28 Feb 2022 05:34:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646055295; cv=none; d=google.com; s=arc-20160816; b=PmW6iviLRTBEKdCpUlgWEcP6kRAAX8e2NyHq8fEjOpqFSCajS1bRBXyini3SI2I0Q5 pyejigWjeo7hby5TQzNG7zRJ+scYEFhlKhvXKFkVDS9hbtsk9AxxJF0q4QiNeh/YBQpQ JzCcBOWbXlUA1dBgo+LfB7mz/mzKRMDjZPmdPFB4hyXCZlfY9RnfkIgZAil75hCwlBYj t1O3kViDFWUcKVQ9Dga8029YyhUMq1ZM0CEz5dY5vjGFIgE78yi1VQuKGfrzq138BYkk R0PM70k1cwotaCgPPoUjzIABbh9VS4Cl5evreMsmsWtYxgBDzpJvdWcsqei0xKZcOkAG 5ABg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=XC7q336p+3yz9SXS9ZVHG+qns5z7lvEURk+VZZRcFRw=; b=fAb4DoysVRLm4SrFDSspGl1I8VOSYaZ//D0Z77HJMC0PG/GnFEtQZR0CtD4LcMvb5P 24ZIp79rJNxDIjKTGQ/nTiBNrPgG5QnUopYPbkXbxl2Kr9ArO3+cmC+juyElkJW9rP50 x60iowCkmwkXF8/m0fyQkD8Qap/CWG31c5kb2KHvbhCoJF4/L8jZAKomqPX4g6rBxJXt BPxcvJBA1zosdMAZsJIFOP1XlbrtFqWXd/mH1OVZFQLW7UWlDiTTJs+L/pWn02rwLxoh ME9MJIYizIUOQ9nOy1KT3wX6+916LYnXahTHqoGwa5/0wfAWkApGOP0BJ+cu/Mxyx5jd cV6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=cbQVeAU4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r10-20020a1709062cca00b006cd3404e99asi5512537ejr.549.2022.02.28.05.34.32; Mon, 28 Feb 2022 05:34:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=cbQVeAU4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235143AbiB1NQs (ORCPT + 99 others); Mon, 28 Feb 2022 08:16:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235145AbiB1NQc (ORCPT ); Mon, 28 Feb 2022 08:16:32 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 192327462B; Mon, 28 Feb 2022 05:15:53 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BD26FB810BF; Mon, 28 Feb 2022 13:15:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58204C340FA; Mon, 28 Feb 2022 13:15:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646054150; bh=XC7q336p+3yz9SXS9ZVHG+qns5z7lvEURk+VZZRcFRw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=cbQVeAU4fSucwMwELJ2chTApjPOmF9JV0Bq5ZQ+SLVOeuzaOEKn8OCD86frbDeTUk 178U9AVLlTn39ViS32nJUTew0lzqS0jEupKT5cWc6LEotoNepUDqIRFs1QMgCAZqwx lSVS7McGv8T6ZJozZAKgUq3qSTypblHzo+rQT6jKX2qMjcv7/BzzwzRNf/ehHJsFwy TrYWKm3uuTvPQeKUbg0ZQ9XNnfYzV08QCcZMEqRtap0GeIWlSA8b2rEJ86yhe++kUc iwE1ZQoB7T4QjP+wBxCAa7/jzm60j0NngX0Od+S4/ZGoOHVCr+6Ed/e/QbPitjMKnv 8eVyCwaim79Rg== Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-2d68d519a33so107434077b3.7; Mon, 28 Feb 2022 05:15:50 -0800 (PST) X-Gm-Message-State: AOAM531Hz/vKOguZ3KM81OEHHNGQfvICmmqjzQbCACzOungT0pRcZfW8 km1JLL7OFBA1r76Dk1nwMJUnnr7VwlW1hz3WFc8= X-Received: by 2002:a81:7d04:0:b0:2d0:d0e2:126f with SMTP id y4-20020a817d04000000b002d0d0e2126fmr19559172ywc.485.1646054149209; Mon, 28 Feb 2022 05:15:49 -0800 (PST) MIME-Version: 1.0 References: <20220228114254.1099945-1-dovmurik@linux.ibm.com> <20220228114254.1099945-4-dovmurik@linux.ibm.com> In-Reply-To: From: Ard Biesheuvel Date: Mon, 28 Feb 2022 14:15:38 +0100 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" X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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)