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 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C396DC05027 for ; Mon, 23 Jan 2023 08:15:50 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 036E7856F4; Mon, 23 Jan 2023 09:15:49 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="fh20G3sM"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2D3EB856F6; Mon, 23 Jan 2023 09:15:47 +0100 (CET) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 34BD8856F3 for ; Mon, 23 Jan 2023 09:15:44 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ilias.apalodimas@linaro.org Received: by mail-ej1-x630.google.com with SMTP id kt14so28350694ejc.3 for ; Mon, 23 Jan 2023 00:15:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+ur3p5Gcb9s/GslQozIRjrspx7YzZu9sF9AMEc2h3Ow=; b=fh20G3sM497ZGyG26KEafCL1AkFa4jOipu+133Fj7zjeQvbMC0tKaplVabXscidCMc 3O8QwhkeMa+mj40mGFrSW5c3UJKpmzEMLn++KkZCpR6rS8h+VbctbeoTCjXeHUXlWgNH i0K0o+Er51I5a58IoOO3EY1vxC+MxAE32WVumBog977sa4w6oVy1eyludpgrU/duQOYr nA9zBWMyME7WUqppSZy/tlEDW6BdcNphGFBemsRBh5Dt6FhUK0Lr6lHSGl76J0Ttnz3J ZpQjNpG7cLrqvNdjUkkEIPuG1+2sxCXd08+KImChX64OTweN56HozIKHaQL6+e4rcKtV Hlww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+ur3p5Gcb9s/GslQozIRjrspx7YzZu9sF9AMEc2h3Ow=; b=v+o2+ksAv6ASwlUb7jtBoB+CoLyXWqJtMAVLT/TOd5ET0mNsyWOnRzNTcbOGEMtt3W Kce2Oy8FpyBkA83qM3Gf+AMLuqT3LMorpTgBtHDlJ8Nnln6R/3lHCxTInRF+QqgCJ9yv bmPcTMu83IJ89ygWEpDiHRakLUofhgwqZcXczoTOMRT3ZKRdaVN9jj0vf3Mutun6MDBr XUl+BV14u0C7F9gLLUW6FbA/UwMSfxluDMHJoLIeACvCFU27YSpiMAmlY3lv42eNeoZH KzN2xBtwdupk6eLzrR7g76xfF95+7IEJQiugNrUb2+fcsLj47zQWQN1pqBANNydwOe+M +sNA== X-Gm-Message-State: AFqh2krFiri8ew+GFOL+ue/mMScn+htDuZ7y0drmWFY795TT/7FoLveu txnKSvuvPVp2kOmOpwqAEF79uA== X-Google-Smtp-Source: AMrXdXvTRj/Sip95obWG+Kv4dq/VCV3ShEr4LHxbNHfRY1YeELx6YeQTX76laOOsOHVTARZS65ZE0w== X-Received: by 2002:a17:906:f753:b0:7c4:edee:28c0 with SMTP id jp19-20020a170906f75300b007c4edee28c0mr25593094ejb.24.1674461743683; Mon, 23 Jan 2023 00:15:43 -0800 (PST) Received: from hera (ppp079167090036.access.hol.gr. [79.167.90.36]) by smtp.gmail.com with ESMTPSA id k6-20020a17090632c600b008779eb0fd83sm4739001ejk.23.2023.01.23.00.15.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Jan 2023 00:15:43 -0800 (PST) Date: Mon, 23 Jan 2023 10:15:40 +0200 From: Ilias Apalodimas To: Simon Glass Cc: Heinrich Schuchardt , u-boot@lists.denx.de, Pali =?iso-8859-1?Q?Roh=E1r?= , Masahisa Kojima , AKASHI Takahiro , Sughosh Ganu , Etienne Carriere , Patrick Delaunay Subject: Re: [RFC PATCH 1/1] efi_loader: get rid of ad-hoc EFI subsystem init Message-ID: References: <20230120123120.1014589-1-ilias.apalodimas@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean Hi Simon, Heinrich On Fri, Jan 20, 2023 at 03:11:13PM -0700, Simon Glass wrote: > Hi Heinrich, > > On Fri, 20 Jan 2023 at 13:36, Heinrich Schuchardt wrote: > > > > On 1/20/23 20:19, Simon Glass wrote: > > > Hi, > > > > > > On Fri, 20 Jan 2023 at 06:03, Heinrich Schuchardt wrote: > > >> > > >> Am 20. Januar 2023 13:31:19 MEZ schrieb Ilias Apalodimas : > > >>> Up to now the EFI subsystem was left out of the main U-Boot init > > >>> process. This has led to various hacks over the years, with the most > > >>> notable one being sprinkling around the efi init call to various places > > >>> such as U-Boot commands, the early boot code etc. > > >>> > > >>> Since EFI has it's own Kconfig option and people can remove it, let's > > >>> wire up the EFI init call on an event for EVT_MAIN_LOOP. > > >>> > > >>> This will also get rid of ad-hoc code in the main event loop, which was > > >>> trying to initialize the subsystem early and perform capsule updates. > > >>> > > >>> TODO: > > >>> - The efi_tcg protocol implicitly initializes the TPM, as a result > > >>> some of the tpm selftests will fail with the RFC. If everyone > > >>> agrees that this is a good idea, I'll clean up the TPM hacks as well > > >>> - We still need to run capsule updates on the main_loop() code since > > >>> in some cases (e.g sandbox) we need preboot commands. > > >>> - wider tests, I've only run QEMU for now > > >>> > > >>> Signed-off-by: Ilias Apalodimas > > >> > > >> > > >> In case of efi_init_obj_list() failing we should still reach the U-Boot console but each of the EFI commands should abort early. > > >> > > >> Please, put the Kconfig related capsule change into a separate patch. > > >> > > >> Otherwise looks good to me. > > >> > > > > > > I am OK with this change too. > > > > > > Two points from my side: > > > > > > 1. The main loop capsule update is (still) a mistake, unfortunately. > > > It should be a command which is run on boot. For sandbox testing, that > > > command should be run *without* rebooting. I am sure I asked for that > > > > Capsule updates must run outside of any command as this is required by > > the UEFI specification. Yes it's still a mistake but we can't get rid of it easily. What I was going to try is add another event notifier which would run post boot. That would work and allow us to define events, after the preboot commands have executed. Simon there *is* a command do that. It's documented in [0]. The tl;dr is run: => efidebug boot add 0 Boot0000 virtio 0:1 => efidebug boot next 0 => setenv -e -nv -bs -rt -v OsIndications =0x0000000000000004 => efidebug capsule disk-update The command exists for testing, but as Heinrich explains, we also need to test the automatic upgrade after a reboot since that's what the EFI specification expects. > > What do you mean? Does the specification mention U-Boot commands? > > > > > Capsule updates require a reboot and the sandbox must behave as a > > regular system so that we can run the same tests on all systems. > > How can I get you past this thinking? We need to 'design for test'. > The current test is a mess, sorry. Perhaps we could have a call to go > through it? > > > > > > at the time but for various reasons it didn't happen. Please can you > > > make that change also? > > > > > > 2. EFI should not be maintaining its own separate data structures, but > > > should keep them attached to driver model. They should be created as > > > needed, dynamically, not all at the start. Is anyone looking at this? > > > I am happy to help suggest initial target for this refactoring. This patch doesn't change anything wrt to structures or how it interacts with DM. That's a different topic, but since there has been no progress apart from block devices for a while, I'll start looking into it myself. FWIW I agree we should refactor the protocol registration and match what U-Boot does with the rest of the DM. > > > > We have started with such a link for block devices. Once those block > > devices are really UEFI compliant we should refactor the other devices > > currently supported by EFI sub-system: > > > > UART, network, RNG, video, TPM. > > > > Some initialization like setting up UEFI variables will not have any > > equivalence in the driver model. > > One way to handle that is to: > > - set up 'global' EFI structures attached to an EFI uclass > - set up 'per device' EFI structures when the device is bound or probed > > Regards, > Simon Can we do this is small steps since I prefer testing everything thoroughly and making sure the EFI init doesn't break? So my plan is to resend this, fixing any TPM selftest regressions and then start cleaning up the protocol registration. [0] https://u-boot.readthedocs.io/en/v2021.04/board/emulation/qemu_capsule_update.html Regards /Ilias