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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6DECC433F5 for ; Thu, 30 Sep 2021 06:47:16 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 0677361875 for ; Thu, 30 Sep 2021 06:47:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0677361875 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id CDE6181195; Thu, 30 Sep 2021 08:47:13 +0200 (CEST) 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="agXuDHlZ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 14B1F81545; Thu, 30 Sep 2021 08:47:12 +0200 (CEST) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 D4BDC80F1A for ; Thu, 30 Sep 2021 08:47:07 +0200 (CEST) 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-yb1-xb36.google.com with SMTP id 71so10893218ybe.6 for ; Wed, 29 Sep 2021 23:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uow4mCeY/n0y5fHUgqUJ0fX38OR+gpITpRwrVF/gKkI=; b=agXuDHlZ70/kDR+DyCuShfukFdmrQkQ89E3ed5l2okyfOa5G0oZaByyYwRlHU6o8cL G6zpIZSmclAy+im1yQeJzh0klxU0krMyTMNH1LWa05Ow+I74EDoBbk1sJ2P2IY1Xd0Lc puuY529Pt2J6Xcy8fFR0Bq+ugPRVwicc4feOFSn8bOG2DyiG1HtGV9g3bGoSVv0jkHm+ 8XBkVREQys5HfRwr6k1CKuqCPOUFCscdEMlmAOeisoKN3B+4Eeg0uinFwfBfPx5zHici HHAyc7rd/gkrN6UinmkXiT6BtHNSHwEYDzfmENoXv/VgmUblbi8pXxE1SjlrvO0bWflL XcOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uow4mCeY/n0y5fHUgqUJ0fX38OR+gpITpRwrVF/gKkI=; b=f/c/iN1HbSD3hqxkURoULxNMhg8OrGiK1wNDy4f8CZhQtq56lrJdHIH3tka34v1Utj KezruOdirR7UwL6spqluR9ehL5SOVKZSGpdSxNrm+mGMrSZND94X9wLmM4HXRi/QMZpb QlDU2JK1RnHy19oajUelMfuQgYGWvZDWKxNcGyGcF0DDDvnXr18FDQX4Wy5m11KVGIz6 W4EF+i1ltz2MfzFHQ3qX+faPG7UkEvfX4ozbTx86OGxPXzxIYNhtTY3ZVAtzlCIjg70k 4ZDVLvM68Q/F78Qg4S2IqjUAbnh3QM+9Z5sNyg38KSdZ4g7kEqjBXFdB7h3oEqR8eAAm V5sw== X-Gm-Message-State: AOAM532OLYEIj2kV4XVdps4Gf8CZSgMw8lcvT4v/AWw5G46H3ZbcTKKi IoQZ9F1/1lc95ZQLf+l2+l0CEFXQiOXE1+0E7Ox12g== X-Google-Smtp-Source: ABdhPJx1a8JJWN4jv5v3RlwB1ruxp9uNMzid7ZZTBpXgrh73TAzP0NEFsBou/UTHLCIEH/z9WxIQV6FHTkRq6XQ8YQE= X-Received: by 2002:a25:5ec5:: with SMTP id s188mr4676286ybb.79.1632984426277; Wed, 29 Sep 2021 23:47:06 -0700 (PDT) MIME-Version: 1.0 References: <2461183e-ae0a-d8b3-3822-6a06ee90950d@gmx.de> In-Reply-To: From: Ilias Apalodimas Date: Thu, 30 Sep 2021 09:46:30 +0300 Message-ID: Subject: Re: Driver model at UEFI runtime To: Bin Meng Cc: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= , Heinrich Schuchardt , Simon Glass , U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.2 at phobos.denx.de X-Virus-Status: Clean On Thu, 30 Sept 2021 at 09:38, Bin Meng wrote: > > On Thu, Sep 30, 2021 at 2:23 PM Fran=C3=A7ois Ozog wrote: >> >> >> >> Le jeu. 30 sept. 2021 =C3=A0 07:12, Bin Meng a =C3= =A9crit : >>> >>> Hi Heinrich, >>> >>> On Thu, Sep 9, 2021 at 7:16 PM Heinrich Schuchardt = wrote: >>> > >>> > Hello Simon, >>> > >>> > The EBBR specification requires that the UEFI SystemReset() runtime >>> > service is available to the operating system. >>> > >>> > Up to now this has been implemented by overriding function >>> > efi_reset_system() which is marked as __efi_runtime. >>> > >>> > Both ARM and RISC-V support generic interfaces for reset. PSCI for AR= M >>> > and the System Reset Extension for SBI on RISC-V. This has kept the >>> > number of implementations low. The only exceptions are: >>> > >>> > * arch/arm/cpu/armv8/fsl-layerscape/cpu.c >>> > * arch/arm/mach-bcm283x/reset.c for the Raspberry PIs >>> > * arch/sandbox/cpu/start.c >>> > >>> > Bin has suggested in >>> > https://lists.denx.de/pipermail/u-boot/2021-September/459865.html to = use >>> > reset drivers based on the driver model. >>> > >>> > Currently after ExitBootServices() the driver model does not exist an= ymore. >>> > >>> > When evaluating Bin's suggestion one has to keep in mind that after >>> > invoking ExitBootServices() most operating systems call >>> > SetVirtualAddressMap(). Due to the change of the address map all >>> > pointers used by U-Boot afterwards must be updated to match the new >>> > memory map. >>> > >>> >>> Yeah, this was discussed 3 years ago: >>> https://u-boot.denx.narkive.com/mA8xIbLk/efi-loader-runtime-services-im= plementation-broken >>> >>> > The impression that Ilias and I have is that keeping the driver model >>> > alive after SetVirtualAddressMap() would incur: >>> > >>> > * a high development effort >>> > * a significant code size increase >>> > * an enlarged attack surface >>> > >>> > For RISC-V it has been clarified in the platform specification that t= he >>> > SBI must implement the system reset extension. For ARMv8 using TF-A a= nd >>> > PSCI is what ARM suggests. >>> > >>> > So for these architectures we do not expect a growth in the number of >>> > drivers needed. >>> > >>> > Ilias and my favorite would be keeping the design as is. >>> > >>> > What is your view on this? >>> >>> Is U-Boot's UEFI loader implementation supposed to be the recommended >>> UEFI firmware on ARM and RISC-V on a production / deployment system? >> >> For Arm: yes, that is SystemReady spec. > > > How about EDK II? Is EDK II supposed to be used in the server environment= where UEFI + ACPI is the way to go? > Yes ACPI pretty much means EDK2. Specifically for Arm SystemReady-ES/SR (embedded server ready and server ready), require ACPI. Boards passing that certification today use EDK2. > Does any board that ships EDK II with UEFI + DTB? The Socionext SynQuacer box is the only board I know off, that works with EDK2 and can use either DT or ACPI. > Can we safely assume that U-Boot's UEFI loader is the reference implement= ation for UEFI + DTB on Arm? There's even more to that. EDK2 is bound to the PI spec as well as the UEFI spec. U-Boot is a UEFI implementation that doesn't need to adhere to that. Regards /Ilias >>> >>> >>> Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do we >>> expect to load grub.efi which chain-loads a kernel without >>> CONFIG_EFI_STUB? >> >> all paths should be possible , and the shim.efi is to be supported too. = With UEFI, I always see that UEFI is kept down to OS for SecureBoot. In oth= er words I don=E2=80=99t see grub.efi booting a non config_efi_stub. >>> >>> What do distributions normally do? >> >> At least Red Hat made it clear at multiple Linaro Connect that they want= standards, and SystemReady is one that makes the life of embedded distros = easy. >> Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi SecureBo= ot. >>> >>> What's our >>> position when compared to EDK II? >> >> the typical distro boot flow is not the most efficient and drags concept= dating where the Microsoft certs had to be part of the picture. A direct U= -Boot Linux.efi is my preferred; avoids yet another OS in the boot path (gr= ub), avoids convoluted platform cert management (shim) and just enhance sec= urity and boot time. Note: Since kernel 5.10, initrd can be measured (with = TPM) when loaded by efi-stub. > > > Regards, > Bin