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 D8E27C4332F for ; Mon, 19 Dec 2022 14:29:37 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E5BD284F87; Mon, 19 Dec 2022 15:29:34 +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="SPHD9Xey"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id EF768850CB; Mon, 19 Dec 2022 15:29:32 +0100 (CET) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 1B6EB84F6B for ; Mon, 19 Dec 2022 15:29:30 +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-ed1-x52c.google.com with SMTP id c66so13100954edf.5 for ; Mon, 19 Dec 2022 06:29:30 -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=u31B8IQcsRTlmUPMTYGHE97/UMTuzhkz++lWcetHK9A=; b=SPHD9XeyS2jBMQdeExX7CPoYoeRdGeDFcR+x3wpkFzsfirL6vFMC/koS7KJHcnUboV f1hD4hOnEigPyUb+BQdniQiHwysJZ5fmWAFn2JoYVfUaZ12rBPXbyp/5lyqS01wZpr2F /CUbskuL3oSM+l5gXQg3+Qv4Z8rznC/ZeuznkkPuD2U3Dz+FI3LpoxfxDBIMODel0x/Z MSSzcYGUUbVju801eAp7pnFXeYleoDtAbQbWfo6K9iwrczF1n5a642uSktwijRT3fDRn 9D4Kx8Eqx6f9CCuc5glWsT/VXjvUNFh552B2Iar5VET/IYmkqAVymMQMlj4bjpYK6QnH K5Ng== 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=u31B8IQcsRTlmUPMTYGHE97/UMTuzhkz++lWcetHK9A=; b=XtA3shbQCRUmtvkEi20duJ8YwnOtiosGD7/wHJGTA2WEhIdhYniZlP4s5PnGKgUdge rSuguVrYFiFnzjIkEwxDiwOeVKr9BTZrq7KBPMgO4dESGHaPcZHjYqR3xKwi1HyE7EC/ BPJ7W73cR5D/NbSx356tZKPNMtnGmFKRLkYVGLFVkz8kL2Y5zScalIJ9UZ+UiixuP0Vf PyikVUig4mLjyLN6Y+QXUdrAflW7QL+OzrFQovfTfe7N7KeGXHhW1w5swoLNFzrytFfu MQ4SM5svx7bPRgfmqwG/ICUKmNZXZDhZwtbUsmcG0S6yoCmURYRAlFeTDY6gcaVJprSw hCOA== X-Gm-Message-State: ANoB5pnmNq9ETUZNa0IyXKmh03Ugq+bv3TvVquJlsPsUgQfOdX91SOmk 7np9O/m1aTbhNIyENjKTMt0wxQ== X-Google-Smtp-Source: AA0mqf6HK/jWveWD6TAi3vTceZ3tYO2XVLkyV+NXdhzGi5HGkJ7J+W+JoNytQfwlZZqtUH+clyLu6w== X-Received: by 2002:a05:6402:1ccd:b0:461:7d2:c9fc with SMTP id ds13-20020a0564021ccd00b0046107d2c9fcmr36346263edb.26.1671460169648; Mon, 19 Dec 2022 06:29:29 -0800 (PST) Received: from hades (ppp078087234022.access.hol.gr. [78.87.234.22]) by smtp.gmail.com with ESMTPSA id p15-20020a17090653cf00b00809e33ba33dsm2744773ejo.19.2022.12.19.06.29.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Dec 2022 06:29:29 -0800 (PST) Date: Mon, 19 Dec 2022 16:29:16 +0200 From: Ilias Apalodimas To: Hector Martin Cc: Janne Grunau , Heinrich Schuchardt , Mark Kettenis , u-boot@lists.denx.de, sjg@chromium.org Subject: Re: RFC: Handling of multiple EFI System Partitions Message-ID: References: <878rj44wtp.fsf@bloch.sibelius.xs4all.nl> <7FDA0F19-CF1D-4897-A338-DE043E980622@gmx.de> <20221219094817.GA4629@jannau.net> <29ab5607-25da-930b-143b-758c630831f9@marcan.st> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29ab5607-25da-930b-143b-758c630831f9@marcan.st> 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 On Mon, Dec 19, 2022 at 08:18:43PM +0900, Hector Martin wrote: > On 19/12/2022 19.52, Ilias Apalodimas wrote: > > Hi Janne, > > > > [...] > > > >>>> function that can be called from board-specific code that sets the > >>>> UUID. > >>>> > >>>> Thoughts? Would such a feature be useful on other hardware > >>>> platforms? > >>> > >>> efi/boot/bootaarch64.efi is only a fallback if load options are not > >>> set up. Once the operating system has generated a load option it is > >>> not used anymore. > >> > >> Setting load options from operation systems is currently not > >> implemented. The only readily available method to store variables is a > >> file in the ESP. This obviously can not be supported as UEFI runtime > >> service while the operation system is using the same disk. > > > > Yes, but I'd skip the 'currently not implemented' part. If you store your EFI > > variables in a file on the ESP, we will *never* be able to (sanely) support SetVariable > > at runtime. > > > >> It might be possible to use NOR flash as UEFI variable store. This could > >> cause issues with the primary boot loader iboot which we can not avoid > >> or with macOS in dual boot configurations. > > > > It is possible. In fact we already have code in U-Boot that stores the EFI > > variables in an RPMB partition of the eMMC. We also have (unfortunately > > not yet upstreamed) code that stores the in an i2c eeprom in the secure > > world. > > > > This is again situational though and none of these applies to MBPs. > > SetVariable at runtime in an RPMB comes with it's own set of problems. > > You basically need to replace the runtime services with OS provided ones... > > The I2C one works fine. > > > > But letting the implementation details aside, what we need to keep in mind, > > is that being able to support SetVariable-RT primarily depends on the *hardware* > > and there's gonna be hardware we'll never be able to support this. > > As far as I'm concerned, the NOR is an implementation detail under > Apple's control and I would NAK any attempt at shoehorning EFI variables > in there. > This is global storage and Apple already have their own NVRAM > format for boot settings (based on CHRP). Trying to abuse it for our own > purposes is asking for trouble, since we can't coordinate anything like > that with Apple. Plus there's a good chance they'll ditch the NOR and go > NVMe-only in the future (they already do it like that on iOS devices). > And if anything goes wrong we make user systems unbootable. Plus we > still have the problem that there is a logical OS environment split > before EFI, which means we'd still need multiple ESPs and an independent > EFI variable store for each. And then if the EFI services owns the NOR, > we *still* need to provide an Apple NVRAM interface to the OS, since we > do want to be able to mutate that for things like configuring boot > settings (boot chime, next boot OS, etc.) at the Apple/iBoot layer. Yep we agree here > > In my opinion, the only sane way to get EFI variables to work here is to > use ubootefi.var and teach OSes how to manipulate it directly, in lieu > of runtime services being available (or perhaps with some kind of > callback layer so the OS can provide ESP file R/W services back to the > runtime services). I'm not sure it's worth actually doing this, but I > can't think of any other viable option if we decide we really want it. We agree here as well. In fact we are doing exactly the same thing for variables that are stored in the RPMB (teach the OS how to do that) and we'll send an RFC shortly. Unfortunately this is not optimal, since we will violate the EFI spec, but tbh there's nothing better we can do. The spec basically dictates your hardware configuration and if you don't have a dedicated storage for the variables, it offers no sane alternatives. Cheers /Ilias > > - Hector