Re: [PATCH] schemas: Add schema for firmware logs

[Ard Biesheuvel]

On Thu, 9 Feb 2023 at 19:05, Simon Glass  wrote:
>
> Hi Jan,
>
> On Wed, 8 Feb 2023 at 01:15, Jan Lübbe  wrote:
> >
> > On Tue, 2023-02-07 at 11:39 -0700, Simon Glass wrote:
> > > Hi Jan,
> > >
> > > On Tue, 7 Feb 2023 at 08:39, Jan Lübbe  wrote:
> > > >
> > > > On Tue, 2023-02-07 at 06:38 -0700, Simon Glass wrote:
> > > > > Hi Jan,
> > > > >
> > > > > On Tue, 7 Feb 2023 at 04:56, Jan Lübbe  wrote:
> > > > >
> > [snip]
> > > > > Thanks for the pointer. I had a look at this. How do you deal with
> > > > > updating a filesystem that might be corrupt? Is that even a good idea,
> > > > > if the purpose of it is to collect data from a kernel crash?
> > > >
> > > > This uses only the ramoops "backend" in pstore, so no filesystems are 
> > > > involved.
> > > > If I remember correctly, ramoops in the kernel just discards any data 
> > > > that is
> > > > too corrupted to process. Barebox should behave the same, as the code 
> > > > was ported
> > > > from the kernel.
> > >
> > > Yes...actually I found that U-Boot has pstore too, but it does not
> > > support writing the console into it. I suppose it would be easy
> > > enough, but it seems that U-Boot's pstore is not as advanced.
> > > >
> >
> > > > > We are working on a firmware 'Transfer List' which is a simple data
> > > > > structure to communicate through the different firmware phases. Since
> > > > > U-Boot is the last one, in this case, I suppose it could do the
> > > > > ramoops thing and add files for each of the firmware phases.
> > > >
> > > > For passing logs "forward" to the next step in the boot chain, this 
> > > > should work
> > > > as well and could be more explicit than the ramoops console. One 
> > > > benefit would
> > > > be that keeping the logs from each step separate, right?
> > >
> > > Yes. But we can't use this to pass it to the kernel.
> > >
> >
> > Hmm, because we would need to reserve space for the text memory regions, 
> > which
> > couldn't be used by the kernel later?
>
> Because the transfer list does not get passed to the kernel. We don't
> want to invent another way to pass info to Linux, since we already
> have FDT, ACPI and cmdline. In fact I have a horrible suspicion that
> someone added a structured cmdline a bit like an FDT but in text...
>

Yes, the tracing folks in Linux cooked up 'bootconfig' without
involving a single person that was already active in boot
architecture, boot loaders, firmware, etc. I was quite shocked by that
as well.

It seems to be another hierarchical key/value pair store, used for
passing a large set of command line arguments which may otherwise
exceed the maximum length of the kernel command line. It is appended
to the initrd by the boot loader. Android have already started using
it as well.

-- 
Ard.
___
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

Re: Firmware handoff status

[Ard Biesheuvel]

On Thu, 9 Feb 2023 at 10:48, ff  wrote:
>
> Hi
>
> Anyone knows what is the status of standardizing firmware handoff (when 
> starting BL33) ?
> Here is a reference to the topic:
> https://github.com/FirmwareHandoff/firmware_handoff
>
> I would be interested in both standard text and standard implementation in 
> TFA.
>
> The context is portability of type-1 hypervisors that need to be fully in 
> control of security and thus execute BL33 in an ad hoc "VM".
> The rationale is to isolate everything that deals with devices or IO (at its 
> core, a hypervisor deals only with CPU, RAM, MMU, SMMU, GIC).
>
> Cheers
>
> FF
>
> PS: To explore how easy it is to boot a hypervisor with either booti, bootefi 
> or BL33 I published a Rust tool (barekit) that can do precisely that (and 
> much more as it can be used to create BL32 or even a Rust based FF-A 
> implementation):
> https://www.linkedin.com/posts/fozog_github-fozogbarekit-rust-base-code-to-activity-7026199056116822017-7_l8?utm_source=share_medium=member_desktop
> https://github.com/fozog/barekit
>

Interesting! I implemented something similar last year for QEM/mach-virt

https://github.com/ardbiesheuvel/efilite

Doing EFI boot like this in a VM is actually faster than without any
firmware whatsoever, given that there is no need to play with the MMU
and caches or clean the entire kernel image to the PoC. (In my
testing, EFI boot takes 3.5ms whereas bare metal boot takes 4.5 ms
from vCPU reset to reaching start_kernel() in Linux)

The main reason is precisely the one you mention: hypervisor folks ask
for 'direct kernel boot' because it is faster but still want to
pretend while in the kernel that we did EFI boot, for ACPI tables,
SMBIOS, TPM support etc, but all this mucking about with uncached
memory with the MMU off is both slow and unsafe, especially on recent
micro-architectures.
___
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

Re: Native PE/COFF support for aarch64

[Ard Biesheuvel]

On Fri, 10 Sept 2021 at 18:36, François Ozog 
wrote:

>
>
> On Fri, 10 Sept 2021 at 18:34, Ard Biesheuvel  wrote:
>
>> On Fri, 10 Sept 2021 at 18:12, François Ozog 
>> wrote:
>> >
>> > Hi,
>> >
>> > this mail just to inform you that there is a plan to support native
>> > building of PE/COFF for aarch64 and in particular to support SBAT for
>> > shim.efi.
>> >
>> > It is seen possible to deliver this by the end of October (this is just
>> an
>> > early estimate).
>> >
>>
>> Support where? binutils+GCC? Clang/LLVM?
>>
> Sorry, I was too excited when writing. binutils+GCC.
>
>

Ah very nice. And about time :-)
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Native PE/COFF support for aarch64

[Ard Biesheuvel]

On Fri, 10 Sept 2021 at 18:12, François Ozog  wrote:
>
> Hi,
>
> this mail just to inform you that there is a plan to support native
> building of PE/COFF for aarch64 and in particular to support SBAT for
> shim.efi.
>
> It is seen possible to deliver this by the end of October (this is just an
> early estimate).
>

Support where? binutils+GCC? Clang/LLVM?
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [v5.4 stable] arm: stm32: Regression observed on "no-map" reserved memory region

[Ard Biesheuvel]

On Tue, 20 Apr 2021 at 17:54, Rob Herring  wrote:
>
> On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE
>  wrote:
> >
> >
> >
> > On 4/20/21 4:45 PM, Rob Herring wrote:
> > > On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE
> > >  wrote:
> > >>
> > >> Hi,
> > >
> > > Greg or Sasha won't know what to do with this. Not sure who follows
> > > the stable list either. Quentin sent the patch, but is not the author.
> > > Given the patch in question is about consistency between EFI memory
> > > map boot and DT memory map boot, copying EFI knowledgeable folks would
> > > help (Ard B for starters).
> >
> > Ok thanks for the tips. I add Ard in the loop.
>
> Sigh. If it was only Ard I was suggesting I would have done that
> myself. Now everyone on the patch in question and relevant lists are
> Cc'ed.
>

Thanks for the cc.

> >
> > Ard, let me know if other people have to be directly added or if I have
> > to resend to another mailing list.
> >
> > thanks
> > alex
> >
> > >
> > >>
> > >> Since v5.4.102 I observe a regression on stm32mp1 platform: "no-map"
> > >> reserved-memory regions are no more "reserved" and make part of the
> > >> kernel System RAM. This causes allocation failure for devices which try
> > >> to take a reserved-memory region.
> > >>
> > >> It has been introduced by the following path:
> > >>
> > >> "fdt: Properly handle "no-map" field in the memory region
> > >> [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]"
> > >> which replace memblock_remove by memblock_mark_nomap in no-map case.
> > >>

Why was this backported? It doesn't look like a bugfix to me.

> > >> Reverting this patch it's fine.
> > >>
> > >> I add part of my DT (something is maybe wrong inside):
> > >>
> > >> memory@c000 {
> > >>  reg = <0xc000 0x2000>;
> > >> };
> > >>
> > >> reserved-memory {
> > >>  #address-cells = <1>;
> > >>  #size-cells = <1>;
> > >>  ranges;
> > >>
> > >>  gpu_reserved: gpu@d400 {
> > >>  reg = <0xd400 0x400>;
> > >>  no-map;
> > >>  };
> > >> };
> > >>
> > >> Sorry if this issue has already been raised and discussed.
> > >>

Could you explain why it fails? The region is clearly part of system
memory, and tagged as no-map, so the patch in itself is not
unreasonable. However, we obviously have code that relies on how the
region is represented in /proc/iomem, so it would be helpful to get
some insight into why this is the case.

In any case, the mere fact that this causes a regression should be
sufficient justification to revert/withdraw it from v5.4, as I don't
see a reason why it was merged there in the first place. (It has no
fixes tag or cc:stable)
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Glitching protection

[Ard Biesheuvel]

On Fri, 26 Mar 2021 at 19:36, Heinrich Schuchardt  wrote:
>
> On 26.03.21 15:12, François Ozog wrote:
> > Hi
> >
> > Trusted Firmware M recently introduced protection against glitching at
> > key decision points:
> > https://github.com/mcu-tools/mcuboot/pull/776
> >
> > To me this is a key mitigation element for companies that target PSA
> > level 3 compliance which means hardware attacks resilience.
> >
> > I believe similar techniques need to be used in different projects
> > involved in Linux secure booting (TF-A, OP-TEE, U-Boot, Linux kernel).
>
> Power glitches can induce changes in data, in code, and in CPU state.
> Signing selected variables cannot be a sufficient counter-measure.
>
> If you want to protect against power glitches, it seems more promising
> to do so on the hardware side, e.g.
>
> * provide circuitry that resets the board if a power-glitch or an
>   electromagnetic interference is detected
> * use ECC RAM
>

Of course it is more promising to do this on the hardware side, nobody
is debating that. Whether it makes sense to harden the software as
well is completely orthogonal to that: on hardened hardware, it adds
another layer of protection, and on hardware that cannot be hardened
for some reason (cost, or more often, the fact that it has already
shipped), it adds a layer of protection where no protection whatsoever
was available beforehand.

However, I do share some of your skepticism: incorporation of these
techniques is not trivial, and commoditizing it by dropping it into
some library that you can link your software against is *not* what I
would prefer to see. This only encourages a check the box mentality,
where people either assume that having the library makes everything
magically secure, or ($DEITY forbid), it gets sucked into the MISRAs
or FIPSes of this world, and it becomes a certification requirement,
and using the library is mandatory, regardless of whether there is a
point to it, or whether it is being used in the right way.

So I'd be more interested in seeing how the underlying methods can be
applied more widely, and not how it gets shrinkwrapped and shipped
with a .h file without any need on the part of the developer to
understand what really goes on under the hood.

-- 
Ard.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: EFI_LOAD_FILE2 for initrd standardization

[Ard Biesheuvel]

On Tue, 2 Mar 2021 at 00:31, Ilias Apalodimas
 wrote:
>
> Hi Samer,
>
> Thanks for having a look at this
>
> On Mon, Mar 01, 2021 at 08:44:00PM +, Samer El-Haj-Mahmoud wrote:
> >
> >
> > > -Original Message-
> > > From: Heinrich Schuchardt 
> > > Sent: Monday, March 1, 2021 2:39 PM
> > > To: Ilias Apalodimas ; Grant Likely
> > > 
> > > Cc: Boot Architecture Mailman List ; 
> > > Samer
> > > El-Haj-Mahmoud ; Ard Biesheuvel
> > > ; Leif Lindholm 
> > > Subject: Re: EFI_LOAD_FILE2 for initrd standardization
> >
> >
> > ...
> >
> > >
> > > The UEFI spec knows two types of separators for device paths. Both have 
> > > type
> > > 0x7F (End of Hardware Device Path) but differ by the sub-type:
> > >
> > > Sub-Type 0xff – End Entire Device Path
> > > Sub-Type 0x01 – End Instance of a Device Path
> > >
> > > Field EFI_LOAD_OPTION.FilePathList[] is described in the UEFI spec as
> > > follows:
> > >
> > > "A packed array of UEFI device paths. The first element of the array is a 
> > > device
> > > path that describes the device and location of the Image for this load 
> > > option."
> > >
> > > It is not immediately clear if the separators between the array elements 
> > > are of
> > > sub-type 0xff or 0x01. The description in the UEFI spec should be 
> > > reworked for
> > > more clarity.
> > >
> >
> > Agree that this is not clear, and could be interpreted either way. And yes, 
> > agree the UEFI spec needs a clarification
> >
> >
> > > The current EDK II coding requires that the device path identifying the 
> > > UEFI
> > > binary (i.e. FilePathList[0] is terminated by a sub-type 0xff end node.
> > >
> >
> > The EDK2 code seems to be incomplete, with a "TODO" to support the 
> > FilePathList[]. In fact, the code calls it "FilePath" to be clear that it 
> > is assuming a single DevicePath (which means a 0xFF sub-type termination)
> > https://github.com/tianocore/edk2/blob/master/MdeModulePkg%2FLibrary%2FUefiBootManagerLib%2FBmLoadOption.c#L199
> >
> > Searching the code further, I see there is support for parsing 
> > multi-instance device path (separated by END_INSTANCE_DEVICE_PATH_SUBTYPE, 
> > or 0x1) in things like UefiDevicePathLib , parsing code, etc... But it does 
> > not seem to be supported at all in the UEFI Boot Manager implemented in EDK2
> >
> >
> > > The UEFI variable ConDev is decribed as "The device path of all possible 
> > > console
> > > input devices". The spec does not refer to it as an array of device paths.
> > >
> >
> > Looking at EDK2, ConXDev are treated as multi-instance devices, with 
> > ConPlatformDxe using AppendDevicePathInstance() and 
> > GetNextDevicePathInstance() to construct / navigate the multiple-instances
> >
> > The spec should have defined these as a "multi-instance device path of all 
> > possible console X devices".  See my notes below on multi-instance DP.
> >
> >
> > > So it seems that the UEFI spec editors mean by array of device paths that 
> > > an
> > > element of the array is separated by sub-type 0xff. Each individual array 
> > > element
> > > may be a collection of device paths instances separated by 0x01 sub-type 
> > > end
> > > nodes.
> > >
> >
> > I am leaning towards this conclusion as well. This is further supported by 
> > the following evidence:
> >
>
> Yes that's exactly what I thought as well and that's what option (2) was
> trying to describe on my first mail.
>
> What I had in there was:
> Loaded Image device path - end node - VenMedia - Initrd DP - end instance - 
> (repeat) - Initrd DP - end node - other DPs
>
> >
> > * EFI_DEVICE_PATH_UTILITIES_PROTOCOL has a function called 
> > IsDevicePathMultiInstance() along with walker functions 
> > AppendDevicePathInstance(), GetNextDevicePathInstance(). The description of 
> > these functions make it clear that the intention is to treat 0x01 as a 
> > separator between multiple instances of device paths in a multi-instance 
> > device path structure, with 0xff as the final end of DP indicator. For 
> > example, AppendDevicePathInstance() is defined as:
> >
> > " This function creates a new device path by appending a copy of the 
> > specified device path instance to a copy of the specified device

Re: [PATCH 1/1] UEFI section 2.6 exceptions for boot services

[Ard Biesheuvel]

On Mon, 15 Feb 2021 at 18:13, Heinrich Schuchardt  wrote:
>
> Describes deviations for ConnectController() and LoadImage().
>
> Signed-off-by: Heinrich Schuchardt 

Acked-by: Ard Biesheuvel 

> ---
>  source/chapter2-uefi.rst | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> index 49aec46..660eb27 100644
> --- a/source/chapter2-uefi.rst
> +++ b/source/chapter2-uefi.rst
> @@ -112,6 +112,17 @@ interface specific UEFI protocols, and so they have been 
> made optional.
>
> * - Element
>   - Description of deviation
> +   * - `LoadImage()`
> + - The LoadImage() boot service is not required to install an
> +   EFI_HII_PACKAGE_LIST_PROTOCOL for an image containing a custom PE/COFF
> +   resource with the type 'HII'. - HII resource images are not needed to 
> run
> +   the UEFI shell or the SCT.
> +   * - `ConnectController()`
> + - The ConnectController()` boot service is not required to support the
> +   EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL,
> +   EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL, and
> +   EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL. - These override protocols 
> are
> +   only useful if drivers are loaded as EFI binaries by the firmware.
> * - `EFI_HII_CONFIG_ACCESS_PROTOCOL`
>   - UEFI requires this for console devices, but it is rarely necessary in 
> practice.
> Therefore this protocol is not required.
> --
> 2.30.0
>
> ___
> boot-architecture mailing list
> boot-architecture@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH] Override UEFI section 2.6 requirements

[Ard Biesheuvel]

On Wed, 3 Feb 2021 at 15:04, Grant Likely  wrote:
>
>
>
> On 02/02/2021 16:46, Peter Robinson wrote:
> > * - EFI_PXE_BASE_CODE_PROTOCOL
> >  - Booting via the Preboot Execution Environment (PXE) is insecure.
> >Loading via PXE is typically executed before launching the first
> >UEFI application.
> 
>  I don't think PXE should be a requirement, as Heinrich mentions it's
>  insecure. We should be requiring a secure protocol for a new spec, not
>  an old one that's being EOLed. I believe vendors are moving to remove
>  it in favour of HTTPS boot which also has the advantage it's more
>  flexible, and it much better places for IoT/Edge deployments which use
>  CDNs and the life extensively and it will generally work with
>  firewalls etc. If we're going to require something for network
>  installs, if the device has a capable network interface, it should be
>  HTTPS Boot.
> 
>  Peter
> >>>
> >>> Unfortunately we've got a functionality gap. U-Boot doesn't yet support
> >>> TCP, HTTP, or TLS. All that functionality needs to be written or ported
> >>> from somewhere.
> >>>
> >>> I would really like to require a secure network boot mechanism, but I
> >>> think it needs to be left out until U-Boot can do TCP and TLS.
> >>
> >> You can use iPXE as U-Boot payload which offers HTTPS and iSCSI. Isn't
> >> that enough?
> >
> > iPXE is an implementation not the standard. I think EBBR the standard
> > should require HTTPS boot, now if U-Boot chooses to implement that
> > part of the standard using an iPXE UEFI binary to implement HTTPS boot
> > that's an optoin.
> >
> >> TLS is quite complicated. GNU TLS has > 430,000 lines of code (without
> >> comments). Looking at the number of CVEs in OpenSSL and GnuTLS I do not
> >> believe that the U-Boot community will be able to produce and maintain a
> >> secure implementation.
> >
> > Sure, but we're not talking about U-Boot, we're talking about EBBR the
> > standard and U-Boot has a number of means of implementing HTTPS Boot,
> > but by hobbling the standard with deployment technologies of the last
> > century I think is a mistake.
> >
> > I have my opinions on whether implementing HTTP boot in U-Boot
> > directly or leaning on iPXE as the implementation but that is
> > irrelevant to what I think is right for EBBR as the standard. I think
> > we should be specifying HTTPS boot as a part of the spec, and having a
> > separate discussion of how that is supported in U-Boot.
>
> I agree here. EBBR should specify interfaces/specs without requiring
> iPXE, or any specific standard. HTTPS boot is clearly the right
> direction, but I'm wrestling with when/how it should be added.
>
> After our chat today, I'll propose that HTTPS boot be required by EBBR
> if network boot is supported. U-Boot on it's own won't meet that
> requirement, so for the time being U-Boot platforms won't be able to
> claim EBBR compliant network boot.
>

+1
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: EBBR Biweekly for 18 Jan 2021

[Ard Biesheuvel]

On Tue, 19 Jan 2021 at 05:54, Dong Wei  wrote:
>
> There is also the SPCR table 
> https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table?redirectedfrom=MSDN
> This is the primary serial console
>

One of the issues we still have not fixed in Linux is the
inconsistency in interpretation of what 'serial console' actually
means.

On Windows, the serial console is a low-level admin interface that may
be exposed in addition to the full blown graphical user interface,
which is always available. The SPCR describes how this admin interface
is exposed, but does not affect what happens on the GUI.

In Linux, the console *is* the primary interface, either graphical or
serial. Currently, the mere presence of a SPCR is taken as an
indication that only the serial console should be enabled; for this
reason, the UEFI ports we have for platforms with PCIe expansion carry
a driver that removes the SPCR again if UEFI detects the presence of a
graphical interface.

Unfortunately, this is not something we can easily change without
breaking existing systems. Note that annotating device objects in the
DSDT is probably not the right approach here, given that this requires
the AML interpreter to be up and running before we can decide where
the console lives.

As Heinrich points out, we have a similar problem today when it comes
to the graphical interface on DT systems, i.e., it is not clear how to
convey that the user expects the interaction with the system to occur
via the graphical UI and not via a serial port. For a bootloader such
as u-boot, it should be fairly easy to suppress the stdout-path if
u-boot itself is running on the graphical display, but it would be
better to communicate the presence of this GUI *in addition to* a
serial port serving as a console.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Ard Biesheuvel]

On Tue, 6 Oct 2020 at 17:09, François Ozog  wrote:

>
>
> On Tue, 6 Oct 2020 at 16:46, Ard Biesheuvel  wrote:
>
>>
>>
>> On Tue, 6 Oct 2020 at 16:22, François Ozog 
>> wrote:
>>
>>> Ard, there is a question for you in the below thread ;-)
>>>
>>> On Tue, 6 Oct 2020 at 15:02, Grant Likely  wrote:
>>>
>>>>
>>>>
>>>> On 06/10/2020 13:52, Heinrich Schuchardt wrote:
>>>> > On 06.10.20 14:43, Grant Likely wrote:
>>>> >
>>>> >>
>>>> >> Current U-Boot by default uses the same DT image for both U-Boot
>>>> >> internal setup and to provide to the OS. This should be split so that
>>>> >> the U-Boot internal version has what U-Boot needs without needs to
>>>> track
>>>> >> mainline Linux DTB schema.
>>>> >>
>>>> >> I've been looking into a generic config for adding a separate OS-dtb
>>>> to
>>>> >> U-Boot that is not used internally and is only passed to the OS. That
>>>> >> would solve the problem you're seeing above.
>>>
>>> >
>>>> > What would be the advantage of building said second device-tree into
>>>> > U-Boot instead of loading it from a (possibly signed) file?
>>>>
>>>> I would see that as an implementation detail, but from the OS point of
>>>> view EBBR requires the firmware to provide a DTB to the OS without the
>>>> OS having any involvement in providing it. The easiest solution is to
>>>> embed the OS dtb into U-Boot, but it could be loaded and verified from
>>>> a
>>>> file as well.
>>>>
>>> To strongly state that the DT is a hardware description entity,
>>> disconnected from open source projects consuming it,
>>>  I would still build the DT for the Booted Payload in the context of
>>> devicetree.org and append it to either FIP or U-Boot.
>>> From a hierarchical perspective FIP would make more sense (I was told by
>>> the LinuxBoot guys that the ACPI tables are
>>> tied to PEI so that they can use them while replacing EDK2. I am not
>>> sure my understanding is correct: Ard ?)
>>>
>>
>> No that is a lie. In EDK2 based firmwares, there are DXE protocols used
>> for publishing and manipulating ACPI tables, and for exposing them via the
>> config table array when the boot finally occurs.
>>
>> Are the ACPI tables "static" blobs that are integrated into the firmware
> image with some late fixups in the DXE phase or are they entirely built
> programmatically during the DXE phase? In the case they are static base
> blobs in the firmware image, are they used (to access hardware, not
> manipulated) in all phases (SEC, PEI, DXE) ?
>

They could be generated from scratch or incorporated fully baked. In either
case, the firmware itself never consumes the ACPI tables, it only produces
them for consumption by the OS.


>
>
>> I should also point out (for anyone that hadn't noticed) that the
>> Linuxboot guys have a highly skewed and opinionated view of UEFI boot,
>> which seems mostly based on bad experiences with IBV provided, OEM mangled
>> builds for proprietary code bases of which it is unknown how much they are
>> based on EDK2 (or UEFI for that matter). The IBVs used to claim that they
>> carried their own complete implementations of the PI and UEFI and
>> specifications, but everybody knows that is a lie, especially for firmwares
>> built for ARM machines.
>>
>> as I consider that PEI and TF-A are at the same layer I am inclined to
>>> promote this.
>>>
>>
>> TF-A is secure firmware, PEI is non-secure firmware, so I suppose it
>> depends on how you defined your layers. Although in the x86 context, PEI
>> executes when the SMM execution context has not split off yet, so it s
>> closer to a secure world firmware than it is on ARM (same applies to DXE
>> before EndOfDxe, but the boundary line is not as clear in this case)
>>
> I was biased by the x86 model here...
>
>>
>>
>> Should the DTB cause problems, the one embedded in the FIT would be
>>> replacing the platform base one
>>>  (I assume this is your "loaded and verified from a file" comment).
>>>
>>>>
>>>> g.
>>>>
>>>
>>>
>>> --
>>> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
>>> T: +33.67221.6485
>>> francois.o...@linaro.org | Skype: ffozog
>>>
>>>
>
> --
> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
> T: +33.67221.6485
> francois.o...@linaro.org | Skype: ffozog
>
>
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Ard Biesheuvel]

On Tue, 6 Oct 2020 at 16:22, François Ozog  wrote:

> Ard, there is a question for you in the below thread ;-)
>
> On Tue, 6 Oct 2020 at 15:02, Grant Likely  wrote:
>
>>
>>
>> On 06/10/2020 13:52, Heinrich Schuchardt wrote:
>> > On 06.10.20 14:43, Grant Likely wrote:
>> >
>> >>
>> >> Current U-Boot by default uses the same DT image for both U-Boot
>> >> internal setup and to provide to the OS. This should be split so that
>> >> the U-Boot internal version has what U-Boot needs without needs to
>> track
>> >> mainline Linux DTB schema.
>> >>
>> >> I've been looking into a generic config for adding a separate OS-dtb to
>> >> U-Boot that is not used internally and is only passed to the OS. That
>> >> would solve the problem you're seeing above.
>
> >
>> > What would be the advantage of building said second device-tree into
>> > U-Boot instead of loading it from a (possibly signed) file?
>>
>> I would see that as an implementation detail, but from the OS point of
>> view EBBR requires the firmware to provide a DTB to the OS without the
>> OS having any involvement in providing it. The easiest solution is to
>> embed the OS dtb into U-Boot, but it could be loaded and verified from a
>> file as well.
>>
> To strongly state that the DT is a hardware description entity,
> disconnected from open source projects consuming it,
>  I would still build the DT for the Booted Payload in the context of
> devicetree.org and append it to either FIP or U-Boot.
> From a hierarchical perspective FIP would make more sense (I was told by
> the LinuxBoot guys that the ACPI tables are
> tied to PEI so that they can use them while replacing EDK2. I am not sure
> my understanding is correct: Ard ?)
>

No that is a lie. In EDK2 based firmwares, there are DXE protocols used for
publishing and manipulating ACPI tables, and for exposing them via the
config table array when the boot finally occurs.

I should also point out (for anyone that hadn't noticed) that the Linuxboot
guys have a highly skewed and opinionated view of UEFI boot, which seems
mostly based on bad experiences with IBV provided, OEM mangled builds for
proprietary code bases of which it is unknown how much they are based on
EDK2 (or UEFI for that matter). The IBVs used to claim that they carried
their own complete implementations of the PI and UEFI and specifications,
but everybody knows that is a lie, especially for firmwares built for ARM
machines.

as I consider that PEI and TF-A are at the same layer I am inclined to
> promote this.
>

TF-A is secure firmware, PEI is non-secure firmware, so I suppose it
depends on how you defined your layers. Although in the x86 context, PEI
executes when the SMM execution context has not split off yet, so it s
closer to a secure world firmware than it is on ARM (same applies to DXE
before EndOfDxe, but the boundary line is not as clear in this case)


Should the DTB cause problems, the one embedded in the FIT would be
> replacing the platform base one
>  (I assume this is your "loaded and verified from a file" comment).
>
>>
>> g.
>>
>
>
> --
> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
> T: +33.67221.6485
> francois.o...@linaro.org | Skype: ffozog
>
>
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Ard Biesheuvel]

On Tue, 6 Oct 2020 at 12:13, François Ozog  wrote:

>
>
> On Tue, 6 Oct 2020 at 10:06, Ard Biesheuvel  wrote:
>
>>
>>
>> On Tue, 6 Oct 2020 at 10:00, François Ozog 
>> wrote:
>>
>>>
>>>
>>> Le mar. 6 oct. 2020 à 09:21, Ard Biesheuvel  a écrit :
>>>
>>>> On Tue, 6 Oct 2020 at 06:35, Heinrich Schuchardt 
>>>> wrote:
>>>> >
>>>> > Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely <
>>>> grant.lik...@arm.com>:
>>>> > >
>>>> > >
>>>> > >On 03/10/2020 09:51, Heinrich Schuchardt wrote:
>>>> > >> Hello Ilias, hello Christian,
>>>> > >>
>>>> > >> with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for
>>>> > >initramfs
>>>> > >> loading") Ilias provided the possibility to specify a device path
>>>> > >> (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
>>>> > >> served via the EFI_FILE_LOAD2_PROTOCOL.
>>>> > >>
>>>> > >> Ard extended the Linux EFI stub to allow loading the initial RAM
>>>> disk
>>>> > >> via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
>>>> > >>
>>>> > >> With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
>>>> > >> IH_OS_EFI") Cristian enabled signed FIT images that contain a
>>>> device
>>>> > >> tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
>>>> > >>
>>>> > >> In the DTE calls we have discussed that it is unfortunate that we
>>>> do
>>>> > >not
>>>> > >> have a method to validate initial RAM images in the UEFI context.
>>>> > >>
>>>> > >> To me it would look like a good path forward to combine the two
>>>> > >ideas:
>>>> > >>
>>>> > >> * Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
>>>> > >> * Pass location and size to the UEFI subsystem and serve them via
>>>> > >>the EFI_FILE_LOAD2_PROTOCOL.
>>>> > >>
>>>> > >> We could also extend the bootefi command to be callable as
>>>> > >>
>>>> > >> bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
>>>> > >>
>>>> > >> like the booti command to serve an initial RAM disk.
>>>> > >>
>>>> > >> What are your thoughts?
>>>> > >
>>>> > >Hi Heinrich,
>>>> > >
>>>> > >I've got concerns about this approach. Even though it uses the UEFI
>>>> > >infrastructure, images deployed in this way are U-Boot specific and
>>>> > >won't ever be applicable on EDK2 or other UEFI implementations.
>>>> > >
>>>> > >However there is another way to approach it which I think Francois
>>>> > >touched on. If instead a UEFI stub was added to the FIT image, in the
>>>> > >same way that the kernel has a UEFI stub, then the logic of decoding
>>>> > >the
>>>> > >FIT and choosing the correct DTB & initrd can be part of the image
>>>> and
>>>> > >it becomes applicable to any UEFI implementation. It would also
>>>> address
>>>> > >
>>>> > >Ard's concern of loading the FIT into memory, and then copying due to
>>>> > >the EFI_FILE_LOAD2 path. The FIT stub would already know the image is
>>>> > >in
>>>> > >RAM, that is is reserved correctly, and just pass the correct
>>>> addresses
>>>> > >
>>>> > >to the kernel as part of the normal boot flow.
>>>> > >
>>>> > >Signing would also be taken care of because the whole FIT can be
>>>> > >signed,
>>>> > >and that signature would be checked when it gets loaded.
>>>> > >
>>>> > >Thoughts?
>>>> > >
>>>> >
>>>> > The gain of a fit image in U-Boot used for calling the Linux kernel
>>>> via the EFI stub vs calling the legacy entry point comes down to providing
>>>> the EFI_RNG_PROTOCOL to be used for KASLR.
>>>> >
>>>> > For initrd a stub U

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Ard Biesheuvel]

On Tue, 6 Oct 2020 at 10:00, François Ozog  wrote:

>
>
> Le mar. 6 oct. 2020 à 09:21, Ard Biesheuvel  a écrit :
>
>> On Tue, 6 Oct 2020 at 06:35, Heinrich Schuchardt 
>> wrote:
>> >
>> > Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely <
>> grant.lik...@arm.com>:
>> > >
>> > >
>> > >On 03/10/2020 09:51, Heinrich Schuchardt wrote:
>> > >> Hello Ilias, hello Christian,
>> > >>
>> > >> with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for
>> > >initramfs
>> > >> loading") Ilias provided the possibility to specify a device path
>> > >> (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
>> > >> served via the EFI_FILE_LOAD2_PROTOCOL.
>> > >>
>> > >> Ard extended the Linux EFI stub to allow loading the initial RAM disk
>> > >> via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
>> > >>
>> > >> With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
>> > >> IH_OS_EFI") Cristian enabled signed FIT images that contain a device
>> > >> tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
>> > >>
>> > >> In the DTE calls we have discussed that it is unfortunate that we do
>> > >not
>> > >> have a method to validate initial RAM images in the UEFI context.
>> > >>
>> > >> To me it would look like a good path forward to combine the two
>> > >ideas:
>> > >>
>> > >> * Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
>> > >> * Pass location and size to the UEFI subsystem and serve them via
>> > >>the EFI_FILE_LOAD2_PROTOCOL.
>> > >>
>> > >> We could also extend the bootefi command to be callable as
>> > >>
>> > >> bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
>> > >>
>> > >> like the booti command to serve an initial RAM disk.
>> > >>
>> > >> What are your thoughts?
>> > >
>> > >Hi Heinrich,
>> > >
>> > >I've got concerns about this approach. Even though it uses the UEFI
>> > >infrastructure, images deployed in this way are U-Boot specific and
>> > >won't ever be applicable on EDK2 or other UEFI implementations.
>> > >
>> > >However there is another way to approach it which I think Francois
>> > >touched on. If instead a UEFI stub was added to the FIT image, in the
>> > >same way that the kernel has a UEFI stub, then the logic of decoding
>> > >the
>> > >FIT and choosing the correct DTB & initrd can be part of the image and
>> > >it becomes applicable to any UEFI implementation. It would also address
>> > >
>> > >Ard's concern of loading the FIT into memory, and then copying due to
>> > >the EFI_FILE_LOAD2 path. The FIT stub would already know the image is
>> > >in
>> > >RAM, that is is reserved correctly, and just pass the correct addresses
>> > >
>> > >to the kernel as part of the normal boot flow.
>> > >
>> > >Signing would also be taken care of because the whole FIT can be
>> > >signed,
>> > >and that signature would be checked when it gets loaded.
>> > >
>> > >Thoughts?
>> > >
>> >
>> > The gain of a fit image in U-Boot used for calling the Linux kernel via
>> the EFI stub vs calling the legacy entry point comes down to providing the
>> EFI_RNG_PROTOCOL to be used for KASLR.
>> >
>> > For initrd a stub UEFI binary will work. But if you want to provide a
>> kernel specific  dtb with the same stub binary it will require a new
>> service for device-tree fixups.
>> >
>> > Both approaches are on Francois' DTE slidedeck.
>> >
>> > When thinking of security what really is unclear to me is how we can
>> safely provide the decryption key for the root partition. Without such a
>> means secure boot stops being secure once Linux starts the init process. I
>> would assume that only the secure world can provide the key.
>> >
>>
>> Secure boot only deals with authentication, which does not require any
>> secret keys.
>>
>> Encrypted file systems are a completely separate matter. Typically,
>> this is based on TPM-based local attestation, where the decryption key
>> has been sea

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Ard Biesheuvel]

On Tue, 6 Oct 2020 at 06:35, Heinrich Schuchardt  wrote:
>
> Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely :
> >
> >
> >On 03/10/2020 09:51, Heinrich Schuchardt wrote:
> >> Hello Ilias, hello Christian,
> >>
> >> with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for
> >initramfs
> >> loading") Ilias provided the possibility to specify a device path
> >> (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
> >> served via the EFI_FILE_LOAD2_PROTOCOL.
> >>
> >> Ard extended the Linux EFI stub to allow loading the initial RAM disk
> >> via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
> >>
> >> With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
> >> IH_OS_EFI") Cristian enabled signed FIT images that contain a device
> >> tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
> >>
> >> In the DTE calls we have discussed that it is unfortunate that we do
> >not
> >> have a method to validate initial RAM images in the UEFI context.
> >>
> >> To me it would look like a good path forward to combine the two
> >ideas:
> >>
> >> * Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
> >> * Pass location and size to the UEFI subsystem and serve them via
> >>the EFI_FILE_LOAD2_PROTOCOL.
> >>
> >> We could also extend the bootefi command to be callable as
> >>
> >> bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
> >>
> >> like the booti command to serve an initial RAM disk.
> >>
> >> What are your thoughts?
> >
> >Hi Heinrich,
> >
> >I've got concerns about this approach. Even though it uses the UEFI
> >infrastructure, images deployed in this way are U-Boot specific and
> >won't ever be applicable on EDK2 or other UEFI implementations.
> >
> >However there is another way to approach it which I think Francois
> >touched on. If instead a UEFI stub was added to the FIT image, in the
> >same way that the kernel has a UEFI stub, then the logic of decoding
> >the
> >FIT and choosing the correct DTB & initrd can be part of the image and
> >it becomes applicable to any UEFI implementation. It would also address
> >
> >Ard's concern of loading the FIT into memory, and then copying due to
> >the EFI_FILE_LOAD2 path. The FIT stub would already know the image is
> >in
> >RAM, that is is reserved correctly, and just pass the correct addresses
> >
> >to the kernel as part of the normal boot flow.
> >
> >Signing would also be taken care of because the whole FIT can be
> >signed,
> >and that signature would be checked when it gets loaded.
> >
> >Thoughts?
> >
>
> The gain of a fit image in U-Boot used for calling the Linux kernel via the 
> EFI stub vs calling the legacy entry point comes down to providing the 
> EFI_RNG_PROTOCOL to be used for KASLR.
>
> For initrd a stub UEFI binary will work. But if you want to provide a kernel 
> specific  dtb with the same stub binary it will require a new service for 
> device-tree fixups.
>
> Both approaches are on Francois' DTE slidedeck.
>
> When thinking of security what really is unclear to me is how we can safely 
> provide the decryption key for the root partition. Without such a means 
> secure boot stops being secure once Linux starts the init process. I would 
> assume that only the secure world can provide the key.
>

Secure boot only deals with authentication, which does not require any
secret keys.

Encrypted file systems are a completely separate matter. Typically,
this is based on TPM-based local attestation, where the decryption key
has been sealed into the TPM, and is only unsealed when all the boot
components check out (based on their 'measurements' [aka hashes] that
are cumulatively recorded in TPM hardware registers called PCRs)

In general, keeping secrets on a device is much more difficult than
authenticating executable images, and typically involves some user
provided secret, or h/w support. UEFI secure boot only reasons about
authentication.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Ard Biesheuvel]

On Sat, 3 Oct 2020 at 18:35, Heinrich Schuchardt  wrote:
>
> On 10/3/20 3:12 PM, Ard Biesheuvel wrote:
> >
> >
> > On Sat, 3 Oct 2020 at 13:16, François Ozog  > <mailto:francois.o...@linaro.org>> wrote:
> >
> >
> >
> > Le sam. 3 oct. 2020 à 13:14, François Ozog  > <mailto:francois.o...@linaro.org>> a écrit :
> >
> >
> >
> > Le sam. 3 oct. 2020 à 10:51, Heinrich Schuchardt
> > mailto:xypron.g...@gmx.de>> a écrit :
> >
> > Hello Ilias, hello Christian,
> >
> >
> >
> > with commit ec80b4735a59 ("efi_loader: Implement FileLoad2
> > for initramfs
> >
> > loading") Ilias provided the possibility to specify a device
> > path
> >
> > (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk
> > can be
> >
> > served via the EFI_FILE_LOAD2_PROTOCOL.
> >
> >
> >
> > Ard extended the Linux EFI stub to allow loading the initial
> > RAM disk
> >
> > via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
> >
> >
> >
> > With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
> >
> > IH_OS_EFI") Cristian enabled signed FIT images that contain
> > a device
> >
> > tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
> >
> >
> >
> > In the DTE calls we have discussed that it is unfortunate
> > that we do not
> >
> > have a method to validate initial RAM images in the UEFI
> > context.
> >
> >
> >
> > To me it would look like a good path forward to combine the
> > two ideas:
> >
> >
> >
> > * Let the signed FIT image (of type IH_OS_EFI) contain a RAM
> > disk
> >
> > * Pass location and size to the UEFI subsystem and serve
> > them via
> >
> >   the EFI_FILE_LOAD2_PROTOCOL.
> >
> >
> >
> > We could also extend the bootefi command to be callable as
> >
> >
> >
> >bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
> >
> >
> >
> > like the booti command to serve an initial RAM disk.
> >
> >
> >
> > What are your thoughts?
> >
> > that looks super interesting.
> > I propose something (in the latest desk preparing oct 14th)
> > similar except the an efi application boots the FIT.
> > I view UEFI as booting a PE coff and pass a set of config
> > tables. Today we have DTB, we could just add Initrd (you command
> > line). Bootefi would be responsible to valide the containing FIT
> > before pushing initrd (and dTB?)into the table. It would be the
> > responsibility of the efi stub to get the initrd from the config
> > table (GUID to be defined).
> >
> > the memory attributes of the initrd config table should be such that
> > it can be recovered for normal use. That may be tricky though.
> >
> >
> > The purpose of the EFI_FILE_LOAD2_PROTOCOL based initrd loading
> > mechanism is to allow the EFI stub (which is tightly coupled to the
> > kernel arch/version/etc) to allocate the memory for the initrd, and pass
> > it into the LoadFile2() request, using whichever policy it wants to
> > adhere to for alignment, offset and/or vicinity of the kernel image. It
> > also ensures that any measurement performed by the bootloader for
> > attestation or authentication can be delayed to the point where the
> > booting kernel assumes ownership of the initrd contents, preventing
> > potential TOCTOU issues where intermediate boot stages are involved
> > (shim+grub etc)
>
> Any UEFI binary that you invoke can overwrite the complete system table
> and replace the existing UEFI API by its own implementation which may be
> malicious.
>

I don't see how this has anything to do with what I wrote above.

> So the EFI_FILE_LOAD2_PROTOCOL does not provide any safety guarantees
> whatsoever.
>
> Either you have a chain of trust or not. If you have a chain of trust,
> it is sufficient that user input, e.g. an initrd loaded from disk is
> verified once.
>
> >
> > Creating an initrd config table would mean that the bootloader decides
> > 

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Ard Biesheuvel]

On Sat, 3 Oct 2020 at 13:16, François Ozog  wrote:

>
>
> Le sam. 3 oct. 2020 à 13:14, François Ozog  a
> écrit :
>
>>
>>
>> Le sam. 3 oct. 2020 à 10:51, Heinrich Schuchardt  a
>> écrit :
>>
>>> Hello Ilias, hello Christian,
>>>
>>>
>>>
>>> with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for initramfs
>>>
>>> loading") Ilias provided the possibility to specify a device path
>>>
>>> (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
>>>
>>> served via the EFI_FILE_LOAD2_PROTOCOL.
>>>
>>>
>>>
>>> Ard extended the Linux EFI stub to allow loading the initial RAM disk
>>>
>>> via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
>>>
>>>
>>>
>>> With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
>>>
>>> IH_OS_EFI") Cristian enabled signed FIT images that contain a device
>>>
>>> tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
>>>
>>>
>>>
>>> In the DTE calls we have discussed that it is unfortunate that we do not
>>>
>>> have a method to validate initial RAM images in the UEFI context.
>>>
>>>
>>>
>>> To me it would look like a good path forward to combine the two ideas:
>>>
>>>
>>>
>>> * Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
>>>
>>> * Pass location and size to the UEFI subsystem and serve them via
>>>
>>>   the EFI_FILE_LOAD2_PROTOCOL.
>>>
>>>
>>>
>>> We could also extend the bootefi command to be callable as
>>>
>>>
>>>
>>>bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
>>>
>>>
>>>
>>> like the booti command to serve an initial RAM disk.
>>>
>>>
>>>
>>> What are your thoughts?
>>
>> that looks super interesting.
>> I propose something (in the latest desk preparing oct 14th) similar
>> except the an efi application boots the FIT.
>> I view UEFI as booting a PE coff and pass a set of config tables. Today
>> we have DTB, we could just add Initrd (you command line). Bootefi would be
>> responsible to valide the containing FIT before pushing initrd (and
>> dTB?)into the table. It would be the responsibility of the efi stub to get
>> the initrd from the config table (GUID to be defined).
>>
> the memory attributes of the initrd config table should be such that it
> can be recovered for normal use. That may be tricky though.
>

The purpose of the EFI_FILE_LOAD2_PROTOCOL based initrd loading mechanism
is to allow the EFI stub (which is tightly coupled to the kernel
arch/version/etc) to allocate the memory for the initrd, and pass it into
the LoadFile2() request, using whichever policy it wants to adhere to for
alignment, offset and/or vicinity of the kernel image. It also ensures that
any measurement performed by the bootloader for attestation or
authentication can be delayed to the point where the booting kernel assumes
ownership of the initrd contents, preventing potential TOCTOU issues where
intermediate boot stages are involved (shim+grub etc)

Creating an initrd config table would mean that the bootloader decides
where to load the initrd in memory, and only passes the address and size.
This is exactly what we wanted to avoid, because now, the bootloader has to
know all these different rules that vary between kernel version,
configurations and architectures.

For uboot's implementation of FIT based EFI_FILE_LOAD2_PROTOCOL, this might
mean that the initrd is loaded into memory first, and copied to another
location (and [re-]authenticated) when LoadFile2() is invoked. I don't
think this is a problem in the general case, but we might think about ways
to avoid this if this turns out to be a problem for memory constrained
devices with huge initrds.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Specifying the boot flow

[Ard Biesheuvel]

On Fri, 2 Oct 2020 at 15:12, Heinrich Schuchardt  wrote:
>
...
> Please read
>
> https://u-boot.readthedocs.io/en/latest/uefi/uefi.html#launching-a-uefi-binary-from-a-fit-image
>
> Up to now the signed fit image can provide the UEFI binary and the FDT.
>
> We could easily and probably should extend U-Boot to provide the RAM
> disk loaded as part of a fit image via the EFI_LOAD_FILE2_PROTOCOL for
> consumption by Linux.
>
> @Ard:
> Is there any documentation for the usage of the EFI_LOAD_FILE2_PROTOCOL
> by Linux? I could not find anything in
> https://www.kernel.org/doc/html/latest/search.html. We should document
> how the RAM disk is passed to the EFI stub and how it is communicated to
> the main Linux.
>
> To my understanding this is how it works:
>
> If the the kernel command line contains "noinitrd", no RAM disk is
> loaded by the EFI stub.
>
> If the parameter is not passed the initial RAM disk is searched in the
> following sequence:
>
> * EFI_LOAD_FILE2_PROTOCOL
> * file path indicated by initrd= command line argument.
>
> After successfully loading a RAM disk the Linux EFI stub sets the device
> tree properties "linux,initrd-start" and "linux,initrd-end" in the
> "/chosen" node to indicated the location of the RAM disk.
>
> If the EFI stub is called without a device-tree, an empty device tree is
> created for adding these properties. So on boards with ACPI the initrd
> address is passed via the device-tree too.
>
> GRUB uses the same DT properties to pass a RAM disk (function
> linux_prepare_fdt()). So the RAM disk position passed by GRUB is only a
> fallback replaced by the kernel EFI stub when loading an image via the
> EFI_LOAD_FILE2_PROTOCOL or the initrd= parameter.
>

Indeed.

The need to modify the DT to pass parameters to the incoming kernel is
problematic, because it interferes with the OS's ability to
authenticate it (assuming we ever get to that point).

What we attempted with these changes is to have a cleaner separation between
a) h/w description
b) data provided by the boot environment.

in a way that enables authentication and attestation in a arch-agnostic manner.

Note that initrd= is problematic because it only supports loading the
initrd from the same block device that the kernel image itself was
loaded from, which may be overly restrictive in some cases.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Specifying the boot flow

[Ard Biesheuvel]

On Thu, 1 Oct 2020 at 22:30, Simon Glass  wrote:
>
> Hi Grant,
>
> [who is 'nd'?]
>

That would be our bot who kindly omits of the obnoxious email footer
on outgoing email if cc'ed.

> On Wed, 30 Sep 2020 at 09:26, Grant Likely  wrote:
> >
> > Hi Simon,
> >
> > Heinrich provided some great answers on the technical details. I'll try
> > not to retrace his answers, but there are a few conceptual model bits
> > that I think are worth talking about...
> >
> > On 28/09/2020 17:51, Simon Glass wrote:
> > > Hi,
> > >
> > > I thought perhaps it might be worth starting a thread on this, as
> > > despite Grant and Heinrich kinding spending a bit of time talking
> > > about this, I am still very much in the dark about how 'embedded' and
> > > distro/other boot flows are going to come together with EBBR. Of
> > > course this would be easier f2f.
> >
> > I'll assume for both of the cases you describe below that the UEFI boot
> > path (bootefi) is used instead of the traditional bootm.
>
> Well in fact it is either bootm (ARM + x86) or zboot (x86) depending
> on what we are talking about.
>
> >
> > > Case 1:
> > > Firmware loads the kernel to a particular address, selects DT and
> > > boots it. The kernel may require EFI boot services, or may not, but in
> > > the general case the firmware provides them.
> > >
> > > Case 2:
> > > Firmware loads EFI app and provides EFI boot services to it. How the
> > > system actually boots is under control of the app.
> > As far as bootefi is concerned, case 1 & case 2 are identical. The image
> > to be run is loaded into memory and bootefi executes the payload. In
> > case 1 the payload in Linux's built-in UEFI stub. In case 2 the payload
> > is grub.efi, shell.efi, shim.efi, etc.
> >
> > bootefi differs from bootm in that instead of a bare vmlinuz image or a
> > FIT image, the loaded image is a PECOFF executable. U=Boot parses the
> > PECOFF headers, loads the sections into memory and jumps to the entry
> > point. It also leaves a pointer to an in-memory information table with
> > callbacks into firmware functions for accessing basic services (console,
> > block device, network, graphics, filesystem, etc).
> >
> > If the image is Linux, then the stub will do a small amount of setup
> > before calling ExitBootServices(), which tells firmware to stop managing
> > hardware because the kernel is taking over. (In UEFI terms, this is call
> > an "OS loader" image)
> >
> > If the image is a transient binary like Grub or the UEFI shell, it can
> > use firmware facilities to load additional files (e.g., initrd, kernel,
> > etc) before jumping into another PE/COFF binary. For example, Grub will
> > typically load the kernel into memory, which itself is a PE/COFF image,
> > and then jump to its entry point.
>
> Yes. I think this is the source of the pain, since there is really no
> limit on what these can do and there is no standard flow. Much of the
> loading happens outside the control of the bootloader, which means
> that verified boot and testing are harder.
>
> >
> > If an image doesn't call ExitBootServices(), and instead exits, control
> > returns to firmware as one would expect.
> >
> > > I feel that a lot of the confusion about verified boot, DT selections,
> > > boot menus, etc. is coming from the introduction of an EFI app which
> > > has no specification (it can be grub, shim or something else, as I
> > > understand it). Certainly this is very flexible and future-proof, but
> > > it is also arbitrarily complex, unpredictable and hard to secure.
> >
> > Of the items you've listed above, DT selection does indeed need work,
> > but the rest is quite well specified. The UEFI spec has very clear
> > specifications on how the boot image is selected via the BOOT
> > variables and the format of the binaries. Secure Boot is also
> > standardized so that when Secure Boot is turned on, firmware will only
> > execute images signed by a recognized key.
> >
> > It is no more arbitrarily complex than booting an OS kernel. When
> > compared against bootm, both boot flows load an image into memory, and
> > both jump to the image starting point. In both cases the OS can do
> > whatever it wants after the firmware jumps into it, and in both cases if
> > security is enabled then the binaries must be signed.
>
> I think you are missing my point. With bootm etc. it jumps straight
> from U-Boot to linux. Of course linux may have an EFI shim, but there
> is no grub or any other loader 'in the way'.
>
> >
> > Where UEFI differs is that it continues to offer {console,net,block,fs}
> > services for as long as the image chooses to use them so that early boot
> > code doesn't need to carry its own implementations.
>
> Yes. Certainly having a standard way to output console text is useful
> early in linux for debugging. I'm not too sure about the others
> though, in the simple case.
>

Another advantage of EFI boot is that it allows us to avoid putting
Linux specific knowledge into the bootloader, which is 

Re: EBBR: RISC-V handoff to OS

[Ard Biesheuvel]

ion of such an "alternate execution
> environment". But an alternative execution environment serving
> interrupts while calling the UEFI API and relying on values that it has
> put into gp would not work on current U-Boot.
>
> >
> > In edk2 RISC-V port, we use "firmware_context" in sbi_platforms which 
> > provided opensbi through mscratch to maintain the firmware specific 
> > context. With this, firmware can maintain its own data structure without 
> > bothering any other industrial specs. Because S-Mode firmware can't access 
> > to mhartid and  the sbi-scratch which is stored in mscratch, so we have 
> > Edk2OpensbiLib that registers the firmware specific sbi extension functions 
> > using "Firmware Code Base Specific SBI Extension Space, Extension Ids 
> > 0x0A00 through 0x0AFF" defined in sbi spec. That is a separate spec 
> > for RISC-V edk2 firmware sbi extension function (This reminds me I forget 
> > to document it). Then edk2 can get the necessary information using edk2 
> > extension sbi call.
> >
>
> Thank you for pointing me at Edk2OpensbiLib. Where can I find the code?
>
> I will have to keep in mind that U-Boot can be used both with and
> without an SEE.
>
> > You would agree with that we don’t have to mention the gp/tp usage in the 
> > calling convention just because of the uboot implementation. And we don’t 
> > have  mention any connection/relationship between  gp/tp usage and the 
> > specific UEFI firmware implementation. The sentence must be also generic to 
> > other UEFI firmware solutions such as edk2 which doesn't care about 
> > destroying gp/tp (so far).
>
> I fully agree that specifications precede implementations.
>
> >
> > In the RISC-V assembly programmer's handbook in RISC-V spec, gp/tp are not 
> > given either the caller or callee to save the value, so we can spec out 
> > something in UEFI spec based on this calling convention.
>
> Jessica Clarke pointed me to the "RISC-V ELF psABI specification"
> (https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md)
> which defines the usage of tp and gp in the RISC-V world:
>
> "In the standard ABI, procedures should not modify the integer registers
> tp and gp, because signal handlers may rely upon their values."
>
> So here the idea is that whoever serves interrupts and exceptions is the
> owner of gp and tp.
>
> After ExitBootServices() signals are served by the operating system. It
> takes hold of the values of tp and gp. See these lines of the Linux kernel:
>
> arch/riscv/kernel/entry.S:97:
> la gp, __global_pointer$
>
> arch/riscv/kernel/head.S:253:
> la tp, init_task
>
> Every time Linux enters kernel mode it again sets its own values of gp
> and tp. This addresses the security problem that you mentioned above.
>
> >
> > The sentence which I consider reasonable is ,
> > "In view of gp and tp registers are not assigned the specific owner to save 
> > and restore their values in the calling convention (refer to "RISC-V 
> > assembly programmer's handbook" section in RISC-V Unprivileged ISA 
> > specification), UEFI firmware must not having assumption of owning the 
> > write access to these register at any circumstances such as in EFI Boot 
> > service, EFI Runtime service, EFI Management Mode service and in any UEFI 
> > firmware interfaces which may invoked by the external firmware payload,  or 
> > altering the values of gp/tp registers results in the interference in the 
> > asynchronous callback to the external firmware payload . Whether and how to 
> > preserve gp and tp during UEFI firmware environment is UEFI firmware 
> > implementation-specific. RISC-V platform firmware integrator should refer 
> > to the corresponding design specification of the particular UEFI firmware 
> > solution."
> >
>
> We should start with a reference of the "RISC-V ELF psABI specification"
> to explain the usage of gp and tp.
>
> It seems to be necessary and sufficient for the firmware to follow:
>
> * Don't trust the values of tp and gp when entered
>   from the payloads world.
> * If you need to change them, restore the values before returning.
> * Never touch tp and gp after ExitBootServices().
>
> The same should be observed by an interrupt or exception handler
> provided by an "alternative execution environment".
>
> Best regards
>
> Heinrich
>
> > I believe this initial sentence still needs some revises, please just 
> > modify above paragraph if you don't like it. We can keep discussing this  
> > ba

Re: [PATCH 1/1] GetMemoryMap(), handling of no-map DT property

[Ard Biesheuvel]

On Tue, 15 Sep 2020 at 17:33, Grant Likely  wrote:
>
>
>
> On 15/09/2020 15:16, Ard Biesheuvel wrote:
> > On Tue, 15 Sep 2020 at 17:05, Grant Likely  wrote:
> >>
> >>
> >>
> >> On 15/09/2020 14:46, Leif Lindholm wrote:
> >>> On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
> >>>>> The EFI stub in Linux removes /memreserve/ entries from the DT before
> >>>>> handing it to the kernel proper.
> >>>>>
> >>>>> commit 0ceac9e094b065fe3fec19669740f338d3480498
> >>>>> Author: Mark Salter 
> >>>>> Date:   Mon Sep 8 13:01:08 2014 -0400
> >>>>>
> >>>>>   efi/arm64: Fix fdt-related memory reservation
> >>>>
> >>>> Does that still make sense? I understand why it was done, but is it
> >>>> right to ignore those reservations outright?
> >>>
> >>> Yes. It is duplication of (sources of) information, forcing the
> >>> operating system to make runtime, or compile time, judgement calls of
> >>> which source(s) of information to respect.
> >>
> >> Not quite that simple. We're not talking about a clean cut-over from
> >> non-UEFI to UEFI platforms, but rather a phased transition where with a
> >> given DT, both the non-UEFI and UEFI boot paths need to work. e.g.,
> >> U-Boot platforms where most people are using 'bootm', but want to start
> >> encouraging them to use the UEFI infrastructure.
> >>
> >> Or in other words, the master source of information is the .dts file,
> >> not the firmware itself.
> >>
> >> The other issue is that the reserved memory region may not be about
> >> firmware at all, but rather a memory layout that is wanted only by the
> >> OS. Regardless of the approach we take here, those regions must be
> >> respected.
> >>
> >>>> As more U-Boot platforms
> >>>> turn on UEFI there could be unexpected consequences if the memory
> >>>> reservation block are silently ignored. I'm think that on the U-Boot
> >>>> platforms it is more likely that /memreserve/ is in use.
> >>>
> >>> That should also make it easy to intercept? Like putting a hook in the
> >>> DT update code that triggers build error/warning (or even update the
> >>> UEFI memory map) if someone is trying to memreserve with the UEFI
> >>> interface enabled.
> >>
> >> It should not be an error to use /memreserve/. That creates a hard break
> >> between UEFI and non-UEFI boot paths for /memreserve/. Updating the
> >> memory map is fine, which leads to the question of what memory type
> >> should be used?
> >>
> >> EfiBootServicesData: Memory still gets mapped in the linear map, but
> >> nothing protects it after ExitBootServices (would require leaving
> >> /memreserve/ intact so the OS knows to protect them).
> >>
> >> EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but
> >> causes a change in behaviour. The memory will not appear in the linear
> >> map. This will possibly cause problems with existing drivers
> >>
> >
> > I wouldn't expect so. Unlike /reserved-memory nodes, which can be
> > referenced by other nodes and explicitly tagged as reusable,
> > /memreserve/s are anonymous holes that are punched into the memory
> > map, so I don't see how a driver would be able to get a reference to
> > that memory (and gets its linear address if it _happens_ to be in
> > lowmem in the first place.)
>
> In the typical use case, the driver doesn't directly use the
> /memreserve/ entry, but rather knowledge of the hole is implicit; the
> driver expects it to exist via some other mechanism. E.g., a property in
> the device node. If /memreserve/ gets cleared out, the device node will
> probably still try to use the region as if it had been reserved.
>
> e.g.:
> powerpc/boot/dts/akebono.dts: <0x1f0 0x10> is reserved, and then
> used in the cpu-release-address property. This is a case where the
> memory should still be in the linear map.
>

That depends on how the boot CPU accesses this memory - a quick scan
shows that many drivers ioremap() this address rather than access it
via the linear mapping.

> These are old use cases, and /memreserve/ is definitely deprecated in
> favour of the /reserved-memory node, but it has users and I absolutely
> do not want to create barriers to adopting the UEFI boot flow.
>
> >> EfiRuntimeServicesData: Keeps the regio

Re: [PATCH 1/1] GetMemoryMap(), handling of no-map DT property

[Ard Biesheuvel]

On Tue, 15 Sep 2020 at 17:05, Grant Likely  wrote:
>
>
>
> On 15/09/2020 14:46, Leif Lindholm wrote:
> > On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
> >>> The EFI stub in Linux removes /memreserve/ entries from the DT before
> >>> handing it to the kernel proper.
> >>>
> >>> commit 0ceac9e094b065fe3fec19669740f338d3480498
> >>> Author: Mark Salter 
> >>> Date:   Mon Sep 8 13:01:08 2014 -0400
> >>>
> >>>  efi/arm64: Fix fdt-related memory reservation
> >>
> >> Does that still make sense? I understand why it was done, but is it
> >> right to ignore those reservations outright?
> >
> > Yes. It is duplication of (sources of) information, forcing the
> > operating system to make runtime, or compile time, judgement calls of
> > which source(s) of information to respect.
>
> Not quite that simple. We're not talking about a clean cut-over from
> non-UEFI to UEFI platforms, but rather a phased transition where with a
> given DT, both the non-UEFI and UEFI boot paths need to work. e.g.,
> U-Boot platforms where most people are using 'bootm', but want to start
> encouraging them to use the UEFI infrastructure.
>
> Or in other words, the master source of information is the .dts file,
> not the firmware itself.
>
> The other issue is that the reserved memory region may not be about
> firmware at all, but rather a memory layout that is wanted only by the
> OS. Regardless of the approach we take here, those regions must be
> respected.
>
> >> As more U-Boot platforms
> >> turn on UEFI there could be unexpected consequences if the memory
> >> reservation block are silently ignored. I'm think that on the U-Boot
> >> platforms it is more likely that /memreserve/ is in use.
> >
> > That should also make it easy to intercept? Like putting a hook in the
> > DT update code that triggers build error/warning (or even update the
> > UEFI memory map) if someone is trying to memreserve with the UEFI
> > interface enabled.
>
> It should not be an error to use /memreserve/. That creates a hard break
> between UEFI and non-UEFI boot paths for /memreserve/. Updating the
> memory map is fine, which leads to the question of what memory type
> should be used?
>
> EfiBootServicesData: Memory still gets mapped in the linear map, but
> nothing protects it after ExitBootServices (would require leaving
> /memreserve/ intact so the OS knows to protect them).
>
> EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but
> causes a change in behaviour. The memory will not appear in the linear
> map. This will possibly cause problems with existing drivers
>

I wouldn't expect so. Unlike /reserved-memory nodes, which can be
referenced by other nodes and explicitly tagged as reusable,
/memreserve/s are anonymous holes that are punched into the memory
map, so I don't see how a driver would be able to get a reference to
that memory (and gets its linear address if it _happens_ to be in
lowmem in the first place.)

> EfiRuntimeServicesData: Keeps the region protected and in the linear
> map, but feels 'wrong'. An OS might decide to reclaim it anyway if it
> doesn't use runtime services (against spec?).
>

EfiRuntimeServicesData is not covered by the linear map, but will map
it in the EFI page tables for access by the firmware itself at
runtime, so it is not an option here.


>
> >
> >> It should be fine for /memreserve/ entries to get applied to the memmap
> >> during boot. Are there problems that I'm missing?
> >
> > Sure. They can be applied in the UEFI memory map. By u-boot, during
> > boot.
> >
> > /
> >  Leif
> >
> >> g.
> >> IMPORTANT NOTICE: The contents of this email and any attachments are 
> >> confidential and may also be privileged. If you are not the intended 
> >> recipient, please notify the sender immediately and do not disclose the 
> >> contents to any other person, use it for any purpose, or store or copy the 
> >> information in any medium. Thank you.
> >> ___
> >> boot-architecture mailing list
> >> boot-architecture@lists.linaro.org
> >> https://lists.linaro.org/mailman/listinfo/boot-architecture
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH 1/1] GetMemoryMap(), handling of no-map DT property

[Ard Biesheuvel]

On Tue, 15 Sep 2020 at 16:15, Grant Likely  wrote:
>
> On 15/09/2020 14:02, Ard Biesheuvel wrote:
> > On Tue, 15 Sep 2020 at 15:59, Grant Likely  wrote:
> >>
> >>
> >>
> >> On 15/09/2020 13:35, Ard Biesheuvel wrote:
> >>> On Tue, 15 Sep 2020 at 15:34, Grant Likely  wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 15/09/2020 13:25, Ard Biesheuvel wrote:
> >>>>> On Tue, 15 Sep 2020 at 15:22, Grant Likely  wrote:
> >>>>>>
> >>>>>> On 15/09/2020 09:33, Heinrich Schuchardt wrote:
> >>>>>>> Closes: #52
> >>>>>>>
> >>>>>>> The no-map property of the /reserved-memory device tree nodes is used 
> >>>>>>> to
> >>>>>>> signal that a memory region shall not be accessed by the operating 
> >>>>>>> system,
> >>>>>>> even not via speculative access.
> >>>>>>>
> >>>>>>> /reserved-memory nodes without the no-map property describe memory 
> >>>>>>> that
> >>>>>>> have special usage by the operating system.
> >>>>>>>
> >>>>>>> This difference has to be reflected in the memory map returned by
> >>>>>>> GetMemoryMap().
> >>>>>>>
> >>>>>>> Signed-off-by: Heinrich Schuchardt 
> >>>>>>> ---
> >>>>>>>  source/chapter2-uefi.rst | 13 +
> >>>>>>>  source/references.rst|  4 
> >>>>>>>  2 files changed, 17 insertions(+)
> >>>>>>>
> >>>>>>> diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> >>>>>>> index 74ef70e..f410c57 100644
> >>>>>>> --- a/source/chapter2-uefi.rst
> >>>>>>> +++ b/source/chapter2-uefi.rst
> >>>>>>> @@ -74,6 +74,19 @@ that virtual addresses must equal physical 
> >>>>>>> addresses.
> >>>>>>>
> >>>>>>>  The default RAM allocated attribute must be EFI_MEMORY_WB.
> >>>>>>>
> >>>>>>> +In the device tree reserved memory in modelled as a /reserved-memory 
> >>>>>>> nodes
> >>>>>>> +[RESMEM]_. The reserved-memory node MAY carry either the no-map or 
> >>>>>>> the resue
> >>>>>>> +property. It MUST NOT carry both properties as this would be 
> >>>>>>> contradictary.
> >>>>>>> +
> >>>>>> After having looked at reserved-memory.txt in the kernel and the
> >>>>>> devicetree spec, I think this should just go straight into dtspec or
> >>>>>> into the kernel tree. I drafted a couple patches yesterday that first
> >>>>>> imports /reserved-memory into dtspec, and then adds the UEFI
> >>>>>> annotations. Here's the current patch for the latter:
> >>>>>>
> >>>>>> 
> >>>>>>
> >>>>>> diff --git a/source/chapter3-devicenodes.rst
> >>>>>> b/source/chapter3-devicenodes.rst
> >>>>>> index 3043b8a..647e487 100644
> >>>>>> --- a/source/chapter3-devicenodes.rst
> >>>>>> +++ b/source/chapter3-devicenodes.rst
> >>>>>> @@ -160,6 +160,12 @@ If the VLE storage attribute is supported, with 
> >>>>>> VLE=0.
> >>>>>>  .. note:: All other standard properties (section
> >>>>>> :ref:`sect-standard-properties`) are allowed but are optional.
> >>>>>>
> >>>>>> +``/memory`` node and UEFI
> >>>>>> +~~
> >>>>>> +
> >>>>>> +When booting via [UEFI]_, the system memory map is obtained via the
> >>>>>> +GetMemoryMap() UEFI boot time service as defined in [UEFI]_ § 7.2,
> >>>>>> +and if present, the OS must ignore any ``/memory`` nodes.
> >>>>>>
> >>>>>
> >>>>> This should cover /memreserve/ entries as well.
> >>>>
> >>>> What memory type should be used for /memreserve/? The memory reserve
> >>>> block isn't nearly as expressive, so we don

Re: [PATCH 1/1] GetMemoryMap(), handling of no-map DT property

[Ard Biesheuvel]

On Tue, 15 Sep 2020 at 15:59, Grant Likely  wrote:
>
>
>
> On 15/09/2020 13:35, Ard Biesheuvel wrote:
> > On Tue, 15 Sep 2020 at 15:34, Grant Likely  wrote:
> >>
> >>
> >>
> >> On 15/09/2020 13:25, Ard Biesheuvel wrote:
> >>> On Tue, 15 Sep 2020 at 15:22, Grant Likely  wrote:
> >>>>
> >>>> On 15/09/2020 09:33, Heinrich Schuchardt wrote:
> >>>>> Closes: #52
> >>>>>
> >>>>> The no-map property of the /reserved-memory device tree nodes is used to
> >>>>> signal that a memory region shall not be accessed by the operating 
> >>>>> system,
> >>>>> even not via speculative access.
> >>>>>
> >>>>> /reserved-memory nodes without the no-map property describe memory that
> >>>>> have special usage by the operating system.
> >>>>>
> >>>>> This difference has to be reflected in the memory map returned by
> >>>>> GetMemoryMap().
> >>>>>
> >>>>> Signed-off-by: Heinrich Schuchardt 
> >>>>> ---
> >>>>> source/chapter2-uefi.rst | 13 +
> >>>>> source/references.rst|  4 
> >>>>> 2 files changed, 17 insertions(+)
> >>>>>
> >>>>> diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> >>>>> index 74ef70e..f410c57 100644
> >>>>> --- a/source/chapter2-uefi.rst
> >>>>> +++ b/source/chapter2-uefi.rst
> >>>>> @@ -74,6 +74,19 @@ that virtual addresses must equal physical addresses.
> >>>>>
> >>>>> The default RAM allocated attribute must be EFI_MEMORY_WB.
> >>>>>
> >>>>> +In the device tree reserved memory in modelled as a /reserved-memory 
> >>>>> nodes
> >>>>> +[RESMEM]_. The reserved-memory node MAY carry either the no-map or the 
> >>>>> resue
> >>>>> +property. It MUST NOT carry both properties as this would be 
> >>>>> contradictary.
> >>>>> +
> >>>> After having looked at reserved-memory.txt in the kernel and the
> >>>> devicetree spec, I think this should just go straight into dtspec or
> >>>> into the kernel tree. I drafted a couple patches yesterday that first
> >>>> imports /reserved-memory into dtspec, and then adds the UEFI
> >>>> annotations. Here's the current patch for the latter:
> >>>>
> >>>> 
> >>>>
> >>>> diff --git a/source/chapter3-devicenodes.rst
> >>>> b/source/chapter3-devicenodes.rst
> >>>> index 3043b8a..647e487 100644
> >>>> --- a/source/chapter3-devicenodes.rst
> >>>> +++ b/source/chapter3-devicenodes.rst
> >>>> @@ -160,6 +160,12 @@ If the VLE storage attribute is supported, with 
> >>>> VLE=0.
> >>>> .. note:: All other standard properties (section
> >>>>:ref:`sect-standard-properties`) are allowed but are optional.
> >>>>
> >>>> +``/memory`` node and UEFI
> >>>> +~~
> >>>> +
> >>>> +When booting via [UEFI]_, the system memory map is obtained via the
> >>>> +GetMemoryMap() UEFI boot time service as defined in [UEFI]_ § 7.2,
> >>>> +and if present, the OS must ignore any ``/memory`` nodes.
> >>>>
> >>>
> >>> This should cover /memreserve/ entries as well.
> >>
> >> What memory type should be used for /memreserve/? The memory reserve
> >> block isn't nearly as expressive, so we don't have details about how to
> >> use it. Be conservative and specify EfiReservedMemoryType?
> >>
> >
> > Currently, we simply ignore memreserve's like we ignore the memory
> > nodes as well.
>
> Looks like in Linux the memory is reserved without the nomap behaviour
> (not removed). Unlike with /reserved-memory, EfiBootServicesData won't
> currently give us the behaviour we want if the kernel is currently
> ignoring the memory reserved block. (for /reserved-memory, the kernel
> 'finds' the reservations again during early boot, so the UEFI
> protections only need to extend to the ExitBootServices() call. With the
> memory reserved block, the kernel has no way to know if it should
> continue to respect those reservations after ExitBootServices if it
> isn't parsing the block.
>
> Should the kernel still respect Memory Reserved block when booting via
> UEFI? At this point I'm inclined to say yes.
>

The EFI stub in Linux removes /memreserve/ entries from the DT before
handing it to the kernel proper.

commit 0ceac9e094b065fe3fec19669740f338d3480498
Author: Mark Salter 
Date:   Mon Sep 8 13:01:08 2014 -0400

   efi/arm64: Fix fdt-related memory reservation
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH 1/1] GetMemoryMap(), handling of no-map DT property

[Ard Biesheuvel]

On Tue, 15 Sep 2020 at 15:34, Grant Likely  wrote:
>
>
>
> On 15/09/2020 13:25, Ard Biesheuvel wrote:
> > On Tue, 15 Sep 2020 at 15:22, Grant Likely  wrote:
> >>
> >> On 15/09/2020 09:33, Heinrich Schuchardt wrote:
> >>> Closes: #52
> >>>
> >>> The no-map property of the /reserved-memory device tree nodes is used to
> >>> signal that a memory region shall not be accessed by the operating system,
> >>> even not via speculative access.
> >>>
> >>> /reserved-memory nodes without the no-map property describe memory that
> >>> have special usage by the operating system.
> >>>
> >>> This difference has to be reflected in the memory map returned by
> >>> GetMemoryMap().
> >>>
> >>> Signed-off-by: Heinrich Schuchardt 
> >>> ---
> >>>source/chapter2-uefi.rst | 13 +
> >>>source/references.rst|  4 
> >>>2 files changed, 17 insertions(+)
> >>>
> >>> diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> >>> index 74ef70e..f410c57 100644
> >>> --- a/source/chapter2-uefi.rst
> >>> +++ b/source/chapter2-uefi.rst
> >>> @@ -74,6 +74,19 @@ that virtual addresses must equal physical addresses.
> >>>
> >>>The default RAM allocated attribute must be EFI_MEMORY_WB.
> >>>
> >>> +In the device tree reserved memory in modelled as a /reserved-memory 
> >>> nodes
> >>> +[RESMEM]_. The reserved-memory node MAY carry either the no-map or the 
> >>> resue
> >>> +property. It MUST NOT carry both properties as this would be 
> >>> contradictary.
> >>> +
> >> After having looked at reserved-memory.txt in the kernel and the
> >> devicetree spec, I think this should just go straight into dtspec or
> >> into the kernel tree. I drafted a couple patches yesterday that first
> >> imports /reserved-memory into dtspec, and then adds the UEFI
> >> annotations. Here's the current patch for the latter:
> >>
> >> 
> >>
> >> diff --git a/source/chapter3-devicenodes.rst
> >> b/source/chapter3-devicenodes.rst
> >> index 3043b8a..647e487 100644
> >> --- a/source/chapter3-devicenodes.rst
> >> +++ b/source/chapter3-devicenodes.rst
> >> @@ -160,6 +160,12 @@ If the VLE storage attribute is supported, with VLE=0.
> >>.. note:: All other standard properties (section
> >>   :ref:`sect-standard-properties`) are allowed but are optional.
> >>
> >> +``/memory`` node and UEFI
> >> +~~
> >> +
> >> +When booting via [UEFI]_, the system memory map is obtained via the
> >> +GetMemoryMap() UEFI boot time service as defined in [UEFI]_ § 7.2,
> >> +and if present, the OS must ignore any ``/memory`` nodes.
> >>
> >
> > This should cover /memreserve/ entries as well.
>
> What memory type should be used for /memreserve/? The memory reserve
> block isn't nearly as expressive, so we don't have details about how to
> use it. Be conservative and specify EfiReservedMemoryType?
>

Currently, we simply ignore memreserve's like we ignore the memory
nodes as well.


>
> >
> >>``/memory`` Examples
> >>
> >> @@ -314,6 +320,9 @@ is ignored.
> >>The ``no-map`` and ``reusable`` properties are mutually exclusive and
> >> both must
> >>not be used together in the same node.
> >>
> >> +Dynamic reserved memory regions must not listed in the [UEFI]_ memory map
> >
> > not be listed
> >
> >> +because they are allocated by the OS after exiting firmware boot services.
> >> +
> >>Linux implementation notes:
> >>
> >>- If a ``linux,cma-default`` property is present, then Linux will use 
> >> the
> >> @@ -341,6 +350,19 @@ nodes by adding a ``memory-region`` property to the
> >> device node.
> >>   Usage legend: R=Required, O=Optional, OR=Optional but Recommended,
> >> SD=See Definition
> >>
> >> ===
> >>
> >> +``/reserved-memory`` and UEFI
> >> +~
> >> +When booting via [UEFI]_, static ``/reserved-memory`` regions must
> >> +also be listed in the system memory map obtained via the GetMemoryMap()
> >> +UEFI boot time se

Re: [PATCH 1/1] GetMemoryMap(), handling of no-map DT property

[Ard Biesheuvel]

On Tue, 15 Sep 2020 at 15:22, Grant Likely  wrote:
>
> On 15/09/2020 09:33, Heinrich Schuchardt wrote:
> > Closes: #52
> >
> > The no-map property of the /reserved-memory device tree nodes is used to
> > signal that a memory region shall not be accessed by the operating system,
> > even not via speculative access.
> >
> > /reserved-memory nodes without the no-map property describe memory that
> > have special usage by the operating system.
> >
> > This difference has to be reflected in the memory map returned by
> > GetMemoryMap().
> >
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> >   source/chapter2-uefi.rst | 13 +
> >   source/references.rst|  4 
> >   2 files changed, 17 insertions(+)
> >
> > diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> > index 74ef70e..f410c57 100644
> > --- a/source/chapter2-uefi.rst
> > +++ b/source/chapter2-uefi.rst
> > @@ -74,6 +74,19 @@ that virtual addresses must equal physical addresses.
> >
> >   The default RAM allocated attribute must be EFI_MEMORY_WB.
> >
> > +In the device tree reserved memory in modelled as a /reserved-memory nodes
> > +[RESMEM]_. The reserved-memory node MAY carry either the no-map or the 
> > resue
> > +property. It MUST NOT carry both properties as this would be contradictary.
> > +
> After having looked at reserved-memory.txt in the kernel and the
> devicetree spec, I think this should just go straight into dtspec or
> into the kernel tree. I drafted a couple patches yesterday that first
> imports /reserved-memory into dtspec, and then adds the UEFI
> annotations. Here's the current patch for the latter:
>
> 
>
> diff --git a/source/chapter3-devicenodes.rst
> b/source/chapter3-devicenodes.rst
> index 3043b8a..647e487 100644
> --- a/source/chapter3-devicenodes.rst
> +++ b/source/chapter3-devicenodes.rst
> @@ -160,6 +160,12 @@ If the VLE storage attribute is supported, with VLE=0.
>   .. note:: All other standard properties (section
>  :ref:`sect-standard-properties`) are allowed but are optional.
>
> +``/memory`` node and UEFI
> +~~
> +
> +When booting via [UEFI]_, the system memory map is obtained via the
> +GetMemoryMap() UEFI boot time service as defined in [UEFI]_ § 7.2,
> +and if present, the OS must ignore any ``/memory`` nodes.
>

This should cover /memreserve/ entries as well.

>   ``/memory`` Examples
>   
> @@ -314,6 +320,9 @@ is ignored.
>   The ``no-map`` and ``reusable`` properties are mutually exclusive and
> both must
>   not be used together in the same node.
>
> +Dynamic reserved memory regions must not listed in the [UEFI]_ memory map

not be listed

> +because they are allocated by the OS after exiting firmware boot services.
> +
>   Linux implementation notes:
>
>   - If a ``linux,cma-default`` property is present, then Linux will use the
> @@ -341,6 +350,19 @@ nodes by adding a ``memory-region`` property to the
> device node.
>  Usage legend: R=Required, O=Optional, OR=Optional but Recommended,
> SD=See Definition
>
> ===
>
> +``/reserved-memory`` and UEFI
> +~
> +When booting via [UEFI]_, static ``/reserved-memory`` regions must
> +also be listed in the system memory map obtained via the GetMemoryMap()
> +UEFI boot time service as defined in [UEFI]_ § 7.2.
> +The reserved memory regions need to be included in the UEFI memory map to
> +protect them from memory allocations by UEFI applications.
> +
> +Reserved regions with the ``no-map`` property must be listed in the memory
> +map with type ``EfiReservedMemoryType``.
> +All other reserved regions must be listed with the type
> +``EfiBootServicesData``.
> +
>   ``/reserved-memory`` Example
>   
>
> diff --git a/source/references.rst b/source/references.rst
> index 961fa20..8400e96 100644
> --- a/source/references.rst
> +++ b/source/references.rst
> @@ -23,3 +23,7 @@
>   .. [EPAPR] *Power.org Standard for Embedded Power Architecture
>  Platform Requirements*, power.org, 2011,
>
> https://www.power.org/documentation/power-org-standard-for-embedded-power-architecture-platform-requirements-epapr-v1-1-2/
> +
> +.. [UEFI] `Unified Extensable Firmware Interface Specification v2.8
> Errata A
> +
> `_,
> +   February 2020, `UEFI Forum `_
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH 1/1] EBBR: GetMemoryMap(), handling of no-map DT property

[Ard Biesheuvel]

On Tue, 8 Sep 2020 at 09:39, Heinrich Schuchardt  wrote:
>
> On 07.09.20 16:56, Grant Likely wrote:
> >
> >
> > On 07/09/2020 15:55, Daniel Thompson wrote:
> >> On Mon, Sep 07, 2020 at 03:22:22PM +0100, Grant Likely wrote:
> >>> I've not heard back, and I've got a conflict this afternoon. I'm going
> >>> to resched for later in the week. Going to aim for Wednesday.
> >>
> >> Are you trying the schedule a full EBBR meeting or just a discussion
> >> about this thread?
> >
> > Only about this thread. The next EBBR meeting will be next week Monday.
> >
> > g.
> >
>
> Wednesday 17:30 UTC+2 would be fine for me.
>

Works for me
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH] Refine firmware shared storage requirements.

[Ard Biesheuvel]

On Wed, 2 Sep 2020 at 15:26, Heinrich Schuchardt  wrote:
>
> On 02.09.20 12:11, Daniel Thompson wrote:
> > On Tue, Sep 01, 2020 at 04:53:49PM +0200, Heinrich Schuchardt wrote:
> >> On 01.09.20 16:49, Daniel Thompson wrote:
> >>> On Tue, Sep 01, 2020 at 03:55:15PM +0200, Heinrich Schuchardt wrote:
>  On 01.09.20 12:59, Grant Likely wrote:
> > The existing language around how firmware and an OS can share a storage
> > device doesn't go into sufficient detail on how the firmware should
> > protect firmware data on the device. Add language for both the GPT and
> > MBR partitioning schemes on how firmware images should be described in
> > the partition table.
> >
> > Signed-off-by: Grant Likely 
> > ---
> >
> > I posted this patch before the v1.0.1 release, but didn't merge it at
> > that time because it needs a little more due diligence than can be give
> > on a minor point release. Posting it now for proper review.
> >
> >  source/chapter4-firmware-media.rst | 67 +++---
> >  1 file changed, 51 insertions(+), 16 deletions(-)
> >
> > diff --git a/source/chapter4-firmware-media.rst 
> > b/source/chapter4-firmware-media.rst
> > index fc71274..65da603 100644
> > --- a/source/chapter4-firmware-media.rst
> > +++ b/source/chapter4-firmware-media.rst
> > @@ -47,13 +47,19 @@ conflict with normal usage of the media by an OS.
> >  Partitioning of Shared Storage
> >  ==
> >
> > -A shared storage device shall use GPT partitioning unless it is 
> > incompatible
> > -with the platform boot sequence.
> > -In which case, MBR partitioning shall be used. [#MBRReqExample]_
> > -
> > -.. [#MBRReqExample] For example, if the boot ROM doesn't understand GPT
> > -   partitioning, and will only work with an MBR, then the storage must 
> > be
> > -   partitioned using an MBR.
> > +The shared storage device must use the GUID Partition Table (GPT) disk
> > +layout as defined in [UEFI]_ § 5.3, unless the platform boot sequence 
> > is
> > +fundamentally incompatible with the GPT disk layout.
> > +In which case, a legacy Master Boot Recored (MBR) must be used.
> > +[#MBRReqExample]_
> > +
> > +.. [#MBRReqExample] For example, if the SoC boot ROM requires an MBR to
> > +   find the next stage firmware image, then it is incompatible with
> > +   the GPT boot layout.
> > +   Similarly, if the boot ROM expects the next stage firmware to be 
> > located
> > +   at LBA1 (the location of the GPT Header), then it is incompatible 
> > with
> > +   the GPT disk layout.
> > +   In both cases the shared storage device must use legacy MBR 
> > partitioning.
> >
> >  .. warning::
> >
> > @@ -71,15 +77,14 @@ the partition(s) containing firmware.
> >
> >  However, some SoCs load firmware from a fixed offset into the storage 
> > media.
> >  In this case, to protect against partitioning tools overwriting 
> > firmware, the
> > -firmware image shall either reside entirely within the first 1MiB of 
> > storage,
> > -or should be covered by a protective partition entry in the partition 
> > table as
> > +partition table must be formed in a way to protect the firmware 
> > image(s) as
> >  described in sections :ref:`section-gpt-parts` and 
> > :ref:`section-mbr-parts`.
> >
> > -Automatic partitioning tools (e.g. an OS installer) must not create
> > -partitions within the first 1MiB of storage, or delete, move, or modify
> > -protective partition entries.
> > +Automatic partitioning tools (e.g. an OS installer) must not
> > +delete the protective information in the partition table, or
> > +delete, move, or modify protective partition entries.
> >  Manual partitioning tools should provide warnings when modifying
> > -protective partitions or creating partitions within the first 1MiB.
> > +protective partitions.
> >
> >  .. warning::
> >
> > @@ -95,19 +100,49 @@ GPT partitioning
> >  
> >
> >  The partition table must strictly conform to the UEFI specification 
> > and include
> > -a protective MBR authored exactly as described in [UEFI]_ § 5 (hybrid
> > +a protective MBR authored exactly as described in [UEFI]_ § 5.3 (hybrid
> >  partitioning schemes are not permitted).
> >
> > -Protective partitions must have the Platform Required Attribute Flag 
> > set.
> > +Fixed-location firmware images must be protected by creating protective
> > +partition entries, or by placing GPT data structures away from the LBAs
> > +occupied by firmware,
> > +
> > +Protective partitions are entries in the partition table that cover the
> > +LBA region occupied by firmware and have the 'Required Partition' 
> > attribute
> 

Re: [PATCH 1/1] EBBR: GetMemoryMap(), handling of no-map DT property

[Ard Biesheuvel]

On Wed, 2 Sep 2020 at 09:48, Heinrich Schuchardt  wrote:
>
> On 9/1/20 10:51 AM, Ard Biesheuvel wrote:
> > On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt  wrote:
> >>
> >> On 8/31/20 9:01 PM, Ard Biesheuvel wrote:
> >>> On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt  
> >>> wrote:
> >>>>
> >>>> Closes: #52
> >>>>
> >>>> The no-map property of the /reserved-memory DT node is used by Linux to
> >>>> signal that a memory region shall not be mapped and that speculative 
> >>>> access
> >>>> shall not be permitted.
> >>>>
> >>>> The memory map returned by GetMemoryMap() does not have a flag
> >>>> corresponding to no-map. So the closest thing we can do is not to include
> >>>> no-map reserved memory into the map returned by GetMemoryMap().
> >>>>
> >>
> >> Dear Ard,
> >>
> >> thanks for reviewing.
> >>
> >>>
> >>> This violates the UEFI spec, which stipulates that the memory map
> >>> describes all memory, no matter how it is used. It also interferes
> >>> with the heuristics we use in Linux to decide which memory attributes
> >>> to use when the code gets mapped explicitly (i.e., by a driver), which
> >>> is permitted in the context of the /reserved-memory node (the no-map
> >>> attribute applies to the linear map, but the region may still be
> >>> mapped for other reasons). Note that an omitted region cannot carry
> >>> EFI_MEMORY_WC/WT/WB attributes either.
> >>
> >> Do you have an example of a no-map /reserved-memory node used in Linux?
> >>
> >
> > Linux ignores DT provided memory reservations entirely when booting in
> > UEFI mode, which is why it is important that the EFI memory map is
> > synchronized. I am not aware of any examples.
>
> Hello Ard,
>
> I found the following compatibility strings for no-map areas in the
> Linux device trees:
>
> compatible = "shared-dma-pool"
> compatible = "qcom,rmtfs-mem"
> compatible = "qcom,cmd-db"
>
> If Linux simply ignores the no-map property from the device-tree when
> booting via UEFI and in UEFI we simply map those areas as reserved,
> there is a conceptual gap as you already stated in a separate mail.
>

There is definitely a gap, but reserved regions are already omitted
from the linear map in Linux, so that is not a problem, i.e., the
'no-map' will be honoured as long as the firmware ensures that no-map
regions are described as EfiReservedMemory.

In other words, today we just assume that the /reserved-memory node
and the EFI memory map do not contradict each other, but we have no
definition or explicit requirement anywhere what that actually means.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [EBBR RFC] Remove the exclusive-or language around DT or ACPI

[Ard Biesheuvel]

On Tue, 1 Sep 2020 at 14:26, Peter Robinson  wrote:
>
> On Tue, Sep 1, 2020 at 12:21 PM Grant Likely  wrote:
> >
> >
> >
> > On 01/09/2020 12:06, Heinrich Schuchardt wrote:
> > > On 9/1/20 12:45 PM, Grant Likely wrote:
> > >> Early in EBBR discussions the decision was made that firmware should not
> > >> provide both DT and ACPI at the same time. The reasoning had been that
> > >> we didn't want to encourage 'hybrid' approaches where the OS tries to
> > >> consume both DT and ACPI descriptions.
> > >>
> > >> However, this fear has not so-far born out, and feedback has been that
> > >> requiring a boot-time switch to select either DT or ACPI is a support
> > >> issue for OS vendors. They would rather see ACPI (or DT) always turned
> > >> on if it is an option and the OS can choose to use it or not.
> > >
> > > Which OS vendor are your referring to?
> > >
> > > Why does that OS vendor not implement both ACPI and DT support to
> > > encompass as many devices as possible?
> >
> > Sure; in concrete terms, this is what I see among the major OSes:
> >
> > Linux: support both; consumes DT by default. (some distros change the
> > preference; "acpi=force" forces kernel to use ACPI instead) [1]
> > BSD: Both (?)
> > Windows: ACPI only
> > VMware ESXi on Arm: ACPI only
> RHEL on Arm: ACPI only.
>
> > > What would we expect to happen if the ACPI and DT content are not
> > > equivalent?
> >
> > Then the OS would get the functionality of whichever system description
> > it chose. The experiments with ACPI-only OSes on Arm SBCs have shown
> > that there is interest in supporting the platforms, even if the initial
> > functionality is reduced due the not all hardware having a usable ACPI
> > description (lots of reasons for this from hardware design not fitting
> > nicely into the ACPI model, to lack of bindings, to just hasn't been
> > looked at yet)
>
> Also network and storage interface, possibly others, names often
> change just due to the way naming//bindings/IDs are handled between
> the two.
>

The crux of the matter is that platform X described via ACPI cannot be
assumed to be the same as platform X described via DT. Peter points
out the device naming changes due to different enumeration order, but
there are many other issues (NUMA topology, RAS features etc). So
there can be no guarantee whatsoever on OSes that are able to support
both descriptions that any OS or HW configuration state can be
preserved across a switch from ACPI to DT or vice versa.

I understand how on the face of it, permitting both to coexist might
seem like the easiest approach from the platform vendor POV, but I
think this is a mistake. Making it the system's job to choose one
description or the other removes any ambiguity, and therefore prevents
problems. I understand how OSVs like MS entering the space that has
historically been dominated by DT are eager to make the switch
seamless for them, but doing so creates problems for Linux, so I would
prefer not to go down this path.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH 1/1] EBBR: GetMemoryMap(), handling of no-map DT property

[Ard Biesheuvel]

On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt  wrote:
>
> On 8/31/20 9:01 PM, Ard Biesheuvel wrote:
> > On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt  
> > wrote:
> >>
> >> Closes: #52
> >>
> >> The no-map property of the /reserved-memory DT node is used by Linux to
> >> signal that a memory region shall not be mapped and that speculative access
> >> shall not be permitted.
> >>
> >> The memory map returned by GetMemoryMap() does not have a flag
> >> corresponding to no-map. So the closest thing we can do is not to include
> >> no-map reserved memory into the map returned by GetMemoryMap().
> >>
>
> Dear Ard,
>
> thanks for reviewing.
>
> >
> > This violates the UEFI spec, which stipulates that the memory map
> > describes all memory, no matter how it is used. It also interferes
> > with the heuristics we use in Linux to decide which memory attributes
> > to use when the code gets mapped explicitly (i.e., by a driver), which
> > is permitted in the context of the /reserved-memory node (the no-map
> > attribute applies to the linear map, but the region may still be
> > mapped for other reasons). Note that an omitted region cannot carry
> > EFI_MEMORY_WC/WT/WB attributes either.
>
> Do you have an example of a no-map /reserved-memory node used in Linux?
>

Linux ignores DT provided memory reservations entirely when booting in
UEFI mode, which is why it is important that the EFI memory map is
synchronized. I am not aware of any examples.

> >
> > So a better approach would be to mandate that these regions are listed
> > in the EFI memory map as EFI reserved regions, with appropriate memory
> > attributes. (Note that on ARM, regions that are really memory rather
> > than MMIO registers, and that are expected to be used with unaligned
> > accesses and/or DC ZVA instructions must be mapped as memory, and so
> > the default of EFI_MEMORY_UC is not appropriate)
> >
>
> It is unclear to me which memory attributes you regard as appropriate.
>

Memory attributes (WB/WT/WC) as opposed to device attributes (UC). A
region mapped as device memory does not behave as memory in terms of
the architecture or the UEFI bindings for ARM (which specify that
unaligned accesses should be permitted, for instance)
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH] EBBR: ResetSystem has return type void

[Ard Biesheuvel]

On Mon, 31 Aug 2020 at 19:38, Heinrich Schuchardt  wrote:
>
> Closes: #50
>
> ResetSystem() has return type void. So it cannot return EFI_UNSUPPORTED.
>
> Signed-off-by: Heinrich Schuchardt 

Acked-by: Ard Biesheuvel 

> ---
>  source/chapter2-uefi.rst | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> index 2add2de..74ef70e 100644
> --- a/source/chapter2-uefi.rst
> +++ b/source/chapter2-uefi.rst
> @@ -209,9 +209,10 @@ ResetSystem() is required to be implemented in boot 
> services, but it is
>  optional for runtime services.
>  During runtime services, the operating system should first attempt to
>  use ResetSystem() to reset the system.
> -If firmware doesn't support ResetSystem() during runtime services,
> -then the call will immediately return EFI_UNSUPPORTED, and the OS should
> -fall back to an architecture or platform specific reset mechanism.
> +
> +If firmware doesn't support ResetSystem() during runtime services, then the 
> call
> +will immediately return, and the OS should fall back to an architecture or
> +platform specific reset mechanism.
>
>  On AArch64 platforms implementing [PSCI]_,
>  if ResetSystem() is not implemented then the Operating System should fall
> --
> 2.28.0
>
> ___
> boot-architecture mailing list
> boot-architecture@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH 1/1] EBBR: GetMemoryMap(), handling of no-map DT property

[Ard Biesheuvel]

On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt  wrote:
>
> Closes: #52
>
> The no-map property of the /reserved-memory DT node is used by Linux to
> signal that a memory region shall not be mapped and that speculative access
> shall not be permitted.
>
> The memory map returned by GetMemoryMap() does not have a flag
> corresponding to no-map. So the closest thing we can do is not to include
> no-map reserved memory into the map returned by GetMemoryMap().
>

This violates the UEFI spec, which stipulates that the memory map
describes all memory, no matter how it is used. It also interferes
with the heuristics we use in Linux to decide which memory attributes
to use when the code gets mapped explicitly (i.e., by a driver), which
is permitted in the context of the /reserved-memory node (the no-map
attribute applies to the linear map, but the region may still be
mapped for other reasons). Note that an omitted region cannot carry
EFI_MEMORY_WC/WT/WB attributes either.

So a better approach would be to mandate that these regions are listed
in the EFI memory map as EFI reserved regions, with appropriate memory
attributes. (Note that on ARM, regions that are really memory rather
than MMIO registers, and that are expected to be used with unaligned
accesses and/or DC ZVA instructions must be mapped as memory, and so
the default of EFI_MEMORY_UC is not appropriate)



> Signed-off-by: Heinrich Schuchardt 
> ---
>  source/chapter2-uefi.rst | 4 
>  source/references.rst| 4 
>  2 files changed, 8 insertions(+)
>
> diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> index 2add2de..1e57164 100644
> --- a/source/chapter2-uefi.rst
> +++ b/source/chapter2-uefi.rst
> @@ -74,6 +74,10 @@ that virtual addresses must equal physical addresses.
>
>  The default RAM allocated attribute must be EFI_MEMORY_WB.
>
> +Reserved memory with property no-map [RESMEM]_ in the /reserved-memory
> +device-tree node shall not be included in the memory map returned by
> +GetMemoryMap().
> +
>  Configuration Tables
>  
>
> diff --git a/source/references.rst b/source/references.rst
> index 1eb0509..2434137 100644
> --- a/source/references.rst
> +++ b/source/references.rst
> @@ -16,6 +16,10 @@
> 
> `_
> 30 January 2015, `Arm Limited `_
>
> +.. [RESMEM] `Reserved memory regions
> +   
> `_,
> +   21 July 2020, Linux kernel
> +
>  .. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0)
> 
> `_
> 8 March 2016, `Arm Limited `_
> --
> 2.28.0
>
> ___
> boot-architecture mailing list
> boot-architecture@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Storage of public key certificates for capsule authentication

[Ard Biesheuvel]

On Mon, 31 Aug 2020 at 20:14, François Ozog 
wrote:

>
>
> On Mon, 31 Aug 2020 at 19:07, Ard Biesheuvel  wrote:
>
>>
>>
>> On Mon, 31 Aug 2020 at 19:30, François Ozog 
>> wrote:
>>
>>>
>>>
>>> On Mon, 31 Aug 2020 at 17:16, Ard Biesheuvel  wrote:
>>>
>>>> On Fri, 28 Aug 2020 at 19:03, Sughosh Ganu 
>>>> wrote:
>>>> >
>>>> > hello Heinrich,
>>>> >
>>>> > On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt >>> >
>>>> > wrote:
>>>> >
>>>> > > On 28.08.20 14:19, Grant Likely wrote:
>>>> > > >
>>>> > > >
>>>> > > > On 28/08/2020 12:57, Sughosh Ganu wrote:
>>>> > > >> hi,
>>>> > > >> I am currently working on adding support for the capsule
>>>> authentication
>>>> > > >> in the SetImage function of the efi firmware management protocol
>>>> in
>>>> > > >> u-boot. This work is part of adding functionality in u-boot for
>>>> firmware
>>>> > > >> updates using the uefi capsule format.
>>>> > > >>
>>>> > > >> The capsule authentication is done using a public key stored as
>>>> a pkcs7
>>>> > > >> certificate. The uefi specification does not have any mention of
>>>> how
>>>> > > >> this certificate needs to be stored. This is unlike the case of
>>>> the
>>>> > > >> certificates used for image authentication when UEFI secure boot
>>>> feature
>>>> > > >> is enabled, where the certificates and hash values are stored as
>>>> part of
>>>> > > >> the authenticated variables like KEK, db, dbx.
>>>> > > >
>>>> > > > I don't think it makes sense to store the capsule authentication
>>>> in the
>>>> > > > KEK. PK and KEK is about the chain of trust between the platform
>>>> owner
>>>> > > > and one of many OSes that may be run on the platform. In the case
>>>> of a
>>>> > > > firmware update, it is an entirely different chain of trust. i.e.
>>>> we
>>>> > > > don't trust 3rd party OS vendors to also provide replacement
>>>> firmware
>>>> > > > images.
>>>> > > >
>>>> > > > The capsule update public key should be kept separately. For
>>>> convenience
>>>> > > > you could define another variable to hold that public key, but it
>>>> would
>>>> > > > be worth checking with the TF-A folks. It might make sense for
>>>> BL31 to
>>>> > > > be the holder of that key.
>>>> > > >
>>>> > > > g.
>>>> > > >
>>>> > > >> Can we use an authenticated variable like KEK to store the
>>>> certificate
>>>> > > >> used for authentication of the capsule payload. Would it make
>>>> sense to
>>>> > > >> have this mentioned in EBBR, or even the UEFI specification.
>>>> Please let
>>>> > > >> me know your thoughts. Thanks.
>>>> > >
>>>> > > Takahiro was working with FIT images as the content of the capsules.
>>>> > > U-Boot already has RSA signing for FIT images. Isn't that enough?
>>>> > >
>>>> > > Cf. u-boot/doc/uImage.FIT/signature.txt
>>>> >
>>>> >
>>>> > We do have the logic for verification of the signatures, and I have
>>>> used
>>>> > the same code for capsule authentication, which has been introduced by
>>>> > Takahiro for image authentication. My question was about storage of
>>>> the
>>>> > public key certificate -- whether it should be stored as a normal uefi
>>>> > variable, or as an authenticated variable.
>>>> >
>>>>
>>>> I agree with Grant here. The scopes of signed capsule update and UEFI
>>>> secure boot are entirely disjoint, and so there is no reason for the
>>>> sets of certificates to overlap either, especially because the scope
>>>> of signed capsule update is much narrower (i.e., any OS loader from
>>>> any OS vendor could potentially be install

Re: Storage of public key certificates for capsule authentication

[Ard Biesheuvel]

On Mon, 31 Aug 2020 at 19:30, François Ozog 
wrote:

>
>
> On Mon, 31 Aug 2020 at 17:16, Ard Biesheuvel  wrote:
>
>> On Fri, 28 Aug 2020 at 19:03, Sughosh Ganu 
>> wrote:
>> >
>> > hello Heinrich,
>> >
>> > On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt 
>> > wrote:
>> >
>> > > On 28.08.20 14:19, Grant Likely wrote:
>> > > >
>> > > >
>> > > > On 28/08/2020 12:57, Sughosh Ganu wrote:
>> > > >> hi,
>> > > >> I am currently working on adding support for the capsule
>> authentication
>> > > >> in the SetImage function of the efi firmware management protocol in
>> > > >> u-boot. This work is part of adding functionality in u-boot for
>> firmware
>> > > >> updates using the uefi capsule format.
>> > > >>
>> > > >> The capsule authentication is done using a public key stored as a
>> pkcs7
>> > > >> certificate. The uefi specification does not have any mention of
>> how
>> > > >> this certificate needs to be stored. This is unlike the case of the
>> > > >> certificates used for image authentication when UEFI secure boot
>> feature
>> > > >> is enabled, where the certificates and hash values are stored as
>> part of
>> > > >> the authenticated variables like KEK, db, dbx.
>> > > >
>> > > > I don't think it makes sense to store the capsule authentication in
>> the
>> > > > KEK. PK and KEK is about the chain of trust between the platform
>> owner
>> > > > and one of many OSes that may be run on the platform. In the case
>> of a
>> > > > firmware update, it is an entirely different chain of trust. i.e. we
>> > > > don't trust 3rd party OS vendors to also provide replacement
>> firmware
>> > > > images.
>> > > >
>> > > > The capsule update public key should be kept separately. For
>> convenience
>> > > > you could define another variable to hold that public key, but it
>> would
>> > > > be worth checking with the TF-A folks. It might make sense for BL31
>> to
>> > > > be the holder of that key.
>> > > >
>> > > > g.
>> > > >
>> > > >> Can we use an authenticated variable like KEK to store the
>> certificate
>> > > >> used for authentication of the capsule payload. Would it make
>> sense to
>> > > >> have this mentioned in EBBR, or even the UEFI specification.
>> Please let
>> > > >> me know your thoughts. Thanks.
>> > >
>> > > Takahiro was working with FIT images as the content of the capsules.
>> > > U-Boot already has RSA signing for FIT images. Isn't that enough?
>> > >
>> > > Cf. u-boot/doc/uImage.FIT/signature.txt
>> >
>> >
>> > We do have the logic for verification of the signatures, and I have used
>> > the same code for capsule authentication, which has been introduced by
>> > Takahiro for image authentication. My question was about storage of the
>> > public key certificate -- whether it should be stored as a normal uefi
>> > variable, or as an authenticated variable.
>> >
>>
>> I agree with Grant here. The scopes of signed capsule update and UEFI
>> secure boot are entirely disjoint, and so there is no reason for the
>> sets of certificates to overlap either, especially because the scope
>> of signed capsule update is much narrower (i.e., any OS loader from
>> any OS vendor could potentially be installed on a given system,
>> whereas only a single entity publishes firmware updates for it)
>>
>
> I'd like to see people's view on who signs what, in the following use case:
> - Car vendor A builds a car with tier1-1 and tier1-2 boards provided by
> silicon1 and silicon2.
> - TF-A, OP-TEE, SCMI-TA, U-Boot are provided by silicon1 for board1 and
> silicon2 for board2
> - board1 is an android auto board and has a DRM TA on board1 provided by
> Netflix
> - board2 is an AGL board provided by tier1-2
> Is the following correct?
> PK only cert should be issued by silicon1 and silicon2.
> KEK in board1 shall contain silicon1, android, Netflix certs
> KEK in board2 shall contain silicon2, tier1-2 certs
> DB shall contain the signatures of relevant images on each board.
> Shouldn't car vendor A have a way to insert itself in the chain of trust?
>
>
So you are assu

Re: Storage of public key certificates for capsule authentication

[Ard Biesheuvel]

On Mon, 31 Aug 2020 at 19:00, François Ozog  wrote:
>
> On Fri, 28 Aug 2020 at 18:03, Sughosh Ganu  wrote:
>
> > hello Heinrich,
> >
> > On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt 
> > wrote:
> >
> >> On 28.08.20 14:19, Grant Likely wrote:
> >> >
> >> >
> >> > On 28/08/2020 12:57, Sughosh Ganu wrote:
> >> >> hi,
> >> >> I am currently working on adding support for the capsule authentication
> >> >> in the SetImage function of the efi firmware management protocol in
> >> >> u-boot. This work is part of adding functionality in u-boot for
> >> firmware
> >> >> updates using the uefi capsule format.
> >> >>
> >> >> The capsule authentication is done using a public key stored as a pkcs7
> >> >> certificate. The uefi specification does not have any mention of how
> >> >> this certificate needs to be stored. This is unlike the case of the
> >> >> certificates used for image authentication when UEFI secure boot
> >> feature
> >> >> is enabled, where the certificates and hash values are stored as part
> >> of
> >> >> the authenticated variables like KEK, db, dbx.
> >> >
> >> > I don't think it makes sense to store the capsule authentication in the
> >> > KEK. PK and KEK is about the chain of trust between the platform owner
> >> > and one of many OSes that may be run on the platform. In the case of a
> >> > firmware update, it is an entirely different chain of trust. i.e. we
> >> > don't trust 3rd party OS vendors to also provide replacement firmware
> >> > images.
> >> >
> >> > The capsule update public key should be kept separately. For convenience
> >> > you could define another variable to hold that public key, but it would
> >> > be worth checking with the TF-A folks. It might make sense for BL31 to
> >> > be the holder of that key.
> >> >
> >> > g.
> >> >
> >> >> Can we use an authenticated variable like KEK to store the certificate
> >> >> used for authentication of the capsule payload. Would it make sense to
> >> >> have this mentioned in EBBR, or even the UEFI specification. Please let
> >> >> me know your thoughts. Thanks.
> >>
> >> Takahiro was working with FIT images as the content of the capsules.
> >> U-Boot already has RSA signing for FIT images. Isn't that enough?
> >>
> >> Cf. u-boot/doc/uImage.FIT/signature.txt
> >
> >
> > We do have the logic for verification of the signatures, and I have used
> > the same code for capsule authentication, which has been introduced by
> > Takahiro for image authentication. My question was about storage of the
> > public key certificate -- whether it should be stored as a normal uefi
> > variable, or as an authenticated variable.
> >
> > The list of accepted certificates should be in an authenticated variable
> ro avoid injection of an attacker cert.
>

Why should it be in a variable to begin with? It is common practice
for firmware images to have compiled-in certificates for firmware
update, which is all you typically need for production hardware. (For
development, you could add a jumper, or simply rely on a SPI flash
programmer to flash development images or debrick the hardware)

Reusing UEFI secure boot infrastructure for this is not supported by
requirements of the use case, but simply because the use cases seem
related at first glance, but they are really not. (The platform owner
should be in full control of the certificates that define the secure
boot policies, but updating the system firmware itself is usually
under OEM control, and has limitations related to warranty, support
etc)
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Storage of public key certificates for capsule authentication

[Ard Biesheuvel]

On Fri, 28 Aug 2020 at 19:03, Sughosh Ganu  wrote:
>
> hello Heinrich,
>
> On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt 
> wrote:
>
> > On 28.08.20 14:19, Grant Likely wrote:
> > >
> > >
> > > On 28/08/2020 12:57, Sughosh Ganu wrote:
> > >> hi,
> > >> I am currently working on adding support for the capsule authentication
> > >> in the SetImage function of the efi firmware management protocol in
> > >> u-boot. This work is part of adding functionality in u-boot for firmware
> > >> updates using the uefi capsule format.
> > >>
> > >> The capsule authentication is done using a public key stored as a pkcs7
> > >> certificate. The uefi specification does not have any mention of how
> > >> this certificate needs to be stored. This is unlike the case of the
> > >> certificates used for image authentication when UEFI secure boot feature
> > >> is enabled, where the certificates and hash values are stored as part of
> > >> the authenticated variables like KEK, db, dbx.
> > >
> > > I don't think it makes sense to store the capsule authentication in the
> > > KEK. PK and KEK is about the chain of trust between the platform owner
> > > and one of many OSes that may be run on the platform. In the case of a
> > > firmware update, it is an entirely different chain of trust. i.e. we
> > > don't trust 3rd party OS vendors to also provide replacement firmware
> > > images.
> > >
> > > The capsule update public key should be kept separately. For convenience
> > > you could define another variable to hold that public key, but it would
> > > be worth checking with the TF-A folks. It might make sense for BL31 to
> > > be the holder of that key.
> > >
> > > g.
> > >
> > >> Can we use an authenticated variable like KEK to store the certificate
> > >> used for authentication of the capsule payload. Would it make sense to
> > >> have this mentioned in EBBR, or even the UEFI specification. Please let
> > >> me know your thoughts. Thanks.
> >
> > Takahiro was working with FIT images as the content of the capsules.
> > U-Boot already has RSA signing for FIT images. Isn't that enough?
> >
> > Cf. u-boot/doc/uImage.FIT/signature.txt
>
>
> We do have the logic for verification of the signatures, and I have used
> the same code for capsule authentication, which has been introduced by
> Takahiro for image authentication. My question was about storage of the
> public key certificate -- whether it should be stored as a normal uefi
> variable, or as an authenticated variable.
>

I agree with Grant here. The scopes of signed capsule update and UEFI
secure boot are entirely disjoint, and so there is no reason for the
sets of certificates to overlap either, especially because the scope
of signed capsule update is much narrower (i.e., any OS loader from
any OS vendor could potentially be installed on a given system,
whereas only a single entity publishes firmware updates for it)
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [EBBR PATCH] Add EFI GUID for device tree blob

[Ard Biesheuvel]

On 5/13/20 2:48 PM, Grant Likely wrote:



On 12/05/2020 18:54, Ard Biesheuvel wrote:

On 5/12/20 7:23 PM, Grant Likely wrote:



On 12/05/2020 18:16, Ard Biesheuvel wrote:
On Tue, 12 May 2020 at 19:05, Grant Likely  
wrote:




On 07/05/2020 20:15, Daniel Thompson wrote:

On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote:
On Thu, 7 May 2020 at 16:50, Daniel Thompson 


wrote:

On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt 
wrote:

On 06.05.20 17:14, Ard Biesheuvel wrote:

On 5/6/20 5:01 PM, Grant Likely wrote:

On 06/05/2020 15:56, Ard Biesheuvel wrote:

On 5/6/20 4:54 PM, Grant Likely wrote:



On 06/05/2020 15:52, Ard Biesheuvel wrote:

On 5/6/20 4:38 PM, Grant Likely wrote:
Only if the door is wide open. If there is a /real need/ 
for a
limited set of changes to the dtb, then those specific 
cases can

be spelled out as things firmware is allowed to modify in a
replacement DTB. Any scenarios here need to be very 
specific.


What specific cases do we know about?



None. There is no way the firmware can currently 
manipulate the DTB
after the EFI stub has taken ownership of it. We load the 
firmware
provided one, copy it into a new allocation and make our 
changes

there. This version is the one that is passed to the OS.


Before ExitBootServices()?



Yes.


Right, so the kernel stub is completely out and language is 
needed for

when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???



No changes should be made to the DTB after it has been 
installed as a

config table.

Second, if an Efi application replaces the DTB, what are the 
known
scenarios for wanting firmware to apply fixups to the DTB 
(again; need

to be very specific)



None. The firmware should not expect to be given the 
opportunity to

tweak the DTB after it hands off to the next stage.


This would imply that GRUB should not offer a devicetree 
command if it

does not know what fix-ups are needed?


Quite the opposite.

It is partly *because* grub (which is part of the OS, not part 
of the
system firmware) is entitled to make changes that the system 
firmware

must leave the DTB alone.


Isn't it more accurate to say that grub is part of Linux distros 
targeting

servers and desktops.
In embedded, I am not sure grub is in the picture all the time.


Sure grub isn't a mandatory but on systems which include it then 
it is

part of the OS.


In your view, what is the role of grub in the DT lifecycle? I see 
it as the

"authoritative entity" to deal with chosen node (bootargs, cma) and
speical reverved-memory for kexec...


Er... I mostly use it to workaround broken system firmware ;-) and 
for

development and testing.

However from an EBBR point of view there is no reason to care 
about the

role of grub in the DT lifecycle because it is not in scope. Once we
have handed over to next component (whether it is grub, the 
efistub, a

bsd loader or any other OS component) then we no longer get a say in
what happens to the DT.


To get back to something concrete in the EBBR text, how about the
addition of the following text to the Devicetree section?

---
Firmware must have the DTB resident in memory and listed in the EFI
system table before executing any UEFI applications. Firmware must not
modify the resident DTB while a UEFI application is executing, 
including

during calls to boot services or runtime services.

UEFI applications are permitted to modify or replace the loaded DTB.
Firmware must ignore any changes to the DTB made by an application and
simply pass the modified or replaced DTB through to the operating
system. Firmware must not depend on the in-memory DTB for its own
operation. I.e., Once execution of a UEFI application begins, firmware
must treat the resident DTB as an anonymous blob and not depend on any
data in the DTB.
---

I think that covers the use cases of UEFI applications making 
changes to

the DTB (for any number of valid reasons); but spells out that the
firmware is not to make use of or change the DTB once application
execution begins.



This still suggests that the system firmware is involved at all in
passing the DTB once it has handed off to any UEFI application
including the OS loader, but it shouldn't be.

The system firmware should simply
a) *produce* the DTB as a config table before calling any other
applications (or even other 3rd party drivers if they are supported -
this amounts to the meaning of EndOfDxe in PI)
b) not *consume* a DTB from the config table - even if it uses DT
internally, it should not reload the DT that a loader may have
installed.


Can you suggest how I describe this in the spec?



Perhaps something along the lines of:

"""
If a DTB is used to describe the platform to the OS, it must be 
installed as a EFI configuration table under the appropriate GUID by 
the system firmware before starting any UEFI applications or drivers 
that are not part of the system firmware image themselves. Once the 
DTB is ins

Re: [EBBR PATCH] Add EFI GUID for device tree blob

[Ard Biesheuvel]

On 5/12/20 7:23 PM, Grant Likely wrote:



On 12/05/2020 18:16, Ard Biesheuvel wrote:

On Tue, 12 May 2020 at 19:05, Grant Likely  wrote:




On 07/05/2020 20:15, Daniel Thompson wrote:

On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote:
On Thu, 7 May 2020 at 16:50, Daniel Thompson 


wrote:


On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote:

On 06.05.20 17:14, Ard Biesheuvel wrote:

On 5/6/20 5:01 PM, Grant Likely wrote:

On 06/05/2020 15:56, Ard Biesheuvel wrote:

On 5/6/20 4:54 PM, Grant Likely wrote:



On 06/05/2020 15:52, Ard Biesheuvel wrote:

On 5/6/20 4:38 PM, Grant Likely wrote:

Only if the door is wide open. If there is a /real need/ for a
limited set of changes to the dtb, then those specific 
cases can

be spelled out as things firmware is allowed to modify in a
replacement DTB. Any scenarios here need to be very specific.

What specific cases do we know about?



None. There is no way the firmware can currently manipulate 
the DTB
after the EFI stub has taken ownership of it. We load the 
firmware
provided one, copy it into a new allocation and make our 
changes

there. This version is the one that is passed to the OS.


Before ExitBootServices()?



Yes.


Right, so the kernel stub is completely out and language is 
needed for

when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???



No changes should be made to the DTB after it has been installed 
as a

config table.


Second, if an Efi application replaces the DTB, what are the known
scenarios for wanting firmware to apply fixups to the DTB 
(again; need

to be very specific)



None. The firmware should not expect to be given the opportunity to
tweak the DTB after it hands off to the next stage.


This would imply that GRUB should not offer a devicetree command 
if it

does not know what fix-ups are needed?


Quite the opposite.

It is partly *because* grub (which is part of the OS, not part of the
system firmware) is entitled to make changes that the system firmware
must leave the DTB alone.


Isn't it more accurate to say that grub is part of Linux distros 
targeting

servers and desktops.
In embedded, I am not sure grub is in the picture all the time.


Sure grub isn't a mandatory but on systems which include it then it is
part of the OS.


In your view, what is the role of grub in the DT lifecycle? I see 
it as the

"authoritative entity" to deal with chosen node (bootargs, cma) and
speical reverved-memory for kexec...


Er... I mostly use it to workaround broken system firmware ;-) and for
development and testing.

However from an EBBR point of view there is no reason to care about the
role of grub in the DT lifecycle because it is not in scope. Once we
have handed over to next component (whether it is grub, the efistub, a
bsd loader or any other OS component) then we no longer get a say in
what happens to the DT.


To get back to something concrete in the EBBR text, how about the
addition of the following text to the Devicetree section?

---
Firmware must have the DTB resident in memory and listed in the EFI
system table before executing any UEFI applications. Firmware must not
modify the resident DTB while a UEFI application is executing, including
during calls to boot services or runtime services.

UEFI applications are permitted to modify or replace the loaded DTB.
Firmware must ignore any changes to the DTB made by an application and
simply pass the modified or replaced DTB through to the operating
system. Firmware must not depend on the in-memory DTB for its own
operation. I.e., Once execution of a UEFI application begins, firmware
must treat the resident DTB as an anonymous blob and not depend on any
data in the DTB.
---

I think that covers the use cases of UEFI applications making changes to
the DTB (for any number of valid reasons); but spells out that the
firmware is not to make use of or change the DTB once application
execution begins.



This still suggests that the system firmware is involved at all in
passing the DTB once it has handed off to any UEFI application
including the OS loader, but it shouldn't be.

The system firmware should simply
a) *produce* the DTB as a config table before calling any other
applications (or even other 3rd party drivers if they are supported -
this amounts to the meaning of EndOfDxe in PI)
b) not *consume* a DTB from the config table - even if it uses DT
internally, it should not reload the DT that a loader may have
installed.


Can you suggest how I describe this in the spec?



Perhaps something along the lines of:

"""
If a DTB is used to describe the platform to the OS, it must be 
installed as a EFI configuration table under the appropriate GUID by the 
system firmware before starting any UEFI applications or drivers that 
are not part of the system firmware image themselves. Once the DTB is 
installed as a configuration table, the system firmware must not make 
any modifications to it.


UEFI a

Re: [EBBR PATCH] Add EFI GUID for device tree blob

[Ard Biesheuvel]

On Tue, 12 May 2020 at 19:05, Grant Likely  wrote:
>
>
>
> On 07/05/2020 20:15, Daniel Thompson wrote:
> > On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote:
> >> On Thu, 7 May 2020 at 16:50, Daniel Thompson 
> >> wrote:
> >>
> >>> On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote:
> >>>> On 06.05.20 17:14, Ard Biesheuvel wrote:
> >>>>> On 5/6/20 5:01 PM, Grant Likely wrote:
> >>>>>> On 06/05/2020 15:56, Ard Biesheuvel wrote:
> >>>>>>> On 5/6/20 4:54 PM, Grant Likely wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 06/05/2020 15:52, Ard Biesheuvel wrote:
> >>>>>>>>> On 5/6/20 4:38 PM, Grant Likely wrote:
> >>>>>>>>>> Only if the door is wide open. If there is a /real need/ for a
> >>>>>>>>>> limited set of changes to the dtb, then those specific cases can
> >>>>>>>>>> be spelled out as things firmware is allowed to modify in a
> >>>>>>>>>> replacement DTB. Any scenarios here need to be very specific.
> >>>>>>>>>>
> >>>>>>>>>> What specific cases do we know about?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> None. There is no way the firmware can currently manipulate the DTB
> >>>>>>>>> after the EFI stub has taken ownership of it. We load the firmware
> >>>>>>>>> provided one, copy it into a new allocation and make our changes
> >>>>>>>>> there. This version is the one that is passed to the OS.
> >>>>>>>>
> >>>>>>>> Before ExitBootServices()?
> >>>>>>>>
> >>>>>>>
> >>>>>>> Yes.
> >>>>>>
> >>>>>> Right, so the kernel stub is completely out and language is needed for
> >>>>>> when the DTB becomes 'sedimented'.
> >>>>>> - Before ExitBootServices()
> >>>>>> - After ???
> >>>>>>
> >>>>>
> >>>>> No changes should be made to the DTB after it has been installed as a
> >>>>> config table.
> >>>>>
> >>>>>> Second, if an Efi application replaces the DTB, what are the known
> >>>>>> scenarios for wanting firmware to apply fixups to the DTB (again; need
> >>>>>> to be very specific)
> >>>>>>
> >>>>>
> >>>>> None. The firmware should not expect to be given the opportunity to
> >>>>> tweak the DTB after it hands off to the next stage.
> >>>>
> >>>> This would imply that GRUB should not offer a devicetree command if it
> >>>> does not know what fix-ups are needed?
> >>>
> >>> Quite the opposite.
> >>>
> >>> It is partly *because* grub (which is part of the OS, not part of the
> >>> system firmware) is entitled to make changes that the system firmware
> >>> must leave the DTB alone.
> >>
> >> Isn't it more accurate to say that grub is part of Linux distros targeting
> >> servers and desktops.
> >> In embedded, I am not sure grub is in the picture all the time.
> >
> > Sure grub isn't a mandatory but on systems which include it then it is
> > part of the OS.
> >
> >
> >> In your view, what is the role of grub in the DT lifecycle? I see it as the
> >> "authoritative entity" to deal with chosen node (bootargs, cma) and
> >> speical reverved-memory for kexec...
> >
> > Er... I mostly use it to workaround broken system firmware ;-) and for
> > development and testing.
> >
> > However from an EBBR point of view there is no reason to care about the
> > role of grub in the DT lifecycle because it is not in scope. Once we
> > have handed over to next component (whether it is grub, the efistub, a
> > bsd loader or any other OS component) then we no longer get a say in
> > what happens to the DT.
>
> To get back to something concrete in the EBBR text, how about the
> addition of the following text to the Devicetree section?
>
> ---
> Firmware must have the DTB resident in memory and listed in the EFI
> system table before executing an

Re: [EBBR PATCH] Add EFI GUID for device tree blob

[Ard Biesheuvel]

On Wed, 6 May 2020 at 20:00, Grant Likely  wrote:
>
>
>
> On 06/05/2020 17:57, Ard Biesheuvel wrote:
> > On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt  wrote:
> >>
> >> On 06.05.20 17:14, Ard Biesheuvel wrote:
> >>> On 5/6/20 5:01 PM, Grant Likely wrote:
> > ...
> >>>> Right, so the kernel stub is completely out and language is needed for
> >>>> when the DTB becomes 'sedimented'.
> >>>> - Before ExitBootServices()
> >>>> - After ???
> >>>>
> >>>
> >>> No changes should be made to the DTB after it has been installed as a
> >>> config table.
> >>>
> >>>> Second, if an Efi application replaces the DTB, what are the known
> >>>> scenarios for wanting firmware to apply fixups to the DTB (again; need
> >>>> to be very specific)
> >>>>
> >>>
> >>> None. The firmware should not expect to be given the opportunity to
> >>> tweak the DTB after it hands off to the next stage.
> >>
> >> This would imply that GRUB should not offer a devicetree command if it
> >> does not know what fix-ups are needed?
> >>
> >
> > Grant and you keep mentioning fixups like it is common today for the
> > system firmware to go and change the DTB at random times after
> > invoking the next stage. What exactly do you have in mind here, and
> > why do you think it works correctly today?
>
> In the non-EFI boot flow, it is common for U-Boot to load the DTB, and
> then updating it in the bootm command to insert the kernel command line
> or in another command (e.g. applying overlays). The concern I've heard
> is that the EBBR boot flow won't support what is needed in the embedded
> space.
>
> I want to make sure we're not ruling out behaviour that is required
> because it hasn't been discussed in this context. I suspect the answer
> will simply be exactly what you've already described: The DTB becomes
> static before any EFI applications are executed. Any fixups after that
> point are the responsibility of the boot flow. I want to be sure that
> works for the ST, NXP, TI, etc.
>

I think this is just a terminology clash: in the embedded world, the
DT is read from a file (which may be shipped separately), and so a
'fixup' step is required to put actual runtime data into it.

In the EDK/ACPI/SBBR world, 'fixing up' the firmware tables is the
same as generating them in the first place, since the input is not
taken from a file, and not necessarily in true DT format at all:
Overdrive in edk2-platforms is a good example, it has a .dtb builtin
in with lots of pieces missing, and these are all generated and
inserted on the fly. On SynQuacer, I do something similar, but also
apply overlays depending on what is plugged into the 96boards LS
connector (in theory - only Secure96 is supported at the moment)

So we are basically talking about the same thing, and whatever the
firmware needs to at runtime to produce a correct and accurate DT
needs to be completed before it calls the next boot stage.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [EBBR PATCH] Add EFI GUID for device tree blob

[Ard Biesheuvel]

On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt  wrote:
>
> On 06.05.20 17:14, Ard Biesheuvel wrote:
> > On 5/6/20 5:01 PM, Grant Likely wrote:
...
> >> Right, so the kernel stub is completely out and language is needed for
> >> when the DTB becomes 'sedimented'.
> >> - Before ExitBootServices()
> >> - After ???
> >>
> >
> > No changes should be made to the DTB after it has been installed as a
> > config table.
> >
> >> Second, if an Efi application replaces the DTB, what are the known
> >> scenarios for wanting firmware to apply fixups to the DTB (again; need
> >> to be very specific)
> >>
> >
> > None. The firmware should not expect to be given the opportunity to
> > tweak the DTB after it hands off to the next stage.
>
> This would imply that GRUB should not offer a devicetree command if it
> does not know what fix-ups are needed?
>

Grant and you keep mentioning fixups like it is common today for the
system firmware to go and change the DTB at random times after
invoking the next stage. What exactly do you have in mind here, and
why do you think it works correctly today?

> Should GRUB command be marked as deprecated? - CC Daniel
> https://www.gnu.org/software/grub/manual/grub/grub.html#devicetree
>

I don't think so. There are valid use cases for it, and the system
firmware should not be poking around in the DTB anyway after it has
launched the next stage loader.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [EBBR PATCH] Add EFI GUID for device tree blob

[Ard Biesheuvel]

On 5/6/20 5:01 PM, Grant Likely wrote:

On 06/05/2020 15:56, Ard Biesheuvel wrote:

On 5/6/20 4:54 PM, Grant Likely wrote:



On 06/05/2020 15:52, Ard Biesheuvel wrote:

On 5/6/20 4:38 PM, Grant Likely wrote:
Only if the door is wide open. If there is a /real need/ for a 
limited set of changes to the dtb, then those specific cases can be 
spelled out as things firmware is allowed to modify in a 
replacement DTB. Any scenarios here need to be very specific.


What specific cases do we know about?



None. There is no way the firmware can currently manipulate the DTB 
after the EFI stub has taken ownership of it. We load the firmware 
provided one, copy it into a new allocation and make our changes 
there. This version is the one that is passed to the OS.


Before ExitBootServices()?



Yes.


Right, so the kernel stub is completely out and language is needed for 
when the DTB becomes 'sedimented'.

- Before ExitBootServices()
- After ???



No changes should be made to the DTB after it has been installed as a 
config table.


Second, if an Efi application replaces the DTB, what are the known 
scenarios for wanting firmware to apply fixups to the DTB (again; need 
to be very specific)




None. The firmware should not expect to be given the opportunity to 
tweak the DTB after it hands off to the next stage.

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [EBBR PATCH] Add EFI GUID for device tree blob

[Ard Biesheuvel]

On 5/6/20 4:54 PM, Grant Likely wrote:



On 06/05/2020 15:52, Ard Biesheuvel wrote:

On 5/6/20 4:38 PM, Grant Likely wrote:
Only if the door is wide open. If there is a /real need/ for a 
limited set of changes to the dtb, then those specific cases can be 
spelled out as things firmware is allowed to modify in a replacement 
DTB. Any scenarios here need to be very specific.


What specific cases do we know about?



None. There is no way the firmware can currently manipulate the DTB 
after the EFI stub has taken ownership of it. We load the firmware 
provided one, copy it into a new allocation and make our changes 
there. This version is the one that is passed to the OS.


Before ExitBootServices()?



Yes.

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [EBBR PATCH] Add EFI GUID for device tree blob

[Ard Biesheuvel]

On 5/6/20 4:38 PM, Grant Likely wrote:



On 06/05/2020 15:21, Ard Biesheuvel wrote:

On Wed, 6 May 2020 at 15:56, Grant Likely  wrote:




On 05/05/2020 16:57, Ard Biesheuvel wrote:
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt 
 wrote:



...


As long as device-trees loaded by an EFI application like GRUB do not
fully describe boards and miss on copying memory reservations,
boot-hartid and everything else needed for successful booting the
requirement not to fix-up device trees is not plausible to me.



This is a fair point. The point I made was about firmware relying on
changes made by the kernel's EFI stub between entry and the point
where it calls ExitBootServices().


Can we create a flow-diagram of who needs to modify what? Here's a first
attempt:

Scenario 1: Firmware provides DTB

1) Firmware loads stock DTB into EfiACPIReclaimMemory
2) Firmware updates DTB /chosen and /memory with current config
 DTB becomes immutable to firmware
3) Firmware calls EFI Application or OS Loader
4) ExitBootServices()
5) OS Consumes firmware-provided DTB

Scenario 2: EFI Application provides replacement DTB and handles fixups

1) Firmware loads stock DTB into EfiACPIReclaimMemory
2) Firmware updates DTB /chosen and /memory with current config
 DTB becomes immutable to firmware
3) Firmware calls EFI Application which provides replacement DTB
    a) Application loads replacement DTB into EfiACPIReclaimMemory
    b) Application updates replacement DTB with /chosen & /memory from
default DTB
    c) Application calls OS Loader
5) ExitBootServices()
6) OS Consumes replacement DTB

Scenario 3: EFI Application provides replacement DTB; but depends on
firmware to provide fixups

1) Firmware loads stock DTB into EfiACPIReclaimMemory
2) Firmware calls EFI Application which provides replacement DTB
    a) Application loads replacement DTB into EfiACPIReclaimMemory
    b) Application calls OS Loader
3) ExitBootServices()
    a) Firmware updates current DTB /chosen and /memory with current 
config

 DTB becomes immutable to firmware
4) OS Consumes replacement DTB



This doesn't make sense to me. EFI boot does not use /memory nodes in
the first place (or /memreserve/s), but the OS does not even install
the DTB back into the config table array. In Linux, the EFI stub just
passes its address in memory via r0, because that is what the bare
metal boot protocol stipulates.


Ah right, I forgot about that detail. Ignore the bits about /memory. My 
intent wasn't to be super-accurate at this point, but to start a chat 
about what firmware updates may need to be applied to a replacement DTB.



So whatever is in the config table array when the OS loader executes
is what it will consume. It is fine if some intermediate agent
replaces the DTB entirely, but the firmware should not expect to be
able to make any changes to it once it hands off to the next boot
stage.

This is essentially why I brought this up: the firmware should provide
the DTB. We know that in reality, people used DTBs shipped with the
OS, and this is not great but acceptable. If we allow firmware to have
a reverse dependency on the DTB, we make this dependency hell only
worse, since you may find yourself in the situation where your kernel
does not support the DT shipped with your firmware, and your firmware
does not support the DT shipped with your kernel.


Only if the door is wide open. If there is a /real need/ for a limited 
set of changes to the dtb, then those specific cases can be spelled out 
as things firmware is allowed to modify in a replacement DTB. Any 
scenarios here need to be very specific.


What specific cases do we know about?



None. There is no way the firmware can currently manipulate the DTB 
after the EFI stub has taken ownership of it. We load the firmware 
provided one, copy it into a new allocation and make our changes there. 
This version is the one that is passed to the OS.





___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [EBBR PATCH] Add EFI GUID for device tree blob

[Ard Biesheuvel]

On Wed, 6 May 2020 at 15:56, Grant Likely  wrote:
>
>
>
> On 05/05/2020 16:57, Ard Biesheuvel wrote:
> > On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt  wrote:
> >>
> > ...
> >>
> >> As long as device-trees loaded by an EFI application like GRUB do not
> >> fully describe boards and miss on copying memory reservations,
> >> boot-hartid and everything else needed for successful booting the
> >> requirement not to fix-up device trees is not plausible to me.
> >>
> >
> > This is a fair point. The point I made was about firmware relying on
> > changes made by the kernel's EFI stub between entry and the point
> > where it calls ExitBootServices().
>
> Can we create a flow-diagram of who needs to modify what? Here's a first
> attempt:
>
> Scenario 1: Firmware provides DTB
>
> 1) Firmware loads stock DTB into EfiACPIReclaimMemory
> 2) Firmware updates DTB /chosen and /memory with current config
>  DTB becomes immutable to firmware
> 3) Firmware calls EFI Application or OS Loader
> 4) ExitBootServices()
> 5) OS Consumes firmware-provided DTB
>
> Scenario 2: EFI Application provides replacement DTB and handles fixups
>
> 1) Firmware loads stock DTB into EfiACPIReclaimMemory
> 2) Firmware updates DTB /chosen and /memory with current config
>  DTB becomes immutable to firmware
> 3) Firmware calls EFI Application which provides replacement DTB
>a) Application loads replacement DTB into EfiACPIReclaimMemory
>b) Application updates replacement DTB with /chosen & /memory from
> default DTB
>c) Application calls OS Loader
> 5) ExitBootServices()
> 6) OS Consumes replacement DTB
>
> Scenario 3: EFI Application provides replacement DTB; but depends on
> firmware to provide fixups
>
> 1) Firmware loads stock DTB into EfiACPIReclaimMemory
> 2) Firmware calls EFI Application which provides replacement DTB
>a) Application loads replacement DTB into EfiACPIReclaimMemory
>b) Application calls OS Loader
> 3) ExitBootServices()
>a) Firmware updates current DTB /chosen and /memory with current config
>  DTB becomes immutable to firmware
> 4) OS Consumes replacement DTB
>

This doesn't make sense to me. EFI boot does not use /memory nodes in
the first place (or /memreserve/s), but the OS does not even install
the DTB back into the config table array. In Linux, the EFI stub just
passes its address in memory via r0, because that is what the bare
metal boot protocol stipulates.

So whatever is in the config table array when the OS loader executes
is what it will consume. It is fine if some intermediate agent
replaces the DTB entirely, but the firmware should not expect to be
able to make any changes to it once it hands off to the next boot
stage.

This is essentially why I brought this up: the firmware should provide
the DTB. We know that in reality, people used DTBs shipped with the
OS, and this is not great but acceptable. If we allow firmware to have
a reverse dependency on the DTB, we make this dependency hell only
worse, since you may find yourself in the situation where your kernel
does not support the DT shipped with your firmware, and your firmware
does not support the DT shipped with your kernel.




> These are obviously trivial descriptions, but I'd like to flush out what
> is actually required. There is going to be tension here between what OS
> vendors need, and what vertically integrated embedded users will need.
>
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [EBBR PATCH] Add EFI GUID for device tree blob

[Ard Biesheuvel]

On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt  wrote:
>
...
>
> As long as device-trees loaded by an EFI application like GRUB do not
> fully describe boards and miss on copying memory reservations,
> boot-hartid and everything else needed for successful booting the
> requirement not to fix-up device trees is not plausible to me.
>

This is a fair point. The point I made was about firmware relying on
changes made by the kernel's EFI stub between entry and the point
where it calls ExitBootServices().
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH] Update spec to address UEFI 2.8 Errata A

[Ard Biesheuvel]

On Tue, 5 May 2020 at 13:49, Grant Likely  wrote:
>
> UEFI 2.8 Errata A changed RuntimeServiceSupported value to be passed via
> an EFI_RT_PROPERTIES_TABLE instead of via a runtime variable.
>
> This is a breaking change and we should do a new EBBR release in short
> order to keep EBBR up to date with what is in UEFI. Unsure what the
> overall impact will be. U-Boot implements the variable method which will
> need to be changed to a table. It is unclear if any OSes depend heavily
> on it being implemented.
>

U-Boot has already been updated. Linux never implemented the old
method, and support for the new method will be part of the v5.7
release. No other OSes implement it at all today afaik.

> Cc: Andrei Warkentin 
> Cc: Francois Ozog 
> Cc: Ard Biesheuvel 
> Signed-off-by: Grant Likely 
> ---
>  source/chapter2-uefi.rst | 7 ---
>  source/references.rst| 6 +++---
>  2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> index fe03ae3..b622abe 100644
> --- a/source/chapter2-uefi.rst
> +++ b/source/chapter2-uefi.rst
> @@ -9,7 +9,7 @@ platforms.
>
>  UEFI Version
>  
> -This document uses version 2.8 of the UEFI specification [UEFI]_.
> +This document uses version 2.8 Errata A of the UEFI specification [UEFI]_.
>
>  UEFI Compliance
>  ===
> @@ -111,7 +111,7 @@ during both boot services and runtime services.
>  However, it isn't always practical for all EFI_RUNTIME_SERVICES functions
>  to be callable during runtime services due to hardware limitations.
>  If any EFI_RUNTIME_SERVICES functions are only available during boot services
> -then firmware shall provide the global `RuntimeServicesSupported` variable to
> +then firmware shall provide the `EFI_RT_PROPERTIES_TABLE` to
>  indicate which functions are available during runtime services.
>  Functions that are not available during runtime services shall return
>  EFI_UNSUPPORTED.
> @@ -202,7 +202,8 @@ If a platform does not implement modifying non-volatile 
> variables with
>  SetVariable() after ExitBootServices(),
>  then firmware shall return EFI_UNSUPPORTED for any call to SetVariable(),
>  and must advertise that SetVariable() isn't available during runtime services
> -via the `RuntimeServicesSupported` variable as defined in [UEFI]_ § 8.1.
> +via the `RuntimeServicesSupported` value in the `EFI_RT_PROPERTIES_TABLE`
> +as defined in [UEFI]_ § 4.6.
>  EFI applications can read `RuntimeServicesSupported` to determine if calls
>  to SetVariable() need to be performed before calling ExitBootServices().
>
> diff --git a/source/references.rst b/source/references.rst
> index d901bb1..1eb0509 100644
> --- a/source/references.rst
> +++ b/source/references.rst
> @@ -20,6 +20,6 @@
> 
> <https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirements.pdf>`_
> 8 March 2016, `Arm Limited <http://arm.com>`_
>
> -.. [UEFI] `Unified Extensable Firmware Interface Specification v2.8
> -   
> <http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf>`_,
> -   March 2019, `UEFI Forum <http://www.uefi.org>`_
> +.. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 Errata A

'extensible'

> +   
> <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_,
> +   February 2020, `UEFI Forum <http://www.uefi.org>`_
> --
> 2.20.1
>
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [EBBR PATCH] Add EFI GUID for device tree blob

[Ard Biesheuvel]

On 5/4/20 8:34 PM, Andrei Warkentin wrote:

Hi Grant,

Please also factor in requirements for how memory containing DT must be 
described in the memory map (Ard mentioned using EfiACPIReclaimMemory).


Maybe something like:

  * Devicetree loaded at boot time must be contained in memory of type
EfiACPIReclaimMemory.



Ack.

Not a strong position, but you may also want to put the foot down on 
*when* the exposed Devicetree blob must be consistent (consistent with 
some firmware setting changes). Perhaps thats at ReadyToBoot or 
ExitBootServices.


ReadyToBoot is a PI concept, not a UEFI concept. And EBS() is way too 
late. But I don't think there is any need to specify this: the firmware 
needs to make the DT available before calling the OS loader - I don't 
think we need to spell that out.


But this brings something else to mind: in the past, we had to push back 
on efforts to upstream Linux changes to install the DTB back into the 
configuration table, so that at EBS() time, the firmware would see the 
modified version. *That* is something we should rule out:


"""
Firmware must not consume device tree descriptions installed as 
configuration tables under this GUID by the OS loader or other boot 
stages that are not part of the system firmware itself

"""


I don't think the exact choice matters as long as it's 
called out, so that an OS loader can be coded to fetch the blob exactly 
once at the right time, and be guaranteed to work on any EBBR-compliant 
implementation (IIRC ACPI has the same problem, but you have the luxury 
of having to worry about that).


You might want to expand the GUID text to be something like:

The following GUID must be used to describe the flattened Devicetree 
blob (dtb) in the EFI_CONFIGURATION_TABLE structure referenced by the 
EFI System Table.


A

*From:* Grant Likely 
*Sent:* Monday, May 4, 2020 12:20 PM
*To:* boot-architecture@lists.linaro.org 

*Cc:* Grant Likely ; Andrei Warkentin 
; Francois Ozog 

*Subject:* [EBBR PATCH] Add EFI GUID for device tree blob
None of the relevent specs (EFI, DT, EBBR) specify the GUID for passing
a DTB. Add it to the EBBR document so it is documented somewhere
relevant.

Fixes: #45
Cc: Andrei Warkentin 
Cc: Francois Ozog 
Signed-off-by: Grant Likely 
---
  source/chapter2-uefi.rst | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index f6a5802..cf2f652 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -86,6 +86,16 @@ tables.
  - An Advanced Configuration and Power Interface [ACPI]_ table, or
  - a Devicetree [DTSPEC]_ system description

+A Devicetree system description MUST be provided in Flattened 
Devicetree (DTB)

+format version 17 or higher.
+The following GUID must be used in the EFT system table to identify the 
DTB.

+
+.. code-block:: c
+
+    #define EFI_DTB_GUID \
+ EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
+  0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
+
  As stated above, EBBR systems must not provide both ACPI and Devicetree
  tables at the same time.
  Systems that support both interfaces must provide a configuration
--
2.20.1

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended 
recipient, please notify the sender immediately and do not disclose the 
contents to any other person, use it for any purpose, or store or copy 
the information in any medium. Thank you.


___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [EBBR PATCH] Add EFI GUID for device tree blob

[Ard Biesheuvel]

On Tue, 5 May 2020 at 10:38, François Ozog  wrote:
>
> On Tue, 5 May 2020 at 09:16, Ard Biesheuvel  wrote:
>
> > On 5/4/20 8:34 PM, Andrei Warkentin wrote:
> > > Hi Grant,
> > >
> > > Please also factor in requirements for how memory containing DT must be
> > > described in the memory map (Ard mentioned using EfiACPIReclaimMemory).
> > >
> > > Maybe something like:
> > >
> > >   * Devicetree loaded at boot time must be contained in memory of type
> > > EfiACPIReclaimMemory.
> > >
> >
> > Ack.
> >
> > Are there any alignment requirements? I think of 64KB pages OS.
> Even though EfiACPIReclaimMemory  is not listed as having memory type
> constraints
> as  EfiACPIReclaimMemoryNVS in section 2.3, I wonder if architecture's last
> level largest
> page size alignment is of interest here.
>

We could add a general guideline to align the allocation to the lowest
power-of-2 value that exceeds the size. That way, it can be mapped (or
omitted) optimally regardless of the OS page size.

Note that these alignment constraints are mostly to avoid mismatched
attributes within the same page frame. For instance, the NVS memory
may need to be mapped uncached by the firmware internally, so it
cannot share a 64k page with another firmware provided allocation that
requires cacheable attributes.

For reclaim memory, the semantics are clearly that it is ordinary
memory, and that the contents are only of interest to the OS if it
chooses to consume them. This is why the alignment constraints do not
cover this type.



> > Not a strong position, but you may also want to put the foot down on
> > > *when* the exposed Devicetree blob must be consistent (consistent with
> > > some firmware setting changes). Perhaps thats at ReadyToBoot or
> > > ExitBootServices.
> >
> > ReadyToBoot is a PI concept, not a UEFI concept. And EBS() is way too
> > late. But I don't think there is any need to specify this: the firmware
> > needs to make the DT available before calling the OS loader - I don't
> > think we need to spell that out.
> >
> > But this brings something else to mind: in the past, we had to push back
> > on efforts to upstream Linux changes to install the DTB back into the
> > configuration table, so that at EBS() time, the firmware would see the
> > modified version. *That* is something we should rule out:
> >
> > """
> > Firmware must not consume device tree descriptions installed as
> > configuration tables under this GUID by the OS loader or other boot
> > stages that are not part of the system firmware itself
> > """
> >
> >
> > > I don't think the exact choice matters as long as it's
> > > called out, so that an OS loader can be coded to fetch the blob exactly
> > > once at the right time, and be guaranteed to work on any EBBR-compliant
> > > implementation (IIRC ACPI has the same problem, but you have the luxury
> > > of having to worry about that).
> > >
> > > You might want to expand the GUID text to be something like:
> > >
> > > The following GUID must be used to describe the flattened Devicetree
> > > blob (dtb) in the EFI_CONFIGURATION_TABLE structure referenced by the
> > > EFI System Table.
> > >
> > > A
> > > 
> > > *From:* Grant Likely 
> > > *Sent:* Monday, May 4, 2020 12:20 PM
> > > *To:* boot-architecture@lists.linaro.org
> > > 
> > > *Cc:* Grant Likely ; Andrei Warkentin
> > > ; Francois Ozog 
> > > *Subject:* [EBBR PATCH] Add EFI GUID for device tree blob
> > > None of the relevent specs (EFI, DT, EBBR) specify the GUID for passing
> > > a DTB. Add it to the EBBR document so it is documented somewhere
> > > relevant.
> > >
> > > Fixes: #45
> > > Cc: Andrei Warkentin 
> > > Cc: Francois Ozog 
> > > Signed-off-by: Grant Likely 
> > > ---
> > >   source/chapter2-uefi.rst | 10 ++
> > >   1 file changed, 10 insertions(+)
> > >
> > > diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> > > index f6a5802..cf2f652 100644
> > > --- a/source/chapter2-uefi.rst
> > > +++ b/source/chapter2-uefi.rst
> > > @@ -86,6 +86,16 @@ tables.
> > >   - An Advanced Configuration and Power Interface [ACPI]_ table, or
> > >   - a Devicetree [DTSPEC]_ system description
> > >
> > > +A Devicetree system description MUST be provided in Flattened
> &g

Re: [PATCH] Fix all UEFI references to be the same version

[Ard Biesheuvel]

On Mon, 4 May 2020 at 19:43, Grant Likely  wrote:
>
> Reference UEFI v2.8 throughout. v2.8 is the first version that defines
> the RuntimeServicesSupported variable.
>
> Fixes: #40
> Signed-off-by: Grant Likely 

This should refer to UEFI 2.8 errata A directly, which is the release
that replaces the RuntimeServicesSupported variable with a
configuration table.
And that probably means this chapter needs an update as well.

> ---
>  source/chapter2-uefi.rst | 4 ++--
>  source/references.rst| 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> index f2e5393..341a4f1 100644
> --- a/source/chapter2-uefi.rst
> +++ b/source/chapter2-uefi.rst
> @@ -9,7 +9,7 @@ platforms.
>
>  UEFI Version
>  
> -This document uses version 2.7 of the UEFI specification [UEFI]_.
> +This document uses version 2.8 of the UEFI specification [UEFI]_.
>
>  UEFI Compliance
>  ===
> @@ -212,7 +212,7 @@ If a platform does not implement modifying non-volatile 
> variables with
>  SetVariable() after ExitBootServices(),
>  then firmware shall return EFI_UNSUPPORTED for any call to SetVariable(),
>  and must advertise that SetVariable() isn't available during runtime services
> -via the `RuntimeServicesSupported` variable as defined in UEFI version 2.8.
> +via the `RuntimeServicesSupported` variable as defined in [UEFI]_ § 8.1.
>  EFI applications can read `RuntimeServicesSupported` to determine if calls
>  to SetVariable() need to be performed before calling ExitBootServices().
>
> diff --git a/source/references.rst b/source/references.rst
> index a12c1a2..57d42e0 100644
> --- a/source/references.rst
> +++ b/source/references.rst
> @@ -20,6 +20,6 @@
> 
> `_
> 8 March 2016, `Arm Limited `_
>
> -.. [UEFI] `Unified Extensable Firmware Interface Specification v2.7A
> -   
> `_,
> -   August 2017, `UEFI Forum `_
> +.. [UEFI] `Unified Extensable Firmware Interface Specification v2.8
> +   
> `_,
> +   March 2019, `UEFI Forum `_
> --
> 2.20.1
>
> ___
> boot-architecture mailing list
> boot-architecture@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [RFC] Systemd-boot and EBBR

[Ard Biesheuvel]

On Sat, 4 Apr 2020 at 12:50, Heinrich Schuchardt  wrote:
>
> On 4/4/20 11:57 AM, François Ozog wrote:
> > Hi,
> >
> > I instrumented boot on my Ubuntu 18.04 server right after systemd startup
> > and caught an access to:
> > /sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
>
> Jeremy's patch 06f7d4a1618d ("efibc: Add EFI Bootloader Control module")
> introduced the variable though this change seems to be unrelated to the
> commit message. See efibc_set_variable() in drivers/firmware/efi/efibc.c.
>
> @Jeremy, Ard
> Why is this variable written when CONFIG_EFI_BOOTLOADER_CONTROL=y? It
> seems not be related to the description of the customizing setting.
>
> According to the UEFI spec the SetVariable() service is optional at
> run-time.
>
> I have started work on implementing variable services at run-time in
> U-Boot. See https://lists.denx.de/pipermail/u-boot/2020-March/404441.html.
>

The whole EFI bootloader control thing predates my EFI maintainership.
I did find some discussions around it, and it seems like Matt simply
merged to put an end to the discussion, rather than because he was
convinced it was a good idea.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [RFC]: Kernel lockdown & secureboot

[Ard Biesheuvel]

On Wed, 19 Jun 2019 at 18:25, Jon Masters  wrote:
>
> On 6/19/19 10:56 AM, Francois Ozog wrote:
>
> > I was tasked to come back to Linaro TSC with an answer on Linaro and
> > kernel lockdown for UEFI SecureBoot, hence the call for feed back.
> >
> > So I did some research... The kernel lockdown does not seem to be a full
> > consensus yet:
> > https://news.ycombinator.com/item?id=16761827
>
> I also did some research. There is nobody currently working on lockdown
> patches for Arm. As in the upstream lockdown effort explicitly is not
> involving Arm at this stage. I flagged this with Arm several years ago,
> re-raised it a few months ago, and am raising it again here right now.
>
> > 1) UEFI SecureBoot: boot chain trust
> > My understanding is that UEFI SecureBoot ensures that the booted UEFI
> > payload is trusted.
> > Should the UEFI payload (a Linux OS) not be that secure it is irrelevant
> > to the UEFI SecureBoot itself.
>
> Sure. But the signed shim loader isn't going to boot a kernel unless it
> also is trusted. If it boots an untrustable kernel, then the keys are
> likely to be revoked (as you later mentioned). A Linux distro actually
> did this and are (from my understanding) going to have consequences for
> not listening or implementing this correctly. No, it is not safe to even
> think about booting an untrustable kernel with the signed boot flow.
>
> Now sure, you can have your own platform keys, but then you're going to
> need to do all of the signing yourself, and not work out of the box.
>

We need some middle ground here - see below.

...

> > UEFI SecureBoot does not mandate Microsoft signed keys.
> > But if you use Microsoft keys, I was warned that Microsoft may revoke
> > certificates for non locked down systems.
> > This warning illustrate the absolute need for independence related to
> > UEFI SecureBoot: I can't imagine a system in Europe (particularly in
> > military) prevented to boot because Microsoft revoked a certificate!!!
>
> I know you don't mean anything against Microsoft here, but just in case
> others get the wrong angle. We actually pushed Arm to go and setup a
> neutral certificate authority for exactly this reason. Years ago. But
> nobody has done it. So we are *grateful* that Microsoft are willing to
> do so. Since they are the only ones will to do it, we'll play by their
> rules, which means (rightly) not allowing Linux to be used as a malware
> trojan - the signed path needs to be done right, meaning that we need
> real lockdown patches implemented properly to do it right at all.
>

So why again does there need to only a single signing authority? If I
run RHEL on my servers, I only care about the RedHat signing key, and
perhaps the signing key of the vendor of the NIC if it is a plugin
type.

i know it is inconvenient, but it is also a *lot* more secure, so if
we takes all this stuff as seriously as we say we do, let's implement
it properly and use UEFI secure boot the way it was intended.

By the same reasoning, one of the things on my todo list is to make
GRUB work without shim. E.g., if the RHEL installer spots the RedHat
certificate in db, why on earth should it bother to install shim in
the first place?

As usual, the things that are driven mostly from the distro side are
way too much geared towards making things work exactly like on x86,
even if it makes no sense whatsoever to do so.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Wed, 5 Jun 2019 at 21:28, Tom Rini  wrote:
>
> On Wed, Jun 05, 2019 at 08:30:12PM +0200, Ard Biesheuvel wrote:
> > On Wed, 5 Jun 2019 at 19:30, Tom Rini  wrote:
> > >
> > > On Wed, Jun 05, 2019 at 06:14:08PM +0100, Mark Brown wrote:
> > > > On Wed, Jun 05, 2019 at 02:16:11PM +0200, Ard Biesheuvel wrote:
> > > >
> > > > > The idea of EBBR is to move away from a vertically integrated model,
> > > > > and permit systems or appliances to use packaged OSes in the field,
> > > > > similar to how this is being done on servers today. The idea that it
> > > > > is required for, say, company X shipping product Yrev0, to upstream a
> > > > > new rev of the DT in order to tweak their board and ship product Yrev1
> > > > > is simply ridiculous. It doesn't scale, and we shouldn't care - the DT
> > > > > bindings is what we care about, and if it adheres to those, the
> > > > > platform can provide any DT it wants, and there is no reason the
> > > > > kernel devs should ever need to look at it.
> > > >
> > > > I don't think anyone is particularly suggesting that (at least not in
> > > > the portions of the thread I read properly, I have to confess I was
> > > > skimming a bunch of it)?
> > >
> > > Just so we're all on the same page, we do understand that someone
> > > somewhere is providing Yrev0.dtb and Yrev1.dtb, yes?  Or are we
> > > expecting someone to be run-time fixing up Yboard.dtb for rev0 vs rev1
> > > vs .. ?
> >
> > Let me put it like this: company X is not interested in having to
> > engage with the distros to get Yrev1.dtb into the OS, nor do they want
> > to be forced to start from an official DTB and apply deltas to make it
> > correct. You ship a board with some description of the board that the
> > OS can understand - this is how the OS identifies which hardware it
> > runs on: the DT description.
>
> Where does this description that's coming with the board come from?
> That _matters_ if you want to have any idea what will be able to use it.
>

From the platform, not from the OS. How the firmware achieves that is
left unspecified by EBBR, it only mandates that it is passed to the OS
via a config table.

> > > > > For development, things are obviously different, I understand that.
> > > > > Shipping DTs for devboards makes sense, especially while the DT
> > > > > bindings are not set in stone yet. But imposing this model for
> > > > > production is unsustainable.
> > > >
> > > > I don't think I've particularly seen anyone trying to do that for
> > > > anything other than devboards, like Tom says people with actual products
> > > > usually don't even consider it.  It's more that there is this devboard
> > > > case where the DTs are currently in kernel and a lot of the people
> > > > hacking on things are using devboards if only for want of anything else
> > > > so they naturally end up caring about that case.
> > >
> > > Keep in mind that the in-kernel dev board ones _are_ important as that's
> > > what you start your custom platform from, 9 times out of 10.  It's quite
> > > often the case of "OK, $vendor gave us schematics for EVB, lets cut what
> > > we don't need and tweak" with a matching set of cuts and tweaks to the
> > > dts for the EVB.  In the case of carrier+SOM it's just adding to, if
> > > using the stock carrier, or again adapting things for the custom
> > > carrier.
> >
> > Of course. But how is this relevant? I am not saying DTs have to be
> > truly original works, just that the OS should not be the one providing
> > it.
>
> Because we've been talking about where the device tree comes from, and I
> keep trying to point out that we are no where near a proven record of
> "DTB is always valid and functional with the Linux Kernel from here
> on out".  There's not the tooling nor review to enforce that and there's
> a few examples every year (of just in-tree device trees, not custom end
> products) where it gets broken.
>

So now, you are saying companies should only ship products with
devices trees that have been reviewed by the kernel community?

This makes no sense to me whatsoever: the DT *bindings* are the
contract that we have with the platforms. If someone ships a DT that
adheres to the bindings, we are on the hook to fix it. If someone
ships a broken DT, it is their problem and they are fix it in their OS
fork, or they issue a firmware update that fixes it.

> > > Bu

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Wed, 5 Jun 2019 at 19:30, Tom Rini  wrote:
>
> On Wed, Jun 05, 2019 at 06:14:08PM +0100, Mark Brown wrote:
> > On Wed, Jun 05, 2019 at 02:16:11PM +0200, Ard Biesheuvel wrote:
> >
> > > The idea of EBBR is to move away from a vertically integrated model,
> > > and permit systems or appliances to use packaged OSes in the field,
> > > similar to how this is being done on servers today. The idea that it
> > > is required for, say, company X shipping product Yrev0, to upstream a
> > > new rev of the DT in order to tweak their board and ship product Yrev1
> > > is simply ridiculous. It doesn't scale, and we shouldn't care - the DT
> > > bindings is what we care about, and if it adheres to those, the
> > > platform can provide any DT it wants, and there is no reason the
> > > kernel devs should ever need to look at it.
> >
> > I don't think anyone is particularly suggesting that (at least not in
> > the portions of the thread I read properly, I have to confess I was
> > skimming a bunch of it)?
>
> Just so we're all on the same page, we do understand that someone
> somewhere is providing Yrev0.dtb and Yrev1.dtb, yes?  Or are we
> expecting someone to be run-time fixing up Yboard.dtb for rev0 vs rev1
> vs .. ?
>

Let me put it like this: company X is not interested in having to
engage with the distros to get Yrev1.dtb into the OS, nor do they want
to be forced to start from an official DTB and apply deltas to make it
correct. You ship a board with some description of the board that the
OS can understand - this is how the OS identifies which hardware it
runs on: the DT description.

> > > For development, things are obviously different, I understand that.
> > > Shipping DTs for devboards makes sense, especially while the DT
> > > bindings are not set in stone yet. But imposing this model for
> > > production is unsustainable.
> >
> > I don't think I've particularly seen anyone trying to do that for
> > anything other than devboards, like Tom says people with actual products
> > usually don't even consider it.  It's more that there is this devboard
> > case where the DTs are currently in kernel and a lot of the people
> > hacking on things are using devboards if only for want of anything else
> > so they naturally end up caring about that case.
>
> Keep in mind that the in-kernel dev board ones _are_ important as that's
> what you start your custom platform from, 9 times out of 10.  It's quite
> often the case of "OK, $vendor gave us schematics for EVB, lets cut what
> we don't need and tweak" with a matching set of cuts and tweaks to the
> dts for the EVB.  In the case of carrier+SOM it's just adding to, if
> using the stock carrier, or again adapting things for the custom
> carrier.
>

Of course. But how is this relevant? I am not saying DTs have to be
truly original works, just that the OS should not be the one providing
it.

> But maybe it's just me that's confused about what "shipping" means in
> this context.  Almost no one bothers "shipping" the DTS files for a
> custom product to mainline Linux as no one is supposed to be running
> anything other than the provided software on the custom device and so it
> goes where ever it goes for that products needs and support plans.
> Rarely does a board, devboard or finished end-user product, ship with a
> DTB file stored stand-alone in a flash chip, that is intended as the
> final forever DTB.  It's just another part of
> firmware-by-which-I-mean-the-whole-software-stack.
>

Who said anything about the DT being stored in a flash chip? I already
explained more than once that it is up to the firmware to decide *how*
it stores the DT, and the filesystem is fine if it does not care about
security or if it implements some form of authentication.

The point is that we are trying to move from this custom device model
to a model where you can run a generic distro, without having to put
the burden on the OS vendor to bundle a DT for every platform that it
will ever run on, which is especially tricky if those platforms do not
exist yet.

> Which is why my whole point here has been that the DTB needs to be
> treated and signature checked just like any other part of what's being
> loaded (kernel, initrd, grub and grub.conf OR systemd-boot and
> systemd-boot.conf, etc, etc).
>

Again, I am not arguing that the DT should be linked into the firmware
executable, I am only saying that UEFI secure boot is not appropriate
for authenticating it (and that the OS should not be providing it)
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Wed, 5 Jun 2019 at 14:59, Tom Rini  wrote:
>
> On Wed, Jun 05, 2019 at 09:17:04AM +0100, Graeme Gregory wrote:
> > On Wed, 5 Jun 2019 at 07:36, Ard Biesheuvel 
> > wrote:
> >
> > > On Wed, 5 Jun 2019 at 00:41, Tom Rini  wrote:
> > > >
> > > ...
> > >
> > > > It depends on what you mean by "OS provided".  The DTS files come from
> > > > the Linux Kernel sources, full stop.
> > >
> > > That is the mistake we should try to fix.
> > >
> > > We have DT bindings, which define the contract between the OS on one
> > > side, and the platform on the other side. This means it is the
> > > platform's job to present a DT description that adheres to those
> > > [stable] bindings.
> > >
> > > Today's development model of developing DT bindings in lockstep with
> > > the drivers, and then bundling DT files with the OS is completely
> > > unsustainable, since it doesn't scale, and it demonstrably results in
> > > DT bindings that get modified without any regard for devices that are
> > > already in the field (MacchiatoBin is a good example).
> > >
> > > So it doesn't really matter where the kernel *sources* come from, as
> > > long as the platform provides its own DT, which does not change just
> > > because the kernel changes.
> > >
> > > It is already defined how the platform provides this DT on a UEFI
> > > system, i.e., via a configuration table with a known GUID. How the
> > > firmware popiulates this memory is an implementation detail: if it
> > > wants to load it from a signed file in the file system, that is fine,
> > > as long as it is not the OS providing this file to the firmware.
> > >
> > >
> > I agree, people seem to be conflating where DT is stored in source control
> > over where it should be supplied to OS.
> >
> > Just because the DT is in linux kernel git does not mean you can't build it
> > into the u-boot for your board.
> >
> > In fact I bet u-boot maintainer would love patches for updates ;-)
>
> Right.  But there's also confusion about where the DTB is to be found.
> Whereas ACPI is "burned in" the DTB (generally) is not and will not be.
> It will be loaded from storage, so in the context of this overall
> thread, figuring out how to verify the signature on the DTB is a main
> use case.
>

There is no confusion at all.  On a UEFI/EBBR system, the DT shall be
provided to the OS via a config table using the established GUID. How
the firmware achieves that is left unspecified. The fact that it may
be loaded from storage does not make it part of the packaged OS, it is
still a component of the platform.

But based on this discussion, I will argue going forward that
- the firmware must not rely on the OS to put DT images under known
names into known locations in the file system,
- the firmware provides this DT regardless of which keys are loaded
into the uefi secure boot keyring, IOW, if i choose to put only the
RedHat certificate in db because that is all i care about, I don't
want to end up with a bricked system because the DT was loaded via the
secure boot stack and was signed with the Microsoft keyring.

Btw, the fact that Authenticode/PE-COFF does not permit multiple
signatures does not make things any easier.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Wed, 5 Jun 2019 at 13:14, Mark Brown  wrote:
>
> On Wed, Jun 05, 2019 at 11:18:44AM +0100, Steve McIntyre wrote:
>
> > Nod. We're *way* past the time where this should have stopped. How on
> > earth do we get to common DT useful for all bootloaders, OSes (etc.)
> > if people still consider the bundled, changing sources in the Linux
> > tree to be canonical?
>
> It's a chicken and egg situation - for the platforms where nobody is
> actually shipping systems with a separate device tree it's easy for
> people to miss accidental incompatibilities without noticing, or decide
> that deliberate incompatibilites won't be noticed.  If there's users
> making noise that's a lot harder to do.  Pushing on EBBR is going to
> help there, and it'd really help if there were more hardware built with
> separate boot storage :/
>
> Some of the platforms *are* doing a good job of not needlessly churning
> their device trees (they're just not very noticable since things just
> work and they make no noise), and even without people worrying about
> separately distributed DTs widely adopted in tree bindings are doing a
> lot for stability due to the number of places that would need updates
> for incompatibilites (and also avoiding the DMI quirk tables ACPI relies
> on which is nice).

I am not disagreeing with any of this. But it is helpful to keep in
mind that, in the context what we are trying to achieve, the
requirement/expectation that a DT lives on git.kernel.org and gets
packaged and shipped by the distro makes no sense at all.

The idea of EBBR is to move away from a vertically integrated model,
and permit systems or appliances to use packaged OSes in the field,
similar to how this is being done on servers today. The idea that it
is required for, say, company X shipping product Yrev0, to upstream a
new rev of the DT in order to tweak their board and ship product Yrev1
is simply ridiculous. It doesn't scale, and we shouldn't care - the DT
bindings is what we care about, and if it adheres to those, the
platform can provide any DT it wants, and there is no reason the
kernel devs should ever need to look at it.

For development, things are obviously different, I understand that.
Shipping DTs for devboards makes sense, especially while the DT
bindings are not set in stone yet. But imposing this model for
production is unsustainable.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Wed, 5 Jun 2019 at 00:41, Tom Rini  wrote:
>
...

> It depends on what you mean by "OS provided".  The DTS files come from
> the Linux Kernel sources, full stop.

That is the mistake we should try to fix.

We have DT bindings, which define the contract between the OS on one
side, and the platform on the other side. This means it is the
platform's job to present a DT description that adheres to those
[stable] bindings.

Today's development model of developing DT bindings in lockstep with
the drivers, and then bundling DT files with the OS is completely
unsustainable, since it doesn't scale, and it demonstrably results in
DT bindings that get modified without any regard for devices that are
already in the field (MacchiatoBin is a good example).

So it doesn't really matter where the kernel *sources* come from, as
long as the platform provides its own DT, which does not change just
because the kernel changes.

It is already defined how the platform provides this DT on a UEFI
system, i.e., via a configuration table with a known GUID. How the
firmware popiulates this memory is an implementation detail: if it
wants to load it from a signed file in the file system, that is fine,
as long as it is not the OS providing this file to the firmware.

>  That doesn't mean they're embedded
> within the kernel image.  They're usually going to be pulled from the
> filesystem.
>
> --
> Tom
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Wed, 5 Jun 2019 at 00:34, Tom Rini  wrote:
>
> On Tue, Jun 04, 2019 at 06:14:16PM -0400, Francois Ozog wrote:
> > Le mar. 4 juin 2019 à 17:31, Tom Rini  a écrit :
> >
...
> > I think it may be good to validate but not provide. There is no Linux
> > provided ACPI table right ? So I get the point to validate a DT.
>
> There's "Linux provided" ACPI tables when someone has to decompile,
> fixup and re-compile their DSDT files.
>
> Or perhaps a better way to think of it is that yes, there's "Linux
> provided ACPI tables" when vendors are developing their hardware and
> correcting their ACPI tables.  Same thing with DT, by and large (as
> overlays and secure boot are a can of worms to worry about later).

Secure boot enabled Linux does not permit this model. Side loading of
DSDTs/SSDTs is disabled by the hardening patchset that all the distros
carry for secure boot enabled kernels.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Tue, 4 Jun 2019 at 18:38, Francois Ozog  wrote:

>
>
> On Tue, 4 Jun 2019 at 10:57, Ard Biesheuvel 
> wrote:
>
>>
>> Yes, that makes sense. But the problem is that UEFI secure boot does not
>> support this model. An image is considered valid if it authenticates
>> against any of the keys in db. And any key in KEK can sign updates to db
>> and dbx. And today's current practice is to include Microsoft keys in both
>> KEK and db.
>>
>> Only shim.efi is Microsoft signed. So we shold be clear to sign
> SecureBoot without Shim, booting directly grub.efi for instance.
>
>

Unfortunately, the way things work today, secureboot-enabled GRUB can only
run in combination with shim, since it explicitly attaches to a protocol
exposed by shim. So even on a system where the installer can see that the
required certificates (i.e., redhat's signing certificate) are present in
the firmware's keyring, it still needs to install shim in order to be able
to run GRUB.

This is on my list of things to get fixed, and I have already discussed a
possible solution with Peter Jones (RH) but neither of us currently have
the bandwidth to sit down and do the work.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Tue, 4 Jun 2019 at 16:52, Francois Ozog  wrote:

>
>
> On Tue, 4 Jun 2019 at 10:37, Ard Biesheuvel 
> wrote:
>
>> On Tue, 4 Jun 2019 at 16:29, Heinrich Schuchardt 
>> wrote:
>> >
>> >
>> >
>> > On 6/4/19 4:20 PM, Ard Biesheuvel wrote:
>> > > On Tue, 4 Jun 2019 at 16:17, Heinrich Schuchardt 
>> wrote:
>> > >>
>> > >>
>> > >>
>> > >> On 6/4/19 3:55 PM, Francois Ozog wrote:
>> > >>> On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel <
>> ard.biesheu...@linaro.org>
>> > >>> wrote:
>> > >>>
>> > >>>>
>> > >>>>
>> > >>>> On Tue, 4 Jun 2019 at 15:44, Francois Ozog <
>> francois.o...@linaro.org>
>> > >>>> wrote:
>> > >>>>
>> > >>>>> Hi Ard,
>> > >>>>>
>> > >>>>> On Fri, 31 May 2019 at 13:35, Ard Biesheuvel <
>> ard.biesheu...@linaro.org>
>> > >>>>> wrote:
>> > >>>>>
>> > >>>>>> On Fri, 31 May 2019 at 19:25, Ilias Apalodimas
>> > >>>>>>  wrote:
>> > >>>>>>>
>> > >>>>>>> Hi Grant,
>> > >>>>>>>> I see two ways to handle this that fits with the Secure Boot
>> > >>>>>>>> authentication path:
>> > >>>>>>>>
>> > >>>>>>>> Option 1: Leave it to the OS loader
>> > >>>>>>>> We could simply say that if the OS wants to replace the DTB,
>> then it
>> > >>>>>>>> should take care of authentication itself within the OS loader
>> > >>>>>> (possibly
>> > >>>>>>>> the in-kernel UEFI stub) and install a replacement DTB in the
>> > >>>>>>>> configuration table before calling exit boot services. In this
>> > >>>>>> scenario,
>> > >>>>>>>> U-Boot doesn't authenticate the DTB at all.
>> > >>>>>>>>
>> > >>>>>>>> In fact, Option 1 is pretty close to what is required for the
>> initrd.
>> > >>>>>>>>
>> > >>>>>>>> I wonder if it is possible to wrap the DTB with a PE/COFF so
>> that
>> > >>>>>> the os
>> > >>>>>>>> loader can use load_image to authenticate and retrieve the data
>> > >>>>>> without
>> > >>>>>>>> actually executing the image. That would allow for the DTB &
>> initrd
>> > >>>>>> to
>> > >>>>>>>> be authenticated in the same way as the kernel.
>> > >>>>>>> I asked around on this prior to the email, but i think it boils
>> down to
>> > >>>>>>> "UEFI is intended to authenticate bootable images for the
>> platform",
>> > >>>>>> so i doubt
>> > >>>>>>> this will be allowed.
>> > >>>>>>>
>> > >>>>>>
>> > >>>>>> The point I raised when we discussed this is that UEFI is an
>> interface
>> > >>>>>> between the firmware and the OS, and it is up to the firmware to
>> > >>>>>> *provide* the DT not the other way around.
>> > >>>>>>
>> > >>>>>> Whether the firmware reuses some of the existing machinery if it
>> > >>>>>> chooses to load the DT it provides from an arbitrary file on the
>> file
>> > >>>>>> system is an implementation detail, and shouldn't be part of how
>> we
>> > >>>>>> design the interface. The more we standardize this and the more
>> we
>> > >>>>>> make it similar to how the OS loader is authenticated, the more
>> likely
>> > >>>>>> it becomes that it will be relied upon for DTs that are bundled
>> with
>> > >>>>>> the OS, which is a practice we are trying very hard to move away
>> from.
>> > >>>>>>
>> > >>>>>
>> > >>>>> I have the impression that OS provided DT is a bad solution to a
&g

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Tue, 4 Jun 2019 at 16:29, Heinrich Schuchardt  wrote:
>
>
>
> On 6/4/19 4:20 PM, Ard Biesheuvel wrote:
> > On Tue, 4 Jun 2019 at 16:17, Heinrich Schuchardt  wrote:
> >>
> >>
> >>
> >> On 6/4/19 3:55 PM, Francois Ozog wrote:
> >>> On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel 
> >>> wrote:
> >>>
> >>>>
> >>>>
> >>>> On Tue, 4 Jun 2019 at 15:44, Francois Ozog 
> >>>> wrote:
> >>>>
> >>>>> Hi Ard,
> >>>>>
> >>>>> On Fri, 31 May 2019 at 13:35, Ard Biesheuvel 
> >>>>> wrote:
> >>>>>
> >>>>>> On Fri, 31 May 2019 at 19:25, Ilias Apalodimas
> >>>>>>  wrote:
> >>>>>>>
> >>>>>>> Hi Grant,
> >>>>>>>> I see two ways to handle this that fits with the Secure Boot
> >>>>>>>> authentication path:
> >>>>>>>>
> >>>>>>>> Option 1: Leave it to the OS loader
> >>>>>>>> We could simply say that if the OS wants to replace the DTB, then it
> >>>>>>>> should take care of authentication itself within the OS loader
> >>>>>> (possibly
> >>>>>>>> the in-kernel UEFI stub) and install a replacement DTB in the
> >>>>>>>> configuration table before calling exit boot services. In this
> >>>>>> scenario,
> >>>>>>>> U-Boot doesn't authenticate the DTB at all.
> >>>>>>>>
> >>>>>>>> In fact, Option 1 is pretty close to what is required for the initrd.
> >>>>>>>>
> >>>>>>>> I wonder if it is possible to wrap the DTB with a PE/COFF so that
> >>>>>> the os
> >>>>>>>> loader can use load_image to authenticate and retrieve the data
> >>>>>> without
> >>>>>>>> actually executing the image. That would allow for the DTB & initrd
> >>>>>> to
> >>>>>>>> be authenticated in the same way as the kernel.
> >>>>>>> I asked around on this prior to the email, but i think it boils down 
> >>>>>>> to
> >>>>>>> "UEFI is intended to authenticate bootable images for the platform",
> >>>>>> so i doubt
> >>>>>>> this will be allowed.
> >>>>>>>
> >>>>>>
> >>>>>> The point I raised when we discussed this is that UEFI is an interface
> >>>>>> between the firmware and the OS, and it is up to the firmware to
> >>>>>> *provide* the DT not the other way around.
> >>>>>>
> >>>>>> Whether the firmware reuses some of the existing machinery if it
> >>>>>> chooses to load the DT it provides from an arbitrary file on the file
> >>>>>> system is an implementation detail, and shouldn't be part of how we
> >>>>>> design the interface. The more we standardize this and the more we
> >>>>>> make it similar to how the OS loader is authenticated, the more likely
> >>>>>> it becomes that it will be relied upon for DTs that are bundled with
> >>>>>> the OS, which is a practice we are trying very hard to move away from.
> >>>>>>
> >>>>>
> >>>>> I have the impression that OS provided DT is a bad solution to a real
> >>>>> problem:
> >>>>> There should be a Firmware hardware environment (what to initialize,
> >>>>> use...) and a OS hardware environment.
> >>>>> Both should be signed, and controlled by the firmware.
> >>>>> So I would try to find a way to supply firmware with two DTs, or more
> >>>>> likely one DT and one OS overlay (if overlays can remove some hardware).
> >>>>>
> >>>>>
> >>>>
> >>>> If the OS provides a DT to itself, what is the point of pretending that 
> >>>> it
> >>>> has been authenticated to the firmware?
> >>>>
> >>> Agreed, that is stupid! I mispresented my idea: I talk about two DTs
> >>> controlled by hardware/Firmware provider. OS shall be a consumer only.
> >>>
> >>>
>

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Tue, 4 Jun 2019 at 16:17, Heinrich Schuchardt  wrote:
>
>
>
> On 6/4/19 3:55 PM, Francois Ozog wrote:
> > On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel 
> > wrote:
> >
> >>
> >>
> >> On Tue, 4 Jun 2019 at 15:44, Francois Ozog 
> >> wrote:
> >>
> >>> Hi Ard,
> >>>
> >>> On Fri, 31 May 2019 at 13:35, Ard Biesheuvel 
> >>> wrote:
> >>>
> >>>> On Fri, 31 May 2019 at 19:25, Ilias Apalodimas
> >>>>  wrote:
> >>>>>
> >>>>> Hi Grant,
> >>>>>> I see two ways to handle this that fits with the Secure Boot
> >>>>>> authentication path:
> >>>>>>
> >>>>>> Option 1: Leave it to the OS loader
> >>>>>> We could simply say that if the OS wants to replace the DTB, then it
> >>>>>> should take care of authentication itself within the OS loader
> >>>> (possibly
> >>>>>> the in-kernel UEFI stub) and install a replacement DTB in the
> >>>>>> configuration table before calling exit boot services. In this
> >>>> scenario,
> >>>>>> U-Boot doesn't authenticate the DTB at all.
> >>>>>>
> >>>>>> In fact, Option 1 is pretty close to what is required for the initrd.
> >>>>>>
> >>>>>> I wonder if it is possible to wrap the DTB with a PE/COFF so that
> >>>> the os
> >>>>>> loader can use load_image to authenticate and retrieve the data
> >>>> without
> >>>>>> actually executing the image. That would allow for the DTB & initrd
> >>>> to
> >>>>>> be authenticated in the same way as the kernel.
> >>>>> I asked around on this prior to the email, but i think it boils down to
> >>>>> "UEFI is intended to authenticate bootable images for the platform",
> >>>> so i doubt
> >>>>> this will be allowed.
> >>>>>
> >>>>
> >>>> The point I raised when we discussed this is that UEFI is an interface
> >>>> between the firmware and the OS, and it is up to the firmware to
> >>>> *provide* the DT not the other way around.
> >>>>
> >>>> Whether the firmware reuses some of the existing machinery if it
> >>>> chooses to load the DT it provides from an arbitrary file on the file
> >>>> system is an implementation detail, and shouldn't be part of how we
> >>>> design the interface. The more we standardize this and the more we
> >>>> make it similar to how the OS loader is authenticated, the more likely
> >>>> it becomes that it will be relied upon for DTs that are bundled with
> >>>> the OS, which is a practice we are trying very hard to move away from.
> >>>>
> >>>
> >>> I have the impression that OS provided DT is a bad solution to a real
> >>> problem:
> >>> There should be a Firmware hardware environment (what to initialize,
> >>> use...) and a OS hardware environment.
> >>> Both should be signed, and controlled by the firmware.
> >>> So I would try to find a way to supply firmware with two DTs, or more
> >>> likely one DT and one OS overlay (if overlays can remove some hardware).
> >>>
> >>>
> >>
> >> If the OS provides a DT to itself, what is the point of pretending that it
> >> has been authenticated to the firmware?
> >>
> > Agreed, that is stupid! I mispresented my idea: I talk about two DTs
> > controlled by hardware/Firmware provider. OS shall be a consumer only.
> >
> >
>
> In a perfect world firmware would provide the authoritative source of
> the device tree. The current situation has device trees developed in the
> context of Linux and U-Boot picking them up. U-Boot is lagging far
> behind Linux. Whenever I wanted to change a device tree in U-Boot I was
> told to first get that change into Linux. I see no commitment to change
> this process.
>
> Device-trees are provided by U-Boot to Linux as UEFI configuration
> tables. If a device-tree is malicious it may lead to the destruction of
> hardware. So whatever U-Boot provides as a device-tree to Linux should
> be validated.
>

Of course. But that does not mean it should be the job of UEFI secure
boot to do so.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Tue, 4 Jun 2019 at 15:55, Francois Ozog  wrote:

>
>
> On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel 
> wrote:
>
>>
>>
>> On Tue, 4 Jun 2019 at 15:44, Francois Ozog 
>> wrote:
>>
>>> Hi Ard,
>>>
>>> On Fri, 31 May 2019 at 13:35, Ard Biesheuvel 
>>> wrote:
>>>
>>>> On Fri, 31 May 2019 at 19:25, Ilias Apalodimas
>>>>  wrote:
>>>> >
>>>> > Hi Grant,
>>>> > > I see two ways to handle this that fits with the Secure Boot
>>>> > > authentication path:
>>>> > >
>>>> > > Option 1: Leave it to the OS loader
>>>> > > We could simply say that if the OS wants to replace the DTB, then it
>>>> > > should take care of authentication itself within the OS loader
>>>> (possibly
>>>> > > the in-kernel UEFI stub) and install a replacement DTB in the
>>>> > > configuration table before calling exit boot services. In this
>>>> scenario,
>>>> > > U-Boot doesn't authenticate the DTB at all.
>>>> > >
>>>> > > In fact, Option 1 is pretty close to what is required for the
>>>> initrd.
>>>> > >
>>>> > > I wonder if it is possible to wrap the DTB with a PE/COFF so that
>>>> the os
>>>> > > loader can use load_image to authenticate and retrieve the data
>>>> without
>>>> > > actually executing the image. That would allow for the DTB & initrd
>>>> to
>>>> > > be authenticated in the same way as the kernel.
>>>> > I asked around on this prior to the email, but i think it boils down
>>>> to
>>>> > "UEFI is intended to authenticate bootable images for the platform",
>>>> so i doubt
>>>> > this will be allowed.
>>>> >
>>>>
>>>> The point I raised when we discussed this is that UEFI is an interface
>>>> between the firmware and the OS, and it is up to the firmware to
>>>> *provide* the DT not the other way around.
>>>>
>>>> Whether the firmware reuses some of the existing machinery if it
>>>> chooses to load the DT it provides from an arbitrary file on the file
>>>> system is an implementation detail, and shouldn't be part of how we
>>>> design the interface. The more we standardize this and the more we
>>>> make it similar to how the OS loader is authenticated, the more likely
>>>> it becomes that it will be relied upon for DTs that are bundled with
>>>> the OS, which is a practice we are trying very hard to move away from.
>>>>
>>>
>>> I have the impression that OS provided DT is a bad solution to a real
>>> problem:
>>> There should be a Firmware hardware environment (what to initialize,
>>> use...) and a OS hardware environment.
>>> Both should be signed, and controlled by the firmware.
>>> So I would try to find a way to supply firmware with two DTs, or more
>>> likely one DT and one OS overlay (if overlays can remove some hardware).
>>>
>>>
>>
>> If the OS provides a DT to itself, what is the point of pretending that
>> it has been authenticated to the firmware?
>>
> Agreed, that is stupid! I mispresented my idea: I talk about two DTs
> controlled by hardware/Firmware provider. OS shall be a consumer only.
>
>
>
But my point remains the same. If we are accommodating a model where the DT
is shipped with the OS, the OS can deal with authenticating the DTB files.
If the firmware provides the DT, it is a firmware implementation detail how
and where it keeps the DTB files internally, as long as it uses the
official way (i.e., via a UEFI config table) to expose the DT to the OS.

Rolling all of this into secure boot support (which deals with
authenticating OS components/loaders to the firmware) is something we
should avoid.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Tue, 4 Jun 2019 at 15:44, Francois Ozog  wrote:

> Hi Ard,
>
> On Fri, 31 May 2019 at 13:35, Ard Biesheuvel 
> wrote:
>
>> On Fri, 31 May 2019 at 19:25, Ilias Apalodimas
>>  wrote:
>> >
>> > Hi Grant,
>> > > I see two ways to handle this that fits with the Secure Boot
>> > > authentication path:
>> > >
>> > > Option 1: Leave it to the OS loader
>> > > We could simply say that if the OS wants to replace the DTB, then it
>> > > should take care of authentication itself within the OS loader
>> (possibly
>> > > the in-kernel UEFI stub) and install a replacement DTB in the
>> > > configuration table before calling exit boot services. In this
>> scenario,
>> > > U-Boot doesn't authenticate the DTB at all.
>> > >
>> > > In fact, Option 1 is pretty close to what is required for the initrd.
>> > >
>> > > I wonder if it is possible to wrap the DTB with a PE/COFF so that the
>> os
>> > > loader can use load_image to authenticate and retrieve the data
>> without
>> > > actually executing the image. That would allow for the DTB & initrd to
>> > > be authenticated in the same way as the kernel.
>> > I asked around on this prior to the email, but i think it boils down to
>> > "UEFI is intended to authenticate bootable images for the platform", so
>> i doubt
>> > this will be allowed.
>> >
>>
>> The point I raised when we discussed this is that UEFI is an interface
>> between the firmware and the OS, and it is up to the firmware to
>> *provide* the DT not the other way around.
>>
>> Whether the firmware reuses some of the existing machinery if it
>> chooses to load the DT it provides from an arbitrary file on the file
>> system is an implementation detail, and shouldn't be part of how we
>> design the interface. The more we standardize this and the more we
>> make it similar to how the OS loader is authenticated, the more likely
>> it becomes that it will be relied upon for DTs that are bundled with
>> the OS, which is a practice we are trying very hard to move away from.
>>
>
> I have the impression that OS provided DT is a bad solution to a real
> problem:
> There should be a Firmware hardware environment (what to initialize,
> use...) and a OS hardware environment.
> Both should be signed, and controlled by the firmware.
> So I would try to find a way to supply firmware with two DTs, or more
> likely one DT and one OS overlay (if overlays can remove some hardware).
>
>

If the OS provides a DT to itself, what is the point of pretending that it
has been authenticated to the firmware?
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Securing the boot flow in U-Boot

[Ard Biesheuvel]

On Fri, 31 May 2019 at 19:25, Ilias Apalodimas
 wrote:
>
> Hi Grant,
> > I see two ways to handle this that fits with the Secure Boot
> > authentication path:
> >
> > Option 1: Leave it to the OS loader
> > We could simply say that if the OS wants to replace the DTB, then it
> > should take care of authentication itself within the OS loader (possibly
> > the in-kernel UEFI stub) and install a replacement DTB in the
> > configuration table before calling exit boot services. In this scenario,
> > U-Boot doesn't authenticate the DTB at all.
> >
> > In fact, Option 1 is pretty close to what is required for the initrd.
> >
> > I wonder if it is possible to wrap the DTB with a PE/COFF so that the os
> > loader can use load_image to authenticate and retrieve the data without
> > actually executing the image. That would allow for the DTB & initrd to
> > be authenticated in the same way as the kernel.
> I asked around on this prior to the email, but i think it boils down to
> "UEFI is intended to authenticate bootable images for the platform", so i 
> doubt
> this will be allowed.
>

The point I raised when we discussed this is that UEFI is an interface
between the firmware and the OS, and it is up to the firmware to
*provide* the DT not the other way around.

Whether the firmware reuses some of the existing machinery if it
chooses to load the DT it provides from an arbitrary file on the file
system is an implementation detail, and shouldn't be part of how we
design the interface. The more we standardize this and the more we
make it similar to how the OS loader is authenticated, the more likely
it becomes that it will be relied upon for DTs that are bundled with
the OS, which is a practice we are trying very hard to move away from.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH v2 2/2] amr64: map FDT as RW for early_init_dt_scan()

[Ard Biesheuvel]

On Wed, 15 May 2019 at 12:24, Hsin-Yi Wang  wrote:
>
> On Tue, May 14, 2019 at 11:42 PM Mike Rapoport  wrote:
>
> > I'm not sure if early console is available at the time kaslr_early_init()
> > is called, but if yes, running with memblock=debug may shed some light.
> >
> > > I didn't trace the real reason causing this. But in this case, maybe
> > > don't call memblock_reserve() in kaslr?
> >
> > My concern that this uncovered a real bug which might hit us later.
> >
> Hi Mike,
> Thanks for the hint. I tried on my device but seems that earlycon
> happens after the warning call trace, so can't more information.
>
> Since on my device kaslr will be runned, I tried call
> memblock_reserve() in kaslr and not in
> setup_machine_fdt()#fixmap_remap_fdt, but got following warning
>

I realize this is not documented sufficiently in the commit log, but
the reason I introduced the separate __fixmap_remap_fdt() [which does
not call memblock_reserve()] was that the KASLR init code should set
as little global state as possible, given that it is called with the
kernel mapped at the wrong virtual address.

The KASLR boot sequence is something like
- map kernel at default [unrandomized] address
- apply relocations and clear BSS
- run KASLR init to map and parse the FDT [*]
- if KASLR is enabled, unmap the kernel and remap it at the randomized address
- apply relocations and clear BSS
- proceed with start_kernel()

The issue you are seeing is caused by the fact that the memblock
bookkeeping gets into an inconsistent state due to the 2nd clearing of
BSS.

[*] The reason we need to map the FDT this early is to obtain the
random seed, and to check whether 'nokaslr' was passed on the kernel
command line. The reason arm64 deviates from other architectures in
this regard is that we don't have a decompressor, and so there is no
other execution context available where we can run C code to parse the
FDT etc before we enter the kernel proper.




> [0.00] memblock_remove:
> [0x0001-0xfffe] arm64_memblock_init+0x28/0x224
> [0.00] memblock_remove:
> [0x00404000-0x00403ffe] arm64_memblock_init+0x64/0x224
> [0.00] memblock_reserve:
> [0x4008-0x413c3fff]
> arm64_memblock_init+0x188/0x224
> [0.00] WARNING: CPU: 0 PID: 0 at
> /mnt/host/source/src/third_party/kernel/v4.19/mm/memblock.c:583
> memblock_add_range+0x1bc/0x1c8
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.38 #222
> [0.00] Hardware name: MediaTek kukui rev2 board (DT)
> [0.00] pstate: 6085 (nZCv daIf -PAN -UAO)
> [0.00] pc : memblock_add_range+0x1bc/0x1c8
> [0.00] lr : memblock_add_range+0x30/0x1c8
> [0.00] sp : ffab68603ea0
> [0.00] x29: ffab68603ef0 x28: 40954324
> [0.00] x27: 4008 x26: 0008
> [0.00] x25: 80127e4b x24: ffab68716000
> [0.00] x23: ffab680b5000 x22: 01344000
> [0.00] x21: 4008 x20: 
> [0.00] x19: ffab6864bf00 x18: fc94
> [0.00] x17: 003c x16: ffab67d49064
> [0.00] x15: 0006 x14: 626d656d5f34366d
> [0.00] x13: 7261205d6633 x12: 
> [0.00] x11:  x10: 
> [0.00] x9 : 00011547 x8 : ffab68765690
> [0.00] x7 : 696e695f6b636f6c x6 : ffab6875dd41
> [0.00] x5 :  x4 : 
> [0.00] x3 : ffab678a24a0 x2 : 01344000
> [0.00] x1 : 4008 x0 : ffab6864bf00
> [0.00] Call trace:
> [0.00]  memblock_add_range+0x1bc/0x1c8
> [0.00]  memblock_reserve+0x60/0xac
> [0.00]  arm64_memblock_init+0x188/0x224
> [0.00]  setup_arch+0x138/0x19c
> [0.00]  start_kernel+0x68/0x380
> [0.00] random: get_random_bytes called from
> print_oops_end_marker+0x3c/0x58 with crng_init=0
> [0.00] ---[ end trace ea99802b425f7adf ]---
> [0.00] memblock_reserve:
> [0x5f80-0x5f811536]
> early_init_dt_reserve_memory_arch+0x38/0x48
> [0.00] memblock_reserve:
> [0xffe0-0x]
> early_init_dt_reserve_memory_arch+0x38/0x48
>
> So I guess we just can't call memblock_reserve() in kaslr?

Re: [Arm.ebbr-discuss] [PATCH 5/7] Refactor ResetSystem() requirements

[Ard Biesheuvel]

On 27 September 2018 at 13:46, Daniel Thompson
 wrote:
> On Thu, Sep 27, 2018 at 10:53:51AM +, Udit Kumar wrote:
>> > -Original Message-
>> > From: Grant Likely 
>> > Sent: Wednesday, September 26, 2018 6:01 PM
>> > To: Udit Kumar ; boot-architecture@lists.linaro.org;
>> > arm.ebbr-disc...@arm.com
>> > Cc: n...@arm.com
>> > Subject: Re: [Arm.ebbr-discuss] [PATCH 5/7] Refactor ResetSystem()
>> > requirements
>>
>> >  From patch 6:
>> > > +Functions contained in EFI_RUNTIME_SERVICES are expected to be
>> > > +available during both boot services and runtime services.
>> > > +However, it isn't always practical for all EFI_RUNTIME_SERVICES
>> > > +functions to be callable during runtime services due to hardware
>> > limitations.
>> > > +If any EFI_RUNTIME_SERVICES functions are only available during boot
>> > > +services then firmware shall provide the global
>> > > +`RuntimeServicesAvailable` variable to indicate which functions are
>> > available during runtime services.
>> > > +Functions that are not available during runtime services shall return
>> > > +EFI_UNSUPPORTED.
>> >
>> > Is that clear enough?
>>
>> Thanks,  this is clear where UEFI is saying to return an error say for 
>> RTC/Variable service.
>>
>> For reset, there is no error code, in this case, how EFI interface can tell 
>> to OS that reset
>> is not available through runtime.  We should document this.
>
> Interesting.
>
> Clearly the OS can trivially detect the ResetSystem() is not
> implemented/working because it would not otherwise return but this might
> need an update to the ECR (which otherwise has language that adds
> EFI_UNSUPPORTED as a return type to a function with no return type).
>

Instead, we could update the UEFI spec so that ResetSystem() does have
a return type, which may be useful in other way as well. (And being
able to add the language that says 'EFI_SUCCESS - An error has
occurred' is just too appealing)
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] [PATCH 2/7] Add AArch32 details

[Ard Biesheuvel]

On Mon, 24 Sep 2018 at 15:54, Grant Likely  wrote:
>
> Fill out the requirements for AArch32 systems. Not much needs to be
> specified here other than the different privilege modes defined by
> ARMv7 and below.
>
> Resolves: #15
> Signed-off-by: Grant Likely 
> ---
>  source/chapter1-about.rst   | 19 +++
>  source/chapter2-uefi.rst| 32 
>  source/chapter3-secureworld.rst | 18 ++
>  source/index.rst|  1 +
>  4 files changed, 46 insertions(+), 24 deletions(-)
>
> diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
> index d1c6d1d..4d70b2a 100644
> --- a/source/chapter1-about.rst
> +++ b/source/chapter1-about.rst
> @@ -107,9 +107,8 @@ The following guiding principles are used while 
> developing the EBBR specificatio
>  - Support multiple architectures
>
>Any architecture can implement the EBBR requirements.
> -
> -  .. note::
> - At the time of writing this document only addresses AArch64, but 
> AArch32 and others architectures are expected.
> +  Architecture specific requirements will clearly marked as to which
> +  architecture(s) they apply.
>
>  - Design for common embedded hardware
>
> @@ -139,7 +138,7 @@ The following guiding principles are used while 
> developing the EBBR specificatio
>  Scope
>  =
>  This document defines the boot and runtime services that are expected by an
> -Operating System or hypervisor, for an Arm embedded device, which follows the
> +Operating System or hypervisor, for a device which follows the
>  UEFI specification [UEFI]_.
>
>  This specification defines the boot and runtime services for a physical 
> system,
> @@ -180,6 +179,10 @@ This document uses the following terms and abbreviations.
>The 64-bit Arm instruction set used in AArch64 state.
>All A64 instructions are 32 bits.
>
> +   AArch32
> +  Arm 32-bit architectures. AArch32 is a roll up term referring to all
> +  32-bit versions of the Arm architecture starting at ARMv4.
> +
> AArch64 state
>The Arm 64-bit Execution state that uses 64-bit general purpose
>registers, and a 64-bit program counter (PC), Stack Pointer (SP), and
> @@ -193,19 +196,19 @@ This document uses the following terms and 
> abbreviations.
>and which uses boot time services.
>
> EL0
> -  The lowest Exception level. The Exception level that is used to execute
> +  The lowest Exception level on AArch64. The Exception level that is 
> used to execute
>user applications, in Non-secure state.
>
> EL1
> -  Privileged Exception level. The Exception level that is used to execute
> +  Privileged Exception level on AArch64. The Exception level that is 
> used to execute
>Operating Systems, in Non-secure state.
>
> EL2
> -  Hypervisor Exception level. The Exception level that is used to execute
> +  Hypervisor Exception level on AArch64. The Exception level that is 
> used to execute
>hypervisor code. EL2 is always in Non-secure state.
>
> EL3
> -  Secure Monitor Exception level. The Exception level that is used to
> +  Secure Monitor Exception level on AArch64. The Exception level that is 
> used to
>execute Secure Monitor code, which handles the transitions between
>Non-secure and Secure states.  EL3 is always in Secure state.
>
> diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> index f89ac04..7fd8aa6 100644
> --- a/source/chapter2-uefi.rst
> +++ b/source/chapter2-uefi.rst
> @@ -29,19 +29,27 @@ The system firmware must implement support for MBR, GPT 
> and El Torito partitioni
>  UEFI System Environment and Configuration
>  =
>
> -AArch64 Exception Levels
> -
> -
> -The resident AArch64 UEFI boot-time environment is specified to "Use the
> -highest 64-bit Non-secure privilege level available".
> -This level is either EL1 or EL2, depending on whether or not virtualization 
> is
> -used or supported.
> +The resident UEFI boot-time environment shall use the highest non-secure
> +privilege level available.
> +The exact meaning of this is architecture dependant, as detailed below.
>
> -Resident UEFI firmware might target a specific Exception level.
> +Resident UEFI firmware might target a specific priviledge level.

privilege

>  In contrast, UEFI Loaded Images, such as thirdparty drivers and boot
>  applications, must not contain any built-in assumptions that they are to be
> -loaded at a given Exception level during boot time, since they can 
> legitimately
> -be loaded into EL1 or EL2.
> +loaded at a given priviledge level during boot time since they can, for 
> example,
> +legitimately be loaded into either EL1 or EL2 on AArch64.
> +
> +AArch32 Priviledge Levels
> +-
> +
> +UEFI shall execute at either PL1 (svc) or PL2 (hyp),
> +depending on whether or not virtualization is used and supported.
> +

Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime

[Ard Biesheuvel]

On 12 July 2018 at 15:12, Mark Brown  wrote:
> On Thu, Jul 12, 2018 at 01:50:45PM +0100, Daniel Thompson wrote:
>
>> The OS will discover the variable is non-modifiable when it tried to
>> set it. Won't the current proposal mislead standards compliant use of
>> GetVariable()? For example does it it makes standards compliant code
>> *more* likely to call SetVariable() in order to fix up a variable that
>> it thinks was incorrectly set with the NON_VOLATILE attribute.
>
> Do any existing implementations change variables from non-volatile to
> volatile?
>

The UEFI spec is explicit about which variables are volatile and which
are not. Simply relaxing non-volatile to volatile in the general case
doesn't seem like a useful approach to me.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] Multi-cpu boot protocol?

[Ard Biesheuvel]

On 18 May 2018 at 13:49, Grant Likely <grant.lik...@arm.com> wrote:
> On 18/05/2018 12:40, Ard Biesheuvel wrote:
>>
>> On 18 May 2018 at 13:37, Grant Likely <grant.lik...@arm.com> wrote:
>>>
>>> On 18/05/2018 12:13, Andre Przywara wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> On 18/05/18 12:04, Grant Likely wrote:
>>>>>
>>>>>
>>>>> I'm adding some EBBR text around the CPU state at boot and I've lost
>>>>> track of what is being done for multicore bringup. What is the current
>>>>> state-of-the-art for multicore boot protocol when PSCI isn't available?
>>>>
>>>>
>>>>
>>>> It is my understanding that for arm64 PSCI is the only accepted SMP
>>>> bringup method. Now the first ARM64 hardware platform didn't have EL3,
>>>> but wanted to have KVM running, so there was this decision to allow this
>>>> *one* alternative method to enable this platform.
>>>> If I understand Will and Catalin correctly, there is a strong push for
>>>> *no* other methods being added to the kernel.
>>>>
>>>> So for ARM64 the answer should be: PSCI or spin table. Full stop.
>>>
>>>
>>>
>>> AFAIU, MP Boot (ACPI Parking Protocol?) and Spin table are two separate
>>> methods. Correct? So that would be three methods we've got in-kernel at
>>> the
>>> moment.
>>>
>>
>> Indeed.
>>
>>>> For ARM it's quite a different story, though. "New" platforms tend to
>>>> implement PSCI, but there are quite some platforms out there with their
>>>> own methods. Not sure we care about them?
>>>
>>>
>>>
>>> If EL3 is present, I think PSCI is the only interface EBBR should allow.
>>> Proprietary methods are the antithesis of what EBBR is intended to do.
>>>
>>
>> ARMv8-A permits implementation without EL2 or EL3 IIUC, so from a spec
>> pov, it makes sense to mandate spin table or ACPI parking protocol for
>> that use case.
>
>
> One missing bit; I don't believe there are DT bindings for the ACPI
> parking protocol, and similarly no ACPI binding for spin tables.
> Therefore a platform without EL3 must choose to do only DT or only ACPI.

I'd argue that a platform must choose between DT and ACPI anyway,
since we don't want to leave it up to the OS to decide which platform
description is the most accurate one. We have standard EDK2 components
now to make this configurable from the UEFI menus. This means the
firmware can switch between spintable and parking protocol at the same
time.

> I'm rapidly approaching pendanticry here because in practice this is
> unlikely to be a problem. The vast majority of EBBR platforms will be DT
> based, and the platforms that want to have an ACPI option will probably
> target full SBSA/SBBR compliance -- and therefore have EL3.
>
> So, what I'll propose is allow for any of the three (PSCI, ACPI Parking
> Protocol, or spin table) with the caveats:
> * PSCI is required when EL3 exists
> * DT w/o EL3 requires spin-table
> * ACPI w/o EL3 requires ACPI Parking Protocol (and is stupid)
>

PSCI can also be implemented at EL2, and we should not [implicitly]
ban this. You will lose access to KVM if you use EL2 for firmware, but
this could be an appropriate thing to do depending on the use case.

> We'll see if anyone screams about PSCI being required. If so, I'll relax
> it to allow spin-table w/ proprietary EL3.
>
> g.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables

[Ard Biesheuvel]

On 30 April 2018 at 15:57, Chang, Abner (HPS SW/FW Technologist)
<abner.ch...@hpe.com> wrote:
> Hi Ard,
>
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Sunday, April 29, 2018 12:21 AM
>> To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>
>> Cc: Daniel Thompson <daniel.thomp...@linaro.org>; Grant Likely
>> <grant.lik...@arm.com>; Architecture Mailman List > architect...@lists.linaro.org>; l...@cam-list1.cambridge.arm.com;
>> b...@cam-list1.cambridge.arm.com; arm.ebbr-disc...@arm.com
>> Subject: Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent
>> variables
>>
>> On 28 April 2018 at 15:46, Chang, Abner (HPS SW/FW Technologist)
>> <abner.ch...@hpe.com> wrote:
>> > I am behind this topic and not familiar with embedded system with U-boot.
>> Some dumb questions below.
>> > Why there is no persistent storage on platform? I thought at least EEPROM
>> is on platform. Can't EEPROM be the varstore for EFI variable? Or EEPROM is
>> not allowed to write when during runtime? If EEPROM is not possible to be
>> varstore, how about a region from on-board fixed storage? To simulate a
>> partition as EFI varstore from on-platform storage for EFI variable 
>> read/write.
>> > And what is the problem that U-boot can't support SetVariable invoked by
>> OS in runtime?
>> >
>> > One comment to support EFI variable in U-Boot is to refer to the
>> implementation in EDK2 EFI variable.
>> > In EDK2 variable design, another protocol "Firmware Volume Block
>> Protocol" which defined in EFI PI (Platform Initialization spec ) is used as 
>> the
>> abstract layer to abstract storage mechanism from EFI variable driver. The
>> underlying implementation of FVB protocol could access to any kind of
>> storage, such as non-volatile flash, memory, disk or any, that is platform-
>> specific implementation. We probably can apply the same concept of PI spec
>> and edk2 variable implementation on U-Boot UEFI implementation. U-Boot
>> Just provide the generic EFI Variable complaint driver and leave varstore
>> implementation to platform designer.
>>
>> The limitations are not in the software but in the hardware. Embedded or
>> mobile platforms typically only have a single storage device that sits 
>> behind a
>> controller that is either owned by the firmware or by the OS, but not by both
>> at the same time. MMC even has boot partitions and RPMB partitions
>> beyond the primary storage area so that boot images, file systems and
>> secure storage can all share the same flash device.
>>
>> The same applies to EEPROMs on I2C: unless the platform has been carefully
>> architected so that the I2C bus that hosts the EEPROM can be owned by the
>> firmware entirely, you end up in a similar situation where both the firmware
>> and the OS need to access MMIO control registers, and the UEFI spec does
>> not provide any means of arbitration between the two.
>>
>> Therefore, it makes little sense to try and reason about which piece of
>> software does what and whether it is generic or provided by the platform.
>
> Normally  firmware doesn’t access to varstore initiatively after 
> ExitBootService. We actually can treat Runtime SetVariable () as part of OS 
> driver. Just make sure the pointers used in runtime variable driver (and in 
> firmware block driver) are translated to OS virtual address correctly. Also 
> OS probably has to invoke SetVriable() in critical section or in higher 
> priority threat. Then it should be ok to access to varstore under OS if low 
> level FVB driver doesn’t reconfigure controller for varstore accesses. But 
> access to varstore in MMC in both boot time and runtime is more complicated 
> though, perhaps cache it in memory is more easier for varstore in partition 
> case.
>
>

I guess it would be possible to implement this in code. The problem is
that the UEFI spec does not cover any of this, and so there is no way
for the OS to find out whether it can call SetVariable() as the spec
permits, or whether it should switch into this 'special' mode where it
can only call SetVariable() when none of the other cores are executing
completely some completely unrelated piece of code (i.e, the SPI
controller driver) that happens to touch the same hardware on this
particular platform.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables

[Ard Biesheuvel]

On 28 April 2018 at 15:46, Chang, Abner (HPS SW/FW Technologist)
 wrote:
> I am behind this topic and not familiar with embedded system with U-boot. 
> Some dumb questions below.
> Why there is no persistent storage on platform? I thought at least EEPROM is 
> on platform. Can't EEPROM be the varstore for EFI variable? Or EEPROM is not 
> allowed to write when during runtime? If EEPROM is not possible to be 
> varstore, how about a region from on-board fixed storage? To simulate a 
> partition as EFI varstore from on-platform storage for EFI variable 
> read/write.
> And what is the problem that U-boot can't support SetVariable invoked by OS 
> in runtime?
>
> One comment to support EFI variable in U-Boot is to refer to the 
> implementation in EDK2 EFI variable.
> In EDK2 variable design, another protocol "Firmware Volume Block Protocol" 
> which defined in EFI PI (Platform Initialization spec ) is used as the 
> abstract layer to abstract storage mechanism from EFI variable driver. The 
> underlying implementation of FVB protocol could access to any kind of 
> storage, such as non-volatile flash, memory, disk or any, that is 
> platform-specific implementation. We probably can apply the same concept of 
> PI spec and edk2 variable implementation on U-Boot UEFI implementation. 
> U-Boot Just provide the generic EFI Variable complaint driver and leave 
> varstore implementation to platform designer.

The limitations are not in the software but in the hardware. Embedded
or mobile platforms typically only have a single storage device that
sits behind a controller that is either owned by the firmware or by
the OS, but not by both at the same time. MMC even has boot partitions
and RPMB partitions beyond the primary storage area so that boot
images, file systems and secure storage can all share the same flash
device.

The same applies to EEPROMs on I2C: unless the platform has been
carefully architected so that the I2C bus that hosts the EEPROM can be
owned by the firmware entirely, you end up in a similar situation
where both the firmware and the OS need to access MMIO control
registers, and the UEFI spec does not provide any means of arbitration
between the two.

Therefore, it makes little sense to try and reason about which piece
of software does what and whether it is generic or provided by the
platform.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture