Re: [PATCH v2] armv8: crypto: SHA-512 using ARMv8 Crypto Extensions

[Ard Biesheuvel]

On Mon, 12 Feb 2024 at 11:45, Igor Opaniuk  wrote:
>
> From: Igor Opaniuk 
>
> Add support for the SHA-512 Secure Hash Algorithm which uses ARMv8 Crypto
> Extensions. The CPU should support ARMv8.2 instruction set and implement
> SHA512H, SHA512H2, SHA512SU0, and SHA512SU1 instructions.
>
> This information can be obtained from ID_AA64ISAR0_EL1 (AArch64 Instruction
> Set Attribute Register 0), bits [15:12] should be 0b0010 [1], that
> indicates support for SHA512* instructions in AArch64 state. As not all
> ARMv8-base SoCs support that, ARMV8_CE_SHA512 is left disabled by
> default for now.
>
> Validated in QEMU for ARMv8 with compiled-in SHA-2 support (because of
> absence of hw with ARMv8.2-A ready SoC at hand):
>
> => hash sha512 0x4020 0x200
> sha512 for 4020 ... 421f ==> 1aeae269f4eb7c37...
>
> The implementation is based on original implementation from Ard Biesheuvel in
> Linux kernel [2]
>
> [1] 
> https://developer.arm.com/documentation/ddi0601/2023-12/AArch64-Registers/ID-AA64ISAR0-EL1--AArch64-Instruction-Set-Attribute-Register-0
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/crypto/sha2-ce-core.S
>
> CC: Ard Biesheuvel >
> CC: Loic Poulain 
> Signed-off-by: Igor Opaniuk 
> ---
>
> Changes in v2:
> - Dropped "Default n" in Kconfig as Michal Simek suggested
> - Adjusted commit message about QEMU validation
>
>  arch/arm/cpu/armv8/Kconfig  |   4 +
>  arch/arm/cpu/armv8/Makefile |   1 +
>  arch/arm/cpu/armv8/sha512_ce_core.S | 210 
>  arch/arm/cpu/armv8/sha512_ce_glue.c |  20 +++
>  lib/sha512.c|   6 +-
>  5 files changed, 239 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/cpu/armv8/sha512_ce_core.S
>  create mode 100644 arch/arm/cpu/armv8/sha512_ce_glue.c
>
> diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
> index 9f0fb369f7..37b8b60914 100644
> --- a/arch/arm/cpu/armv8/Kconfig
> +++ b/arch/arm/cpu/armv8/Kconfig
> @@ -204,6 +204,10 @@ config ARMV8_CE_SHA256
> bool "SHA-256 digest algorithm (ARMv8 Crypto Extensions)"
> default y if SHA256
>
> +config ARMV8_CE_SHA512
> +   bool "SHA-512 digest algorithm (ARMv8 Crypto Extensions)"
> +   depends on SHA512
> +
>  endif
>
>  endif
> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
> index bba4f570db..3894f2bb2a 100644
> --- a/arch/arm/cpu/armv8/Makefile
> +++ b/arch/arm/cpu/armv8/Makefile
> @@ -45,3 +45,4 @@ obj-$(CONFIG_TARGET_BCMNS3) += bcmns3/
>  obj-$(CONFIG_XEN) += xen/
>  obj-$(CONFIG_ARMV8_CE_SHA1) += sha1_ce_glue.o sha1_ce_core.o
>  obj-$(CONFIG_ARMV8_CE_SHA256) += sha256_ce_glue.o sha256_ce_core.o
> +obj-$(CONFIG_ARMV8_CE_SHA512) += sha512_ce_glue.o sha512_ce_core.o
> \ No newline at end of file
> diff --git a/arch/arm/cpu/armv8/sha512_ce_core.S 
> b/arch/arm/cpu/armv8/sha512_ce_core.S
> new file mode 100644
> index 00..906291f35b
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/sha512_ce_core.S
> @@ -0,0 +1,210 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * sha512-ce-core.S - core SHA-384/SHA-512 transform using v8 Crypto
> + * Extensions
> + *
> + * Copyright (C) 2018 Linaro Ltd 
> + * Copyright (C) 2024 Igor Opaniuk 
> + */
> +
> + #include 
> + #include 
> + #include 
> + #include 
> +
> +   .macro  adr_l, dst, sym
> +   adrp\dst, \sym
> +   add \dst, \dst, :lo12:\sym
> +   .endm
> +
> +   .irpb,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
> +   .set.Lq\b, \b
> +   .set.Lv\b\().2d, \b
> +   .endr
> +
> +   .macro  sha512h, rd, rn, rm
> +   .inst   0xce608000 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
> +   .endm
> +
> +   .macro  sha512h2, rd, rn, rm
> +   .inst   0xce608400 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
> +   .endm
> +
> +   .macro  sha512su0, rd, rn
> +   .inst   0xcec08000 | .L\rd | (.L\rn << 5)
> +   .endm
> +
> +   .macro  sha512su1, rd, rn, rm
> +   .inst   0xce608800 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
> +   .endm
> +

You might check which binutils version supports these instructions
natively, and whether anything older is still supported by u-boot. If
not, you can just drop these macros.

> +   /*
> +* The SHA-512 round constants
> +*/
> +   .section".rodata", "a"
> +   .align  4
> +.Lsha512_rcon:

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Thu, 4 Jan 2024 at 18:53, Chiu, Chasel  wrote:
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel 
> > Sent: Thursday, January 4, 2024 12:43 AM
> > To: Chiu, Chasel 
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > Rutland
> > ; Rob Herring ; Tan, Lean Sheng
> > ; lkml ; Dhaval
> > Sharma ; Brune, Maximilian
> > ; Yunhui Cui ;
> > Dong, Guo ; Tom Rini ; ron minnich
> > ; Guo, Gua ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List 
> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> > On Thu, 4 Jan 2024 at 01:25, Chiu, Chasel  wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Ard Biesheuvel 
> > > > Sent: Wednesday, January 3, 2024 7:22 AM
> > > > To: Chiu, Chasel 
> > > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark
> > > > Rutland ; Rob Herring ; Tan,
> > > > Lean Sheng ; lkml
> > > > ; Dhaval Sharma ;
> > > > Brune, Maximilian ; Yunhui Cui
> > > > ; Dong, Guo ; Tom Rini
> > > > ; ron minnich ; Guo, Gua
> > > > ; linux- a...@vger.kernel.org; U-Boot Mailing
> > > > List 
> > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > > usages
> > > >
> > > > On Fri, 22 Dec 2023 at 20:52, Chiu, Chasel  
> > > > wrote:
> > > > >
> > > > >
> > > > > Please see my reply below inline.
> > > > >
> > > > > Thanks,
> > > > > Chasel
> > > > >
> > > > ...
> > > > > > > > The gEfiMemoryTypeInformationGuid HOB typically carries
> > > > > > > > platform defaults, and the actual memory type information is
> > > > > > > > kept in a non-volatile EFI variable, which gets updated when
> > > > > > > > the memory usage changes. Is this different for UefiPayloadPkg?
> > > > > > > >
> > > > > > > > (For those among the cc'ees less versed in EFI/EDK2: when
> > > > > > > > you get the 'config changed -rebooting' message from the
> > > > > > > > boot firmware, it typically means that this memory type
> > > > > > > > table has changed, and a reboot is necessary.)
> > > > > > > >
> > > > > > > > So the platform init needs to read this variable, or get the
> > > > > > > > information in a different way. I assume it is the payload,
> > > > > > > > not the platform init that updates the variable when
> > > > > > > > necessary. This means the information flows from payload(n)
> > > > > > > > to platform init(n+1), where n is a monotonic index tracking
> > > > > > > > consecutive boots of the
> > > > system.
> > > > > > > >
> > > > > > > > Can you explain how the DT fits into this? How are the
> > > > > > > > runtime-code and runtime-data memory reservation nodes under
> > > > > > > > /reserved-memory used to implement this information exchange
> > > > > > > > between platform init and payload? And how do the HOB and
> > > > > > > > the EFI
> > > > variable fit into this picture?
> > > > > > >
> > > > > > >
> > > > > > > 1. With some offline discussion, we would move
> > > > > > > gEfiMemoryTypeInformationGuid usage to FDT->upl-custom node.
> > > > > > > This is because it is edk2 implementation choice and non-edk2
> > > > > > > PlatformInit or Payload may not have such memory optimization
> > > > > > > implementation. (not a generic usage/requirement for
> > > > > > > PlatformInit and Payload)
> > > > > > >
> > > > > > > The edk2 example flow will be like below:
> > > > > > >
> > > > > > > PlatformInit to GetVariable of gEfiMemoryTypeInformationGuid
> > > > > > > and create Hob-
> > > > > > >
> > > > > > >   PlatformInit to initialize FDT->upl-custom node to report
> > > > > > gEfiMemoryTypeInformationGuid HOB information ->
> > > > > > > Uefi

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Thu, 4 Jan 2024 at 01:25, Chiu, Chasel  wrote:
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel 
> > Sent: Wednesday, January 3, 2024 7:22 AM
> > To: Chiu, Chasel 
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > Rutland
> > ; Rob Herring ; Tan, Lean Sheng
> > ; lkml ; Dhaval
> > Sharma ; Brune, Maximilian
> > ; Yunhui Cui ;
> > Dong, Guo ; Tom Rini ; ron minnich
> > ; Guo, Gua ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List 
> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> > On Fri, 22 Dec 2023 at 20:52, Chiu, Chasel  wrote:
> > >
> > >
> > > Please see my reply below inline.
> > >
> > > Thanks,
> > > Chasel
> > >
> > ...
> > > > > > The gEfiMemoryTypeInformationGuid HOB typically carries platform
> > > > > > defaults, and the actual memory type information is kept in a
> > > > > > non-volatile EFI variable, which gets updated when the memory
> > > > > > usage changes. Is this different for UefiPayloadPkg?
> > > > > >
> > > > > > (For those among the cc'ees less versed in EFI/EDK2: when you
> > > > > > get the 'config changed -rebooting' message from the boot
> > > > > > firmware, it typically means that this memory type table has
> > > > > > changed, and a reboot is necessary.)
> > > > > >
> > > > > > So the platform init needs to read this variable, or get the
> > > > > > information in a different way. I assume it is the payload, not
> > > > > > the platform init that updates the variable when necessary. This
> > > > > > means the information flows from payload(n) to platform
> > > > > > init(n+1), where n is a monotonic index tracking consecutive boots 
> > > > > > of the
> > system.
> > > > > >
> > > > > > Can you explain how the DT fits into this? How are the
> > > > > > runtime-code and runtime-data memory reservation nodes under
> > > > > > /reserved-memory used to implement this information exchange
> > > > > > between platform init and payload? And how do the HOB and the EFI
> > variable fit into this picture?
> > > > >
> > > > >
> > > > > 1. With some offline discussion, we would move
> > > > > gEfiMemoryTypeInformationGuid usage to FDT->upl-custom node. This
> > > > > is because it is edk2 implementation choice and non-edk2
> > > > > PlatformInit or Payload may not have such memory optimization
> > > > > implementation. (not a generic usage/requirement for PlatformInit
> > > > > and Payload)
> > > > >
> > > > > The edk2 example flow will be like below:
> > > > >
> > > > > PlatformInit to GetVariable of gEfiMemoryTypeInformationGuid and
> > > > > create Hob-
> > > > >
> > > > >   PlatformInit to initialize FDT->upl-custom node to report
> > > > gEfiMemoryTypeInformationGuid HOB information ->
> > > > > UefiPayload entry to re-create gEfiMemoryTypeInformationGuid
> > > > > HOB basing
> > > > on FDT input (instead of the default MemoryType inside UefiPayload)
> > > > ->
> > > > >   UefiPayload DxeMain/Gcd will consume
> > > > > gEfiMemoryTypeInformationGuid
> > > > Hob for memory type information ->
> > > > > UefiPayload to initialize UEFI environment (mainly DXE 
> > > > > dispatcher) ->
> > > > >   (additional FV binary appended to common UefiPayload
> > > > > binary)
> > > > PlatformPayload to provide VariableService which is platform
> > > > specific ->
> > > > > UefiPayload UefiBootManager will SetVariable if memory
> > > > > type change
> > > > needed and request a warm reset ->
> > > > >   Back to PlatformInit ...
> > > > >
> > > >
> > > > OK so the upl-custom node can do whatever it needs to. I imagine
> > > > these will include the memory descriptor attribute field, and other
> > > > parts that may be missing from the /reserved-memory DT node 
> > > > specification?
> > >
> > >
> > >

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Fri, 22 Dec 2023 at 20:52, Chiu, Chasel  wrote:
>
>
> Please see my reply below inline.
>
> Thanks,
> Chasel
>
...
> > > > The gEfiMemoryTypeInformationGuid HOB typically carries platform
> > > > defaults, and the actual memory type information is kept in a
> > > > non-volatile EFI variable, which gets updated when the memory usage
> > > > changes. Is this different for UefiPayloadPkg?
> > > >
> > > > (For those among the cc'ees less versed in EFI/EDK2: when you get
> > > > the 'config changed -rebooting' message from the boot firmware, it
> > > > typically means that this memory type table has changed, and a
> > > > reboot is necessary.)
> > > >
> > > > So the platform init needs to read this variable, or get the
> > > > information in a different way. I assume it is the payload, not the
> > > > platform init that updates the variable when necessary. This means
> > > > the information flows from payload(n) to platform init(n+1), where n
> > > > is a monotonic index tracking consecutive boots of the system.
> > > >
> > > > Can you explain how the DT fits into this? How are the runtime-code
> > > > and runtime-data memory reservation nodes under /reserved-memory
> > > > used to implement this information exchange between platform init
> > > > and payload? And how do the HOB and the EFI variable fit into this 
> > > > picture?
> > >
> > >
> > > 1. With some offline discussion, we would move
> > > gEfiMemoryTypeInformationGuid usage to FDT->upl-custom node. This is
> > > because it is edk2 implementation choice and non-edk2 PlatformInit or
> > > Payload may not have such memory optimization implementation. (not a
> > > generic usage/requirement for PlatformInit and Payload)
> > >
> > > The edk2 example flow will be like below:
> > >
> > > PlatformInit to GetVariable of gEfiMemoryTypeInformationGuid and create 
> > > Hob-
> > >
> > >   PlatformInit to initialize FDT->upl-custom node to report
> > gEfiMemoryTypeInformationGuid HOB information ->
> > > UefiPayload entry to re-create gEfiMemoryTypeInformationGuid HOB 
> > > basing
> > on FDT input (instead of the default MemoryType inside UefiPayload) ->
> > >   UefiPayload DxeMain/Gcd will consume gEfiMemoryTypeInformationGuid
> > Hob for memory type information ->
> > > UefiPayload to initialize UEFI environment (mainly DXE 
> > > dispatcher) ->
> > >   (additional FV binary appended to common UefiPayload binary)
> > PlatformPayload to provide VariableService which is platform specific ->
> > > UefiPayload UefiBootManager will SetVariable if memory type 
> > > change
> > needed and request a warm reset ->
> > >   Back to PlatformInit ...
> > >
> >
> > OK so the upl-custom node can do whatever it needs to. I imagine these will
> > include the memory descriptor attribute field, and other parts that may be 
> > missing
> > from the /reserved-memory DT node specification?
>
>
> Yes, if needed by edk2 specific implementation, not generic enough, we may 
> consider to use upl-custom node to pass those data.
>
>
> >
> > >
> > > 2. Now the proposed reserved-memory node usages will be for PlatformInit 
> > > to
> > provide data which may be used by Payload or OS. This is not edk2 specific 
> > and
> > any PlatformInit/Payload could have same support.
> > > Note: all of below are optional and PlatformInit may choose to implement 
> > > some
> > of them or not.
> > >
> > >   - acpi
> > > If PlatformInit created some ACPI tables, this will report a memory 
> > > region which
> > contains all the tables to Payload and Payload may base on this to add some 
> > more
> > tables if required.
> > >
> > >   - acpi-nvs
> > > If PlatformInit has created some ACPI tables which having ACPI NVS memory
> > dependency, this will be that nvs region.
> > >
> >
> > These make sense.
> >
> > >   - boot-code
> > > When PlatformInit having some FW boot phase code that could be freed
> > > for OS to use when payload transferring control to UEFI OS
> > >
> > >   - boot-data
> > > When PlatformInit having some FW boot phase data that could be freed for 
> > > OS
> > to use when payload transferring control to UEFI OS.
> > >
> > >   - runtime-code
> > > PlatformInit may provide some services code that can be used for Payload 
> > > to
> > initialize UEFI Runtime Services for supporting UEFI OS.
> > >
> > >   - runtime-data
> > > PlatformInit may provide some services data that can be used for Payload 
> > > to
> > Initialize UEFI Runtime Services for supporting UEFI OS.
> > >
> >
> > A UEFI OS must consume this information from the UEFI memory map, not from
> > the /reserved-memory nodes. So these nodes must either not be visible to 
> > the OS
> > at all, or carry an annotation that the OS must ignore them.
> >
> > Would it be possible to include a restriction in the DT schema that these 
> > are only
> > valid in the firmware boot phase?
>
>
> https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-boot-servi

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Thu, 21 Dec 2023 at 17:50, Chiu, Chasel  wrote:
>
>
> Hi Ard,
>
> Please see my reply below inline and let me know your thoughts.
>
> Thanks,
> Chasel
>
>
> > -----Original Message-
> > From: Ard Biesheuvel 
> > Sent: Thursday, December 21, 2023 6:31 AM
> > To: Chiu, Chasel 
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > Rutland
> > ; Rob Herring ; Tan, Lean Sheng
> > ; lkml ; Dhaval
> > Sharma ; Brune, Maximilian
> > ; Yunhui Cui ;
> > Dong, Guo ; Tom Rini ; ron minnich
> > ; Guo, Gua ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List 
> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> > On Tue, 28 Nov 2023 at 21:31, Chiu, Chasel  wrote:
> > >
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Ard Biesheuvel 
> > > > Sent: Tuesday, November 28, 2023 10:08 AM
> > > > To: Chiu, Chasel 
> > > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark
> > > > Rutland ; Rob Herring ; Tan,
> > > > Lean Sheng ; lkml
> > > > ; Dhaval Sharma ;
> > > > Brune, Maximilian ; Yunhui Cui
> > > > ; Dong, Guo ; Tom Rini
> > > > ; ron minnich ; Guo, Gua
> > > > ; linux- a...@vger.kernel.org; U-Boot Mailing
> > > > List 
> > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > > usages
> > > >
> > > > You are referring to a 2000 line patch so it is not 100% clear where to 
> > > > look tbh.
> > > >
> > > >
> > > > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel  
> > > > wrote:
> > > > >
> > > > >
> > > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line
> > > > > 268 is for
> > > > related example code.
> > > > >
> > > >
> > > > That refers to a 'memory-allocation' node, right? How does that
> > > > relate to the 'reserved-memory' node?
> > > >
> > > > And crucially, how does this clarify in which way "runtime-code" and
> > > > "runtime- data" reservations are being used?
> > > >
> > > > Since the very beginning of this discussion, I have been asking
> > > > repeatedly for examples that describe the wider context in which these
> > reservations are used.
> > > > The "runtime" into runtime-code and runtime-data means that these
> > > > regions have a special significance to the operating system, not
> > > > just to the next bootloader stage. So I want to understand exactly
> > > > why it is necessary to describe these regions in a way where the
> > > > operating system might be expected to interpret this information and act
> > upon it.
> > > >
> > >
> > >
> > > I think runtime code and data today are mainly for supporting UEFI runtime
> > services - some BIOS functions for OS to utilize, OS may follow below ACPI 
> > spec to
> > treat them as reserved range:
> > > https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#
> > > uefi-memory-types-and-mapping-to-acpi-address-range-types
> > >
> > > Like I mentioned earlier, that PR is still in early phase and has not 
> > > reflected all
> > the required changes yet, but the idea is to build
> > gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.
> > > UEFI generic Payload has DxeMain integrated, however Memory Types are
> > platform-specific, for example, some platforms may need bigger runtime 
> > memory
> > for their implementation, that's why we want such FDT reserved-memory node 
> > to
> > tell DxeMain.
> > >
> >
> > > The Payload flow will be like this:
> > >   Payload creates built-in default MemoryTypes table ->
> > > FDT reserved-memory node to override if required (this also ensures 
> > > the
> > same memory map cross boots so ACPI S4 works) ->
> > >   Build gEfiMemoryTypeInformationGuid HOB by "platfom specific"
> > MemoryTypes Table ->
> > > DxeMain/GCD to consume this MemoryTypes table and setup memory
> > service ->
> > >   Install memory types table to UEFI system table.Configuration 
> > > table...
> > >
> > > Note: if Payload built-in default MemoryTypes table w

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Tue, 28 Nov 2023 at 21:31, Chiu, Chasel  wrote:
>
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel 
> > Sent: Tuesday, November 28, 2023 10:08 AM
> > To: Chiu, Chasel 
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > Rutland
> > ; Rob Herring ; Tan, Lean Sheng
> > ; lkml ; Dhaval
> > Sharma ; Brune, Maximilian
> > ; Yunhui Cui ;
> > Dong, Guo ; Tom Rini ; ron minnich
> > ; Guo, Gua ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List 
> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> > You are referring to a 2000 line patch so it is not 100% clear where to 
> > look tbh.
> >
> >
> > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel  wrote:
> > >
> > >
> > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for
> > related example code.
> > >
> >
> > That refers to a 'memory-allocation' node, right? How does that relate to 
> > the
> > 'reserved-memory' node?
> >
> > And crucially, how does this clarify in which way "runtime-code" and 
> > "runtime-
> > data" reservations are being used?
> >
> > Since the very beginning of this discussion, I have been asking repeatedly 
> > for
> > examples that describe the wider context in which these reservations are 
> > used.
> > The "runtime" into runtime-code and runtime-data means that these regions 
> > have
> > a special significance to the operating system, not just to the next 
> > bootloader
> > stage. So I want to understand exactly why it is necessary to describe these
> > regions in a way where the operating system might be expected to interpret 
> > this
> > information and act upon it.
> >
>
>
> I think runtime code and data today are mainly for supporting UEFI runtime 
> services - some BIOS functions for OS to utilize, OS may follow below ACPI 
> spec to treat them as reserved range:
> https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#uefi-memory-types-and-mapping-to-acpi-address-range-types
>
> Like I mentioned earlier, that PR is still in early phase and has not 
> reflected all the required changes yet, but the idea is to build 
> gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.
> UEFI generic Payload has DxeMain integrated, however Memory Types are 
> platform-specific, for example, some platforms may need bigger runtime memory 
> for their implementation, that's why we want such FDT reserved-memory node to 
> tell DxeMain.
>

> The Payload flow will be like this:
>   Payload creates built-in default MemoryTypes table ->
> FDT reserved-memory node to override if required (this also ensures the 
> same memory map cross boots so ACPI S4 works) ->
>   Build gEfiMemoryTypeInformationGuid HOB by "platfom specific" 
> MemoryTypes Table ->
> DxeMain/GCD to consume this MemoryTypes table and setup memory 
> service ->
>   Install memory types table to UEFI system table.Configuration 
> table...
>
> Note: if Payload built-in default MemoryTypes table works fine for the 
> platform, then FDT reserved-memory node does not need to provide such 'usage' 
> compatible strings. (optional)
> This FDT node could allow flexibility/compatibility without rebuilding 
> Payload binary.
>
> Not sure if I answered all your questions, please highlight which area you 
> need more information.
>

The gEfiMemoryTypeInformationGuid HOB typically carries platform
defaults, and the actual memory type information is kept in a
non-volatile EFI variable, which gets updated when the memory usage
changes. Is this different for UefiPayloadPkg?

(For those among the cc'ees less versed in EFI/EDK2: when you get the
'config changed -rebooting' message from the boot firmware, it
typically means that this memory type table has changed, and a reboot
is necessary.)

So the platform init needs to read this variable, or get the
information in a different way. I assume it is the payload, not the
platform init that updates the variable when necessary. This means the
information flows from payload(n) to platform init(n+1), where n is a
monotonic index tracking consecutive boots of the system.

Can you explain how the DT fits into this? How are the runtime-code
and runtime-data memory reservation nodes under /reserved-memory used
to implement this information exchange between platform init and
payload? And how do the HOB and the EFI variable fit into this
picture?

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

You are referring to a 2000 line patch so it is not 100% clear where
to look tbh.


On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel  wrote:
>
>
> In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for 
> related example code.
>

That refers to a 'memory-allocation' node, right? How does that relate
to the 'reserved-memory' node?

And crucially, how does this clarify in which way "runtime-code" and
"runtime-data" reservations are being used?

Since the very beginning of this discussion, I have been asking
repeatedly for examples that describe the wider context in which these
reservations are used. The "runtime" into runtime-code and
runtime-data means that these regions have a special significance to
the operating system, not just to the next bootloader stage. So I want
to understand exactly why it is necessary to describe these regions in
a way where the operating system might be expected to interpret this
information and act upon it.


>
> > -Original Message-
> > From: Chiu, Chasel
> > Sent: Tuesday, November 21, 2023 10:34 AM
> > To: Ard Biesheuvel ; Simon Glass 
> > Cc: devicet...@vger.kernel.org; Mark Rutland ; Rob
> > Herring ; Tan, Lean Sheng ; lkml
> > ; Dhaval Sharma ; Brune,
> > Maximilian ; Yunhui Cui
> > ; Dong, Guo ; Tom Rini
> > ; ron minnich ; Guo, Gua
> > ; linux-a...@vger.kernel.org; U-Boot Mailing List  > b...@lists.denx.de>; Chiu, Chasel 
> > Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> >
> > Hi Ard,
> >
> > Here is the POC PR for your reference:
> > https://github.com/tianocore/edk2/pull/4969/files#diff-
> > ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR26
> > 8
> > Please note that this PR is still in early phase and expected to have 
> > significant
> > changes.
> >
> > The idea is that payload entry will create gEfiMemoryTypeInformationGuid HOB
> > with payload default memory types and allow FDT to override if correspond 
> > node
> > present.
> > Please let me know if you have questions or suggestions.
> >
> > Thanks,
> > Chasel
> >
> >
> > > -Original Message-
> > > From: Ard Biesheuvel 
> > > Sent: Tuesday, November 21, 2023 8:42 AM
> > > To: Simon Glass 
> > > Cc: Chiu, Chasel ; devicet...@vger.kernel.org;
> > > Mark Rutland ; Rob Herring ;
> > > Tan, Lean Sheng ; lkml
> > > ; Dhaval Sharma ;
> > > Brune, Maximilian ; Yunhui Cui
> > > ; Dong, Guo ; Tom Rini
> > > ; ron minnich ; Guo, Gua
> > > ; linux- a...@vger.kernel.org; U-Boot Mailing List
> > > 
> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > usages
> > >
> > > On Mon, 20 Nov 2023 at 21:12, Simon Glass  wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel  
> > > > wrote:
> > > > >
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > Please see my reply below inline.
> > > > >
> > > > > Thanks,
> > > > > Chasel
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Ard Biesheuvel 
> > > > > > Sent: Saturday, November 11, 2023 3:04 AM
> > > > > > To: Chiu, Chasel 
> > > > > > Cc: Simon Glass ; devicet...@vger.kernel.org;
> > > > > > Mark Rutland ; Rob Herring
> > > > > > ; Tan, Lean Sheng ;
> > > > > > lkml ; Dhaval Sharma
> > > > > > ; Brune, Maximilian
> > > > > > ; Yunhui Cui
> > > > > > ; Dong, Guo ; Tom
> > > > > > Rini ; ron minnich ;
> > > > > > Guo, Gua ; linux- a...@vger.kernel.org;
> > > > > > U-Boot Mailing List 
> > > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common
> > > > > > reserved-memory usages
> > > > > >
> > > > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel 
> > wrote:
> > > > > > >
> > > > > > >
> > > > > > > Just sharing some usage examples from UEFI/EDK2 scenario.
> > > > > > > To support ACPI S4/Hibernation, memory map must be consistent
> > > > > > > before entering and after resuming from S4, in this case

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Mon, 20 Nov 2023 at 21:12, Simon Glass  wrote:
>
> Hi,
>
> On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel  wrote:
> >
> >
> > Hi Ard,
> >
> > Please see my reply below inline.
> >
> > Thanks,
> > Chasel
> >
> >
> > > -Original Message-
> > > From: Ard Biesheuvel 
> > > Sent: Saturday, November 11, 2023 3:04 AM
> > > To: Chiu, Chasel 
> > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > > Rutland
> > > ; Rob Herring ; Tan, Lean Sheng
> > > ; lkml ; Dhaval
> > > Sharma ; Brune, Maximilian
> > > ; Yunhui Cui ;
> > > Dong, Guo ; Tom Rini ; ron minnich
> > > ; Guo, Gua ; linux-
> > > a...@vger.kernel.org; U-Boot Mailing List 
> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > usages
> > >
> > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel  wrote:
> > > >
> > > >
> > > > Just sharing some usage examples from UEFI/EDK2 scenario.
> > > > To support ACPI S4/Hibernation, memory map must be consistent before
> > > > entering and after resuming from S4, in this case payload may need to
> > > > know previous memory map from bootloader (currently generic payload
> > > > cannot access platform/bootloader specific non-volatile data, thus
> > > > could not save/restore memory map information)
> > >
> > > So how would EDK2 reconstruct the entire EFI memory map from just these
> > > unannotated /reserved-memory nodes? The EFI memory map contains much
> > > more information than that, and all of it has to match the pre-hibernate 
> > > situation,
> > > right? Can you given an example?
> >
> >
> > Here we listed only typically memory types that may change cross different 
> > platforms.
> > Reserved memory type already can be handled by reserved-memory node, and 
> > rest of the types usually no need to change cross platforms thus currently 
> > we could rely on default in generic payload.
> > In the future if we see a need to add new memory types we will discuss and 
> > add it to FDT schema.
> >
> >
> >
> > >
> > > > Another usage is to support binary model which generic payload is a 
> > > > prebuilt
> > > binary compatible for all platforms/configurations, however the payload 
> > > default
> > > memory map might not always work for all the configurations and we want to
> > > allow bootloader to override payload default memory map without 
> > > recompiling.
> > > >
> > >
> > > Agreed. But can you explain how a EDK2 payload might make meaningful use 
> > > of
> > > 'runtime-code' regions provided via DT  by the non-EDK2 platform init? 
> > > Can you
> > > give an example?
> >
> >
> > Runtime-code/data is used by UEFI payload for booting UEFI OS which 
> > required UEFI runtime services.
> > Platform Init will select some regions from the usable memory and assign it 
> > to runtime-code/data for UPL to consume. Or assign same runtime-code/data 
> > from previous boot.
> > If UEFI OS is not supported, PlatformInit may not need to provide 
> > runtime-code/data regions to payload. (always providing runtime-code/data 
> > should be supported too)
> >
> >
> > >
> > > > Under below assumption:
> > > > FDT OS impact has been evaluated and taken care by relevant
> > > experts/stakeholders.
> > > > Reviewed-by: Chasel Chiu 
> > > >
> > >
> > > I am sorry but I don't know what 'FDT OS impact' means. We are talking 
> > > about a
> > > firmware-to-firmware abstraction that has the potential to leak into the 
> > > OS
> > > visible interface.
> > >
> > > I am a maintainer in the Tianocore project myself, so it would help if 
> > > you could
> > > explain who these relevant experts and stakeholders are. Was this 
> > > discussed on
> > > the edk2-devel mailing list? If so, apologies for missing it but I may 
> > > not have been
> > > cc'ed perhaps?
> >
> >
> >
> >
> > I'm not familiar with FDT OS, also I do not know if who from edk2-devel 
> > were supporting FDT OS, I think Simon might be able to connect FDT OS 
> > experts/stakeholders.
> > We are mostly focusing on payload firmware phase implementation in edk2 
> > (and other payloads too), however, sin

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel  wrote:
>
>
> Just sharing some usage examples from UEFI/EDK2 scenario.
> To support ACPI S4/Hibernation, memory map must be consistent before entering 
> and after resuming from S4, in this case payload may need to know previous 
> memory map from bootloader (currently generic payload cannot access 
> platform/bootloader specific non-volatile data, thus could not save/restore 
> memory map information)

So how would EDK2 reconstruct the entire EFI memory map from just
these unannotated /reserved-memory nodes? The EFI memory map contains
much more information than that, and all of it has to match the
pre-hibernate situation, right? Can you given an example?

> Another usage is to support binary model which generic payload is a prebuilt 
> binary compatible for all platforms/configurations, however the payload 
> default memory map might not always work for all the configurations and we 
> want to allow bootloader to override payload default memory map without 
> recompiling.
>

Agreed. But can you explain how a EDK2 payload might make meaningful
use of 'runtime-code' regions provided via DT  by the non-EDK2
platform init? Can you give an example?

> Under below assumption:
> FDT OS impact has been evaluated and taken care by relevant 
> experts/stakeholders.
> Reviewed-by: Chasel Chiu 
>

I am sorry but I don't know what 'FDT OS impact' means. We are talking
about a firmware-to-firmware abstraction that has the potential to
leak into the OS visible interface.

I am a maintainer in the Tianocore project myself, so it would help if
you could explain who these relevant experts and stakeholders are. Was
this discussed on the edk2-devel mailing list? If so, apologies for
missing it but I may not have been cc'ed perhaps?


>
> > -Original Message-
> > From: Simon Glass 
> > Sent: Tuesday, September 26, 2023 12:43 PM
> > To: devicet...@vger.kernel.org
> > Cc: Mark Rutland ; Rob Herring ;
> > Tan, Lean Sheng ; lkml  > ker...@vger.kernel.org>; Dhaval Sharma ; Brune,
> > Maximilian ; Yunhui Cui
> > ; Dong, Guo ; Tom Rini
> > ; ron minnich ; Guo, Gua
> > ; Chiu, Chasel ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List ; Ard
> > Biesheuvel ; Simon Glass 
> > Subject: [PATCH v7 2/2] schemas: Add some common reserved-memory usages
> >
> > It is common to split firmware into 'Platform Init', which does the initial 
> > hardware
> > setup and a "Payload" which selects the OS to be booted.
> > Thus an handover interface is required between these two pieces.
> >
> > Where UEFI boot-time services are not available, but UEFI firmware is 
> > present on
> > either side of this interface, information about memory usage and 
> > attributes must
> > be presented to the "Payload" in some form.
> >
> > This aims to provide an small schema addition for the memory mapping needed
> > to keep these two pieces working together well.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v7:
> > - Rename acpi-reclaim to acpi
> > - Drop individual mention of when memory can be reclaimed
> > - Rewrite the item descriptions
> > - Add back the UEFI text (with trepidation)
> >
> > Changes in v6:
> > - Drop mention of UEFI
> > - Use compatible strings instead of node names
> >
> > Changes in v5:
> > - Drop the memory-map node (should have done that in v4)
> > - Tidy up schema a bit
> >
> > Changes in v4:
> > - Make use of the reserved-memory node instead of creating a new one
> >
> > Changes in v3:
> > - Reword commit message again
> > - cc a lot more people, from the FFI patch
> > - Split out the attributes into the /memory nodes
> >
> > Changes in v2:
> > - Reword commit message
> >
> >  .../reserved-memory/common-reserved.yaml  | 71 +++
> >  1 file changed, 71 insertions(+)
> >  create mode 100644 dtschema/schemas/reserved-memory/common-
> > reserved.yaml
> >
> > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml
> > b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > new file mode 100644
> > index 000..f7fbdfd
> > --- /dev/null
> > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > @@ -0,0 +1,71 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2
> > +---
> > +$id:
> > +http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Common m

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Wed, 8 Nov 2023 at 14:57, Rob Herring  wrote:
>
> On Wed, Nov 8, 2023 at 5:38 AM Ard Biesheuvel  wrote:
> >
> > On Tue, 7 Nov 2023 at 19:07, Rob Herring  wrote:
> > >
> > >
> > > All of this:
> > >
> >
> > > > On Mon, 16 Oct 2023 at 15:54, Simon Glass  wrote:
> > > > >
> > > > > It is not specific to EDK2. Imagine this boot sequence:
> > > > >
> > > > > - Platform Init (U-Boot) starts up
> > > > > - U-Boot uses its platform knowledge to sets some ACPI tables and put
> > > > > various things in memory
> > > > > - U-Boot sets up some runtime code and data for the OS
> > > > > - U-Boot jumps to the Tianocore payload **
> > > > > - Payload (Tianocore) wants to know where the ACPI tables are, for 
> > > > > example
> > > > > - Tianocore needs to provide boot services to the OS, so needs to know
> > > > > the memory map, etc.
> > > > >
> > > > > ** At this point we want to use DT to pass the required information.
> > > > >
> > > > > Of course, Platform Init could be coreboot or Tianocore or some
> > > > > strange private binary. Payload could be U-Boot or something else.
> > > > > That is the point of this effort, to build interoperability.
> > >
> > > [...]
> > >
> > > > > Perhaps the problem here is that Linux has tied itself up in knots
> > > > > with its EFI stuff and DT fixups and what-not. But this is not that.
> > > > > It is a simple handoff between two pieces of firmware, Platform Init
> > > > > and Payload. It has nothing to do with the OS. With Tianocore they are
> > > > > typically combined, but with this usage they are split, and we can
> > > > > swap out one project for another on either side of the DT interface.
> > >
> > > Is perhaps the clearest description of the problem you want to solve.
> > > It's clearly related to EFI though not the interface to the OS. IIRC,
> > > "platform init" and "payload" are terms in the UEFI spec, right?
> >
> > No they are not. This is from the universal payload specification that
> > is being drafted here
> >
> > https://universalpayload.github.io/spec/index.html
> >
> > but the UEFI specification does not use this terminology.
>
> Then I'm confused as to what this is:
>
> https://uefi.org/specs/PI/1.8/index.html
>

The PI and UEFI specifications are both maintained by the UEFI forum.

The UEFI specification covers external APIs for firmware
implementations, i.e., the OS visible interface and the public API for
UEFI device drivers that are not tightly integrated with system
firmware (for example, the GPU boot time driver in the ROM of an
add-in card)

The UEFI forum's PI spec describes system firmware internals, and
defines the SEC, PEI DXE and BDS boot phases, among other things.

It is possible to implement UEFI without PI (which is what uboot does,
for instance), but Tianocore/EDK2 is the reference implementation for
both PI and UEFI, and sadly, there is no discernible distinction
between the two (e.g., both PI and UEFI use identifiers with EFI_ type
and enum identifier prefixes)

'platform init' in the context of this discussion is something
completely separate, and has zero bearing on the PI<->UEFI handover in
Tianocore (which is not really a handover to begin with).

There is code in Tianocore which allows it to run as a 'payload',
which means [presumably] that only the DXE and subsequent phases are
launched from a 'platform init' component that describes the platform
using some of the DT bindings that are under discussion here. In this
case, I can see how some of the ACPI descriptions provided by the
'platform init' might be inherited by the 'payload'. However, I don't
see how such a Tianocore payload would make meaningful use of
boot/runtime code/data described in general terms using this proposed
binding, which is why I keep asking for an example scenario.

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Tue, 7 Nov 2023 at 19:07, Rob Herring  wrote:
>
>
> All of this:
>

> > On Mon, 16 Oct 2023 at 15:54, Simon Glass  wrote:
> > >
> > > It is not specific to EDK2. Imagine this boot sequence:
> > >
> > > - Platform Init (U-Boot) starts up
> > > - U-Boot uses its platform knowledge to sets some ACPI tables and put
> > > various things in memory
> > > - U-Boot sets up some runtime code and data for the OS
> > > - U-Boot jumps to the Tianocore payload **
> > > - Payload (Tianocore) wants to know where the ACPI tables are, for example
> > > - Tianocore needs to provide boot services to the OS, so needs to know
> > > the memory map, etc.
> > >
> > > ** At this point we want to use DT to pass the required information.
> > >
> > > Of course, Platform Init could be coreboot or Tianocore or some
> > > strange private binary. Payload could be U-Boot or something else.
> > > That is the point of this effort, to build interoperability.
>
> [...]
>
> > > Perhaps the problem here is that Linux has tied itself up in knots
> > > with its EFI stuff and DT fixups and what-not. But this is not that.
> > > It is a simple handoff between two pieces of firmware, Platform Init
> > > and Payload. It has nothing to do with the OS. With Tianocore they are
> > > typically combined, but with this usage they are split, and we can
> > > swap out one project for another on either side of the DT interface.
>
> Is perhaps the clearest description of the problem you want to solve.
> It's clearly related to EFI though not the interface to the OS. IIRC,
> "platform init" and "payload" are terms in the UEFI spec, right?

No they are not. This is from the universal payload specification that
is being drafted here

https://universalpayload.github.io/spec/index.html

but the UEFI specification does not use this terminology.

> I don't recall how well defined those are vs. just abstract concepts.
>
> Is it only for this interface or any firmware to firmware handoff. If
> the former, then I'm looking for folks involved with EFI/Tianocore to
> have some buy-in. If the latter, then this should be part of the
> firmware handoff efforts and have buy-in there.
>

I still haven't seen any example of how platform init would make
meaningful use of 'boot-code' and 'runtime-code' regions to inform a
payload about executable regions in memory. Especially 'runtime code'
is interesting here, as it presumably means that the OS must map such
regions as executable in some way. This is why I mentioned phandles in
a previous reply: there /must/ be some additional context provided
elsewhere, or the distinction between boot code/data and runtime
code/data is meaningless.

So again, can we *please* have an example of how these regions will be
used in practice?

> > > I do have views on the 'EFI' opt-out with reserved-memory, if you are
> > > interested, but that relates to the OS. If you are wanting to place
> > > some constraints on /reserved-memory and /memory we could do that
> > > e.g. that the DT and the map returned by EFI boot services must be
> > > consistent. But as it is, the nodes are ignored by the OS when booting
> > > with EFI, aren't they?
> >
> > Can this be applied, please? If there are further comments, please let me 
> > know.
>
> I really have limited knowledge and interest in this. I don't mind
> hosting something like this in dtschema, but I'm not taking it without
> buy-in from multiple parties which I haven't seen.
>

I will state again that I do not object to these bindings as long as
they are restricted to use in the context of firmware. However, there
is no scoping in DT schema as far as I am aware, which means that the
OS may be forced/expected to interpret these regions beyond simply
disregarding them and treating them as reserved memory, and *that* is
something I strongly object to.

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Sat, 7 Oct 2023 at 02:03, Simon Glass  wrote:
>
> Hi Ard,
>
> On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> >
> > On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> > > >
> > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
> > > > > >
> > > > > > It is common to split firmware into 'Platform Init', which does the
> > > > > > initial hardware setup and a "Payload" which selects the OS to be 
> > > > > > booted.
> > > > > > Thus an handover interface is required between these two pieces.
> > > > > >
> > > > > > Where UEFI boot-time services are not available, but UEFI firmware 
> > > > > > is
> > > > > > present on either side of this interface, information about memory 
> > > > > > usage
> > > > > > and attributes must be presented to the "Payload" in some form.
> > > > > >
> > > > > > This aims to provide an small schema addition for the memory mapping
> > > > > > needed to keep these two pieces working together well.
> > > > > >
> > > > > > Signed-off-by: Simon Glass 
> > > > > > ---
> > > > > >
> > > > > > Changes in v7:
> > > > > > - Rename acpi-reclaim to acpi
> > > > > > - Drop individual mention of when memory can be reclaimed
> > > > > > - Rewrite the item descriptions
> > > > > > - Add back the UEFI text (with trepidation)
> > > > >
> > > > > I am again checking on this series. Can it be applied, please?
> > > > >
> > > >
> > > > Apologies for the delay in response. I have been away.
> > >
> > > OK, I hope you had a nice trip.
> > >
> >
> > Thanks, it was wonderful!
> >
> > > >
> > > > >
> > > > > >
> > > > > > Changes in v6:
> > > > > > - Drop mention of UEFI
> > > > > > - Use compatible strings instead of node names
> > > > > >
> > > > > > Changes in v5:
> > > > > > - Drop the memory-map node (should have done that in v4)
> > > > > > - Tidy up schema a bit
> > > > > >
> > > > > > Changes in v4:
> > > > > > - Make use of the reserved-memory node instead of creating a new one
> > > > > >
> > > > > > Changes in v3:
> > > > > > - Reword commit message again
> > > > > > - cc a lot more people, from the FFI patch
> > > > > > - Split out the attributes into the /memory nodes
> > > > > >
> > > > > > Changes in v2:
> > > > > > - Reword commit message
> > > > > >
> > > > > >  .../reserved-memory/common-reserved.yaml  | 71 
> > > > > > +++
> > > > > >  1 file changed, 71 insertions(+)
> > > > > >  create mode 100644 
> > > > > > dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > > >
> > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml 
> > > > > > b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > > > new file mode 100644
> > > > > > index 000..f7fbdfd
> > > > > > --- /dev/null
> > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > > > @@ -0,0 +1,71 @@
> > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +$id: 
> > > > > > http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: Common memory reservations
> > > > > > +
> > > > > > +description: |
> > > > > > +  Specifies that the reserved memory region can be used for the 
> > > 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
>
> Hi Ard,
>
> On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> >
> > On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> > >
> > > Hi Rob,
> > >
> > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
> > > >
> > > > It is common to split firmware into 'Platform Init', which does the
> > > > initial hardware setup and a "Payload" which selects the OS to be 
> > > > booted.
> > > > Thus an handover interface is required between these two pieces.
> > > >
> > > > Where UEFI boot-time services are not available, but UEFI firmware is
> > > > present on either side of this interface, information about memory usage
> > > > and attributes must be presented to the "Payload" in some form.
> > > >
> > > > This aims to provide an small schema addition for the memory mapping
> > > > needed to keep these two pieces working together well.
> > > >
> > > > Signed-off-by: Simon Glass 
> > > > ---
> > > >
> > > > Changes in v7:
> > > > - Rename acpi-reclaim to acpi
> > > > - Drop individual mention of when memory can be reclaimed
> > > > - Rewrite the item descriptions
> > > > - Add back the UEFI text (with trepidation)
> > >
> > > I am again checking on this series. Can it be applied, please?
> > >
> >
> > Apologies for the delay in response. I have been away.
>
> OK, I hope you had a nice trip.
>

Thanks, it was wonderful!

> >
> > >
> > > >
> > > > Changes in v6:
> > > > - Drop mention of UEFI
> > > > - Use compatible strings instead of node names
> > > >
> > > > Changes in v5:
> > > > - Drop the memory-map node (should have done that in v4)
> > > > - Tidy up schema a bit
> > > >
> > > > Changes in v4:
> > > > - Make use of the reserved-memory node instead of creating a new one
> > > >
> > > > Changes in v3:
> > > > - Reword commit message again
> > > > - cc a lot more people, from the FFI patch
> > > > - Split out the attributes into the /memory nodes
> > > >
> > > > Changes in v2:
> > > > - Reword commit message
> > > >
> > > >  .../reserved-memory/common-reserved.yaml  | 71 +++
> > > >  1 file changed, 71 insertions(+)
> > > >  create mode 100644 
> > > > dtschema/schemas/reserved-memory/common-reserved.yaml
> > > >
> > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml 
> > > > b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > new file mode 100644
> > > > index 000..f7fbdfd
> > > > --- /dev/null
> > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > @@ -0,0 +1,71 @@
> > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: 
> > > > http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Common memory reservations
> > > > +
> > > > +description: |
> > > > +  Specifies that the reserved memory region can be used for the purpose
> > > > +  indicated by its compatible string.
> > > > +
> > > > +  Clients may reuse this reserved memory if they understand what it is 
> > > > for,
> > > > +  subject to the notes below.
> > > > +
> > > > +maintainers:
> > > > +  - Simon Glass 
> > > > +
> > > > +allOf:
> > > > +  - $ref: reserved-memory.yaml
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +description: |
> > > > +  This describes some common memory reservations, with the 
> > > > compatible
> > > > +  string indicating what it is used for:
> > > > +
> > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables
> > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is 
> > > > reserved by
> > > > +   the firmware for its use and is required to be saved and 
> > > > restored
> > 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
>
> Hi Rob,
>
> On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
> >
> > It is common to split firmware into 'Platform Init', which does the
> > initial hardware setup and a "Payload" which selects the OS to be booted.
> > Thus an handover interface is required between these two pieces.
> >
> > Where UEFI boot-time services are not available, but UEFI firmware is
> > present on either side of this interface, information about memory usage
> > and attributes must be presented to the "Payload" in some form.
> >
> > This aims to provide an small schema addition for the memory mapping
> > needed to keep these two pieces working together well.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v7:
> > - Rename acpi-reclaim to acpi
> > - Drop individual mention of when memory can be reclaimed
> > - Rewrite the item descriptions
> > - Add back the UEFI text (with trepidation)
>
> I am again checking on this series. Can it be applied, please?
>

Apologies for the delay in response. I have been away.

>
> >
> > Changes in v6:
> > - Drop mention of UEFI
> > - Use compatible strings instead of node names
> >
> > Changes in v5:
> > - Drop the memory-map node (should have done that in v4)
> > - Tidy up schema a bit
> >
> > Changes in v4:
> > - Make use of the reserved-memory node instead of creating a new one
> >
> > Changes in v3:
> > - Reword commit message again
> > - cc a lot more people, from the FFI patch
> > - Split out the attributes into the /memory nodes
> >
> > Changes in v2:
> > - Reword commit message
> >
> >  .../reserved-memory/common-reserved.yaml  | 71 +++
> >  1 file changed, 71 insertions(+)
> >  create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml
> >
> > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml 
> > b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > new file mode 100644
> > index 000..f7fbdfd
> > --- /dev/null
> > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > @@ -0,0 +1,71 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Common memory reservations
> > +
> > +description: |
> > +  Specifies that the reserved memory region can be used for the purpose
> > +  indicated by its compatible string.
> > +
> > +  Clients may reuse this reserved memory if they understand what it is for,
> > +  subject to the notes below.
> > +
> > +maintainers:
> > +  - Simon Glass 
> > +
> > +allOf:
> > +  - $ref: reserved-memory.yaml
> > +
> > +properties:
> > +  compatible:
> > +description: |
> > +  This describes some common memory reservations, with the compatible
> > +  string indicating what it is used for:
> > +
> > + acpi: Advanced Configuration and Power Interface (ACPI) tables
> > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is 
> > reserved by
> > +   the firmware for its use and is required to be saved and 
> > restored
> > +   across an NVS sleep
> > + boot-code: Contains code used for booting which is not needed by 
> > the OS
> > + boot-code: Contains data used for booting which is not needed by 
> > the OS
> > + runtime-code: Contains code used for interacting with the system 
> > when
> > +   running the OS
> > + runtime-data: Contains data used for interacting with the system 
> > when
> > +   running the OS
> > +
> > +enum:
> > +  - acpi
> > +  - acpi-nvs
> > +  - boot-code
> > +  - boot-data
> > +  - runtime-code
> > +  - runtime-data
> > +

As I mentioned a few times already, I don't think these compatibles
should be introduced here.

A reserved region has a specific purpose, and the compatible should be
more descriptive than the enum above. If the consumer does not
understand this purpose, it should simply treat the memory as reserved
and not touch it. Alternatively, these regions can be referenced from
other DT nodes using phandles if needed.


> > +  reg:
> > +description: region of memory that is reserved for the purpose 
> > indicated
> > +  by the compatible string.
> > +
> > +required:
> > +  - reg
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +reserved-memory {
> > +#address-cells = <1>;
> > +#size-cells = <1>;
> > +
> > +reserved@1234 {
> > +compatible = "boot-code";
> > +reg = <0x1234 0x0080>;
> > +};
> > +
> > +reserved@4321 {
> > +compatible = "boot-data";
> > +reg = <0x4321 0x0080>;
> > +};
> > +};
> > --
> > 2.42.0.515.g380fc7ccd1-goog
> >
>
> Regards,
> Simon

Re: [PATCH v5 3/4] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Thu, 7 Sept 2023 at 17:57, Simon Glass  wrote:
>
> Hi Ard,
>
> On Thu, 7 Sept 2023 at 09:07, Ard Biesheuvel  wrote:
> >
> > On Thu, 7 Sept 2023 at 16:50, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Thu, 7 Sept 2023 at 08:12, Ard Biesheuvel  wrote:
> > > >
> > > > On Thu, 7 Sept 2023 at 15:56, Simon Glass  wrote:
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > On Thu, 7 Sept 2023 at 07:31, Ard Biesheuvel  wrote:
> > > > > >
...
> > > > > >
> > > > > > I'm happy to help flesh this out, but you still have not provided us
> > > > > > with an actual use case, so I can only draw from my own experience
> > > > > > putting together firmware for virtual and physical ARM machines.
> > > > >
> > > > > I did explain that this is needed when Tianocore is on both sides of
> > > > > the interface, since Platform Init places some things in memory and
> > > > > the Payload needs to preserve them there, and/or know where they are.
> > > > >
> > > > > I think the problem might be that you don't agree with that, but it
> > > > > seems to be a fact, so I am not sure how I can alter it.
> > > > >
> > > > > Please can you clearly explain which part of the use case you are 
> > > > > missing.
> > > > >
> > > >
> > > > 'Tianocore on both sides of the interface' means that Tianocore runs
> > > > as the platform init code, and uses a bespoke DT based protocol to
> > > > launch another instance of Tianocore as the payload, right?
> > >
> > > Not another instance, no. Just the other half of Tianocore. The first
> > > half does platform init and the second half does the loading of the
> > > OS.
> > >
> >
> > That doesn't make any sense to me.
> >
> > > >
> > > > Tianocore/EDK2 already implements methods to reinvoke itself if needed
> > > > (e.g., during a firmware update), and does so by launching a new DXE
> > > > core. So the boot sequence looks like
> > > >
> > > > SEC -> PEI -> DXE -> BDS -> app that invokes UpdateCapsule() -> DXE ->
> > > > firmware update
> > > >
> > > > So please elaborate on how this Tianocore on both sides of the
> > > > interface is put together when it uses this DT based handover. We
> > > > really need a better understanding of this in order to design a DT
> > > > binding that meets its needs.
> > >
> > > Are you familiar with building Tianocore as a coreboot payload, for
> > > example? That shows Tianocore running as just the Payload, with
> > > coreboot doing the platform init. So the use case I am talking about
> > > is similar to that.
> > >
> >
> > Yes I am familiar with that, and it is a completely different thing.
>
> Right, but that is my use case.
>

OK. You alluded to Tianocore <-> Tianocore being your use case, which
is why I kept asking for clarification, as using a DT with this
binding seems unusual at the very least.

So coreboot does the platform init, and then hands over to Tianocore.

I take it we are not talking about x86 here, so there are no Intel FSP
blobs that may have dependencies on Tianocore/EDK2 pieces, right? So
there are no UEFI semantics in the memory descriptions that coreboot
provides to Tianocore.

So coreboot provides information to TIanocore about
- the platform topology (DT as usual)
- DRAM memory banks
- memory reservations
- secure firmware services perhaps?
- anything else?


> >
> > As i explained before, there is already prior art for this in
> > Tianocore, i.e., launching a Tianocore build based on a DT description
> > of the platform, including /memory and /reserved-memory nodes.
>
> By prior art do you mean code, or an existing binding? In either case,
> can you please point me to it? Is this a generic binding used on x86
> as well, or just for ARM?
>
> My goal here is to augment the binding.
>

No I mean code.

There is

https://github.com/tianocore/edk2/tree/master/EmbeddedPkg/Drivers/FdtClientDxe

which encapsulates the DT received from the previous boot stage, and
exposes it as a DXE protocol.

There are other drivers that depend on this protocol, e.g., to
discover additional memory nodes, virtio-mmio drivers and PCI host
bridges.

https://github.com/tianocore/edk2/tree/master/OvmfPkg/Fdt

The bindings used are the ones documented in the 

Re: [PATCH v5 3/4] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Thu, 7 Sept 2023 at 16:50, Simon Glass  wrote:
>
> Hi Ard,
>
> On Thu, 7 Sept 2023 at 08:12, Ard Biesheuvel  wrote:
> >
> > On Thu, 7 Sept 2023 at 15:56, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Thu, 7 Sept 2023 at 07:31, Ard Biesheuvel  wrote:
> > > >
> > > > On Wed, 6 Sept 2023 at 18:50, Simon Glass  wrote:
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > On Wed, Sep 6, 2023, 10:09 Ard Biesheuvel  wrote:
> > > > >>
> > > > >> On Wed, 6 Sept 2023 at 16:54, Simon Glass  wrote:
> > > > >> >
> > > > >> > Hi Rob, Ard,
> > > > >> >
> > > > >> > On Wed, 6 Sept 2023 at 08:34, Rob Herring  wrote:
> > > > >> > >
> > > > >> > > On Tue, Sep 5, 2023 at 4:44 PM Ard Biesheuvel  
> > > > >> > > wrote:
> > > > >> > > >
> > > > >> > > > On Thu, 31 Aug 2023 at 01:18, Simon Glass  
> > > > >> > > > wrote:
> > > > >> > > > >
> > > > >> > > > > The Devicetree specification skips over handling of a 
> > > > >> > > > > logical view of
> > > > >> > > > > the memory map, pointing users to the UEFI specification.
> > > > >> > > > >
> > > > >> > > > > It is common to split firmware into 'Platform Init', which 
> > > > >> > > > > does the
> > > > >> > > > > initial hardware setup and a "Payload" which selects the OS 
> > > > >> > > > > to be booted.
> > > > >> > > > > Thus an handover interface is required between these two 
> > > > >> > > > > pieces.
> > > > >> > > > >
> > > > >> > > > > Where UEFI boot-time services are not available, but UEFI 
> > > > >> > > > > firmware is
> > > > >> > > > > present on either side of this interface, information about 
> > > > >> > > > > memory usage
> > > > >> > > > > and attributes must be presented to the "Payload" in some 
> > > > >> > > > > form.
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > > I don't think the UEFI references are needed or helpful here.
> > > > >> > > >
> > > > >> > > > > This aims to provide an small schema addition for this 
> > > > >> > > > > mapping.
> > > > >> > > > >
> > > > >> > > > > For now, no attempt is made to create an exhaustive binding, 
> > > > >> > > > > so there are
> > > > >> > > > > some example types listed. More can be added later.
> > > > >> > > > >
> > > > >> > > > > The compatible string is not included, since the node name 
> > > > >> > > > > is enough to
> > > > >> > > > > indicate the purpose of a node, as per the existing 
> > > > >> > > > > reserved-memory
> > > > >> > > > > schema.
> > > > >> > >
> > > > >> > > Node names reflect the 'class', but not what's specifically in 
> > > > >> > > the
> > > > >> > > node. So really, all reserved-memory nodes should have the same 
> > > > >> > > name,
> > > > >> > > but that ship already sailed for existing users. 'compatible' is 
> > > > >> > > the
> > > > >> > > right thing here. As to what the node name should be, well, we 
> > > > >> > > haven't
> > > > >> > > defined that. I think we just used 'memory' on some platforms.
> > > > >> >
> > > > >> > OK
> > > > >> >
> > > > >> > >
> > > > >> > > > > This binding does not include a binding for the memory 
> > > > >> > > > > 'attribute'
> > > > >> &

Re: [PATCH v5 3/4] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Thu, 7 Sept 2023 at 15:56, Simon Glass  wrote:
>
> Hi Ard,
>
> On Thu, 7 Sept 2023 at 07:31, Ard Biesheuvel  wrote:
> >
> > On Wed, 6 Sept 2023 at 18:50, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Wed, Sep 6, 2023, 10:09 Ard Biesheuvel  wrote:
> > >>
> > >> On Wed, 6 Sept 2023 at 16:54, Simon Glass  wrote:
> > >> >
> > >> > Hi Rob, Ard,
> > >> >
> > >> > On Wed, 6 Sept 2023 at 08:34, Rob Herring  wrote:
> > >> > >
> > >> > > On Tue, Sep 5, 2023 at 4:44 PM Ard Biesheuvel  
> > >> > > wrote:
> > >> > > >
> > >> > > > On Thu, 31 Aug 2023 at 01:18, Simon Glass  
> > >> > > > wrote:
> > >> > > > >
> > >> > > > > The Devicetree specification skips over handling of a logical 
> > >> > > > > view of
> > >> > > > > the memory map, pointing users to the UEFI specification.
> > >> > > > >
> > >> > > > > It is common to split firmware into 'Platform Init', which does 
> > >> > > > > the
> > >> > > > > initial hardware setup and a "Payload" which selects the OS to 
> > >> > > > > be booted.
> > >> > > > > Thus an handover interface is required between these two pieces.
> > >> > > > >
> > >> > > > > Where UEFI boot-time services are not available, but UEFI 
> > >> > > > > firmware is
> > >> > > > > present on either side of this interface, information about 
> > >> > > > > memory usage
> > >> > > > > and attributes must be presented to the "Payload" in some form.
> > >> > > > >
> > >> > > >
> > >> > > > I don't think the UEFI references are needed or helpful here.
> > >> > > >
> > >> > > > > This aims to provide an small schema addition for this mapping.
> > >> > > > >
> > >> > > > > For now, no attempt is made to create an exhaustive binding, so 
> > >> > > > > there are
> > >> > > > > some example types listed. More can be added later.
> > >> > > > >
> > >> > > > > The compatible string is not included, since the node name is 
> > >> > > > > enough to
> > >> > > > > indicate the purpose of a node, as per the existing 
> > >> > > > > reserved-memory
> > >> > > > > schema.
> > >> > >
> > >> > > Node names reflect the 'class', but not what's specifically in the
> > >> > > node. So really, all reserved-memory nodes should have the same name,
> > >> > > but that ship already sailed for existing users. 'compatible' is the
> > >> > > right thing here. As to what the node name should be, well, we 
> > >> > > haven't
> > >> > > defined that. I think we just used 'memory' on some platforms.
> > >> >
> > >> > OK
> > >> >
> > >> > >
> > >> > > > > This binding does not include a binding for the memory 
> > >> > > > > 'attribute'
> > >> > > > > property, defined by EFI_BOOT_SERVICES.GetMemoryMap(). It may be 
> > >> > > > > useful
> > >> > > > > to have that as well, but perhaps not as a bit mask.
> > >> > > > >
> > >> > > > > Signed-off-by: Simon Glass 
> > >> > > > > ---
> > >> > > > >
> > >> > > > > Changes in v5:
> > >> > > > > - Drop the memory-map node (should have done that in v4)
> > >> > > > > - Tidy up schema a bit
> > >> > > > >
> > >> > > > > Changes in v4:
> > >> > > > > - Make use of the reserved-memory node instead of creating a new 
> > >> > > > > one
> > >> > > > >
> > >> > > > > Changes in v3:
> > >> > > > > - Reword commit message again
> > >> > > > > - 

Re: [PATCH v5 3/4] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Wed, 6 Sept 2023 at 18:50, Simon Glass  wrote:
>
> Hi Ard,
>
> On Wed, Sep 6, 2023, 10:09 Ard Biesheuvel  wrote:
>>
>> On Wed, 6 Sept 2023 at 16:54, Simon Glass  wrote:
>> >
>> > Hi Rob, Ard,
>> >
>> > On Wed, 6 Sept 2023 at 08:34, Rob Herring  wrote:
>> > >
>> > > On Tue, Sep 5, 2023 at 4:44 PM Ard Biesheuvel  wrote:
>> > > >
>> > > > On Thu, 31 Aug 2023 at 01:18, Simon Glass  wrote:
>> > > > >
>> > > > > The Devicetree specification skips over handling of a logical view of
>> > > > > the memory map, pointing users to the UEFI specification.
>> > > > >
>> > > > > It is common to split firmware into 'Platform Init', which does the
>> > > > > initial hardware setup and a "Payload" which selects the OS to be 
>> > > > > booted.
>> > > > > Thus an handover interface is required between these two pieces.
>> > > > >
>> > > > > Where UEFI boot-time services are not available, but UEFI firmware is
>> > > > > present on either side of this interface, information about memory 
>> > > > > usage
>> > > > > and attributes must be presented to the "Payload" in some form.
>> > > > >
>> > > >
>> > > > I don't think the UEFI references are needed or helpful here.
>> > > >
>> > > > > This aims to provide an small schema addition for this mapping.
>> > > > >
>> > > > > For now, no attempt is made to create an exhaustive binding, so 
>> > > > > there are
>> > > > > some example types listed. More can be added later.
>> > > > >
>> > > > > The compatible string is not included, since the node name is enough 
>> > > > > to
>> > > > > indicate the purpose of a node, as per the existing reserved-memory
>> > > > > schema.
>> > >
>> > > Node names reflect the 'class', but not what's specifically in the
>> > > node. So really, all reserved-memory nodes should have the same name,
>> > > but that ship already sailed for existing users. 'compatible' is the
>> > > right thing here. As to what the node name should be, well, we haven't
>> > > defined that. I think we just used 'memory' on some platforms.
>> >
>> > OK
>> >
>> > >
>> > > > > This binding does not include a binding for the memory 'attribute'
>> > > > > property, defined by EFI_BOOT_SERVICES.GetMemoryMap(). It may be 
>> > > > > useful
>> > > > > to have that as well, but perhaps not as a bit mask.
>> > > > >
>> > > > > Signed-off-by: Simon Glass 
>> > > > > ---
>> > > > >
>> > > > > Changes in v5:
>> > > > > - Drop the memory-map node (should have done that in v4)
>> > > > > - Tidy up schema a bit
>> > > > >
>> > > > > Changes in v4:
>> > > > > - Make use of the reserved-memory node instead of creating a new one
>> > > > >
>> > > > > Changes in v3:
>> > > > > - Reword commit message again
>> > > > > - cc a lot more people, from the FFI patch
>> > > > > - Split out the attributes into the /memory nodes
>> > > > >
>> > > > > Changes in v2:
>> > > > > - Reword commit message
>> > > > >
>> > > > >  .../reserved-memory/common-reserved.yaml  | 53 
>> > > > > +++
>> > > > >  1 file changed, 53 insertions(+)
>> > > > >  create mode 100644 
>> > > > > dtschema/schemas/reserved-memory/common-reserved.yaml
>> > > > >
>> > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml 
>> > > > > b/dtschema/schemas/reserved-memory/common-reserved.yaml
>> > > > > new file mode 100644
>> > > > > index 000..d1b466b
>> > > > > --- /dev/null
>> > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
>> > > > > @@ -0,0 +1,53 @@
>> > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> > >

Re: [PATCH v5 3/4] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Wed, 6 Sept 2023 at 16:54, Simon Glass  wrote:
>
> Hi Rob, Ard,
>
> On Wed, 6 Sept 2023 at 08:34, Rob Herring  wrote:
> >
> > On Tue, Sep 5, 2023 at 4:44 PM Ard Biesheuvel  wrote:
> > >
> > > On Thu, 31 Aug 2023 at 01:18, Simon Glass  wrote:
> > > >
> > > > The Devicetree specification skips over handling of a logical view of
> > > > the memory map, pointing users to the UEFI specification.
> > > >
> > > > It is common to split firmware into 'Platform Init', which does the
> > > > initial hardware setup and a "Payload" which selects the OS to be 
> > > > booted.
> > > > Thus an handover interface is required between these two pieces.
> > > >
> > > > Where UEFI boot-time services are not available, but UEFI firmware is
> > > > present on either side of this interface, information about memory usage
> > > > and attributes must be presented to the "Payload" in some form.
> > > >
> > >
> > > I don't think the UEFI references are needed or helpful here.
> > >
> > > > This aims to provide an small schema addition for this mapping.
> > > >
> > > > For now, no attempt is made to create an exhaustive binding, so there 
> > > > are
> > > > some example types listed. More can be added later.
> > > >
> > > > The compatible string is not included, since the node name is enough to
> > > > indicate the purpose of a node, as per the existing reserved-memory
> > > > schema.
> >
> > Node names reflect the 'class', but not what's specifically in the
> > node. So really, all reserved-memory nodes should have the same name,
> > but that ship already sailed for existing users. 'compatible' is the
> > right thing here. As to what the node name should be, well, we haven't
> > defined that. I think we just used 'memory' on some platforms.
>
> OK
>
> >
> > > > This binding does not include a binding for the memory 'attribute'
> > > > property, defined by EFI_BOOT_SERVICES.GetMemoryMap(). It may be useful
> > > > to have that as well, but perhaps not as a bit mask.
> > > >
> > > > Signed-off-by: Simon Glass 
> > > > ---
> > > >
> > > > Changes in v5:
> > > > - Drop the memory-map node (should have done that in v4)
> > > > - Tidy up schema a bit
> > > >
> > > > Changes in v4:
> > > > - Make use of the reserved-memory node instead of creating a new one
> > > >
> > > > Changes in v3:
> > > > - Reword commit message again
> > > > - cc a lot more people, from the FFI patch
> > > > - Split out the attributes into the /memory nodes
> > > >
> > > > Changes in v2:
> > > > - Reword commit message
> > > >
> > > >  .../reserved-memory/common-reserved.yaml  | 53 +++
> > > >  1 file changed, 53 insertions(+)
> > > >  create mode 100644 
> > > > dtschema/schemas/reserved-memory/common-reserved.yaml
> > > >
> > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml 
> > > > b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > new file mode 100644
> > > > index 000..d1b466b
> > > > --- /dev/null
> > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > @@ -0,0 +1,53 @@
> > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: 
> > > > http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Common memory reservations
> > > > +
> > > > +description: |
> > > > +  Specifies that the reserved memory region can be used for the purpose
> > > > +  indicated by its node name.
> > > > +
> > > > +  Clients may reuse this reserved memory if they understand what it is 
> > > > for.
> > > > +
> > > > +maintainers:
> > > > +  - Simon Glass 
> > > > +
> > > > +allOf:
> > > > +  - $ref: reserved-memory.yaml
> > > > +
> > > > +properties:
> > > > +  $nodename:
> > > > +enum:
> &

Re: [PATCH v5 3/4] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Thu, 31 Aug 2023 at 01:18, Simon Glass  wrote:
>
> The Devicetree specification skips over handling of a logical view of
> the memory map, pointing users to the UEFI specification.
>
> It is common to split firmware into 'Platform Init', which does the
> initial hardware setup and a "Payload" which selects the OS to be booted.
> Thus an handover interface is required between these two pieces.
>
> Where UEFI boot-time services are not available, but UEFI firmware is
> present on either side of this interface, information about memory usage
> and attributes must be presented to the "Payload" in some form.
>

I don't think the UEFI references are needed or helpful here.

> This aims to provide an small schema addition for this mapping.
>
> For now, no attempt is made to create an exhaustive binding, so there are
> some example types listed. More can be added later.
>
> The compatible string is not included, since the node name is enough to
> indicate the purpose of a node, as per the existing reserved-memory
> schema.
>
> This binding does not include a binding for the memory 'attribute'
> property, defined by EFI_BOOT_SERVICES.GetMemoryMap(). It may be useful
> to have that as well, but perhaps not as a bit mask.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v5:
> - Drop the memory-map node (should have done that in v4)
> - Tidy up schema a bit
>
> Changes in v4:
> - Make use of the reserved-memory node instead of creating a new one
>
> Changes in v3:
> - Reword commit message again
> - cc a lot more people, from the FFI patch
> - Split out the attributes into the /memory nodes
>
> Changes in v2:
> - Reword commit message
>
>  .../reserved-memory/common-reserved.yaml  | 53 +++
>  1 file changed, 53 insertions(+)
>  create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml
>
> diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml 
> b/dtschema/schemas/reserved-memory/common-reserved.yaml
> new file mode 100644
> index 000..d1b466b
> --- /dev/null
> +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common memory reservations
> +
> +description: |
> +  Specifies that the reserved memory region can be used for the purpose
> +  indicated by its node name.
> +
> +  Clients may reuse this reserved memory if they understand what it is for.
> +
> +maintainers:
> +  - Simon Glass 
> +
> +allOf:
> +  - $ref: reserved-memory.yaml
> +
> +properties:
> +  $nodename:
> +enum:
> +  - acpi-reclaim
> +  - acpi-nvs
> +  - boot-code
> +  - boot-data
> +  - runtime-code
> +  - runtime-data
> +

These types are used by firmware to describe the nature of certain
memory regions to the OS. Boot code and data can be discarded, as well
as ACPI reclaim after its contents have been consumed. Runtime code
and data need to be mapped for runtime features to work.

When one firmware phase communicates the purpose of a certain memory
reservation to another, it is typically not limited to whether its
needs to be preserved and when it needs to be mapped (and with which
attributes). I'd expect a memory reservation appearing under this node
to have a clearly defined purpose, and the subsequent phases need to
be able to discover this information.

For example, a communication buffer for secure<->non-secure
communication or a page with spin tables used by PSCI. None of the
proposed labels are appropriate for this, and I'd much rather have a
compatible string or some other property that clarifies the nature in
a more suitable way. Note that 'no-map' already exists to indicate
that the CPU should not map this memory unless it does so for the
specific purpose that the reservation was made for.


> +  reg:
> +description: region of memory that is reserved for the purpose indicated
> +  by the node name.
> +
> +required:
> +  - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +reserved-memory {
> +#address-cells = <1>;
> +#size-cells = <1>;
> +
> +boot-code@1234 {
> +reg = <0x1234 0x0080>;
> +};
> +
> +boot-data@4321 {
> +reg = <0x4321 0x0080>;
> +};
> +};
> --
> 2.42.0.rc2.253.gd59a3bf2b4-goog
>

Re: [PATCH v3 1/2] schemas: Add a schema for memory map

[Ard Biesheuvel]

On Fri, 1 Sept 2023 at 03:12, Simon Glass  wrote:
>
> Hi Ard,
>
> On Thu, 31 Aug 2023 at 16:39, Ard Biesheuvel  wrote:
> >
> > On Fri, 1 Sept 2023 at 00:17, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Thu, 31 Aug 2023 at 15:48, Ard Biesheuvel  wrote:
> > > >
> > > > On Thu, 31 Aug 2023 at 21:03, Simon Glass  wrote:
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > On Thu, 31 Aug 2023 at 06:28, Ard Biesheuvel  wrote:
> > > > > >
> > > > > > On Wed, 30 Aug 2023 at 23:11, Simon Glass  wrote:
> > > > > > >
> > > > > > > Hi Ard,
> > > > > > >
> > > > > > > On Tue, 29 Aug 2023 at 15:32, Ard Biesheuvel  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Tue, 29 Aug 2023 at 21:18, Simon Glass  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Ard,
> > > > > > > > >
> > > > > > > > > On Thu, 24 Aug 2023 at 03:10, Ard Biesheuvel 
> > > > > > > > >  wrote:
> > > > > > ...
> > > > > > > > > > In summary, I don't see why a non-UEFI payload would care 
> > > > > > > > > > about UEFI
> > > > > > > > > > semantics for pre-existing memory reservations, or vice 
> > > > > > > > > > versa. Note
> > > > > > > > > > that EDK2 will manage its own memory map, and expose it via 
> > > > > > > > > > UEFI boot
> > > > > > > > > > services and not via DT.
> > > > > > > > >
> > > > > > > > > Bear in mind that one or both sides of this interface may be 
> > > > > > > > > UEFI.
> > > > > > > > > There is no boot-services link between the two parts that I 
> > > > > > > > > have
> > > > > > > > > outlined.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don't understand what this means.
> > > > > > > >
> > > > > > > > UEFI specifies how one component invokes another, and it is not 
> > > > > > > > based
> > > > > > > > on a DT binding. If the second component calls UEFI boot or 
> > > > > > > > runtime
> > > > > > > > services, it should be invoked in this manner. If it doesn't, 
> > > > > > > > then it
> > > > > > > > doesn't care about these memory reservations (and the OS will 
> > > > > > > > not be
> > > > > > > > booted via UEFI either)
> > > > > > > >
> > > > > > > > So I feel I am missing something here. Perhaps a practical 
> > > > > > > > example
> > > > > > > > would be helpful?
> > > > > > >
> > > > > > > Let's say we want to support these combinations:
> > > > > > >
> > > > > > > Platform Init -> Payload
> > > > > > > 
> > > > > > > U-Boot -> Tianocore
> > > > > > > coreboot -> U-Boot
> > > > > > > Tianocore -> U-Boot
> > > > > > > Tianocore -> Tianocore
> > > > > > > U-Boot -> U-Boot
> > > > > > >
> > > > > > > Some of the above things have UEFI interfaces, some don't. But in 
> > > > > > > the
> > > > > > > case of Tianocore -> Tianocore we want things to work as if it 
> > > > > > > were
> > > > > > > Tianocore -> (its own handoff mechanism) Tiancore.
> > > > > > >
> > > > > >
> > > > > > If Tianocore is the payload, it is either implemented as a EFI app, 
> > > > > > in
> > > > > > which case it has access to EFI services, or it is not, in which 
> > > > > > case
> > > > > > it doesn't care about UEFI semantics of the existing reserved 
> > > > >

Re: [PATCH v3 1/2] schemas: Add a schema for memory map

[Ard Biesheuvel]

On Fri, 1 Sept 2023 at 00:17, Simon Glass  wrote:
>
> Hi Ard,
>
> On Thu, 31 Aug 2023 at 15:48, Ard Biesheuvel  wrote:
> >
> > On Thu, 31 Aug 2023 at 21:03, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Thu, 31 Aug 2023 at 06:28, Ard Biesheuvel  wrote:
> > > >
> > > > On Wed, 30 Aug 2023 at 23:11, Simon Glass  wrote:
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > On Tue, 29 Aug 2023 at 15:32, Ard Biesheuvel  wrote:
> > > > > >
> > > > > > On Tue, 29 Aug 2023 at 21:18, Simon Glass  wrote:
> > > > > > >
> > > > > > > Hi Ard,
> > > > > > >
> > > > > > > On Thu, 24 Aug 2023 at 03:10, Ard Biesheuvel  
> > > > > > > wrote:
> > > > ...
> > > > > > > > In summary, I don't see why a non-UEFI payload would care about 
> > > > > > > > UEFI
> > > > > > > > semantics for pre-existing memory reservations, or vice versa. 
> > > > > > > > Note
> > > > > > > > that EDK2 will manage its own memory map, and expose it via 
> > > > > > > > UEFI boot
> > > > > > > > services and not via DT.
> > > > > > >
> > > > > > > Bear in mind that one or both sides of this interface may be UEFI.
> > > > > > > There is no boot-services link between the two parts that I have
> > > > > > > outlined.
> > > > > > >
> > > > > >
> > > > > > I don't understand what this means.
> > > > > >
> > > > > > UEFI specifies how one component invokes another, and it is not 
> > > > > > based
> > > > > > on a DT binding. If the second component calls UEFI boot or runtime
> > > > > > services, it should be invoked in this manner. If it doesn't, then 
> > > > > > it
> > > > > > doesn't care about these memory reservations (and the OS will not be
> > > > > > booted via UEFI either)
> > > > > >
> > > > > > So I feel I am missing something here. Perhaps a practical example
> > > > > > would be helpful?
> > > > >
> > > > > Let's say we want to support these combinations:
> > > > >
> > > > > Platform Init -> Payload
> > > > > 
> > > > > U-Boot -> Tianocore
> > > > > coreboot -> U-Boot
> > > > > Tianocore -> U-Boot
> > > > > Tianocore -> Tianocore
> > > > > U-Boot -> U-Boot
> > > > >
> > > > > Some of the above things have UEFI interfaces, some don't. But in the
> > > > > case of Tianocore -> Tianocore we want things to work as if it were
> > > > > Tianocore -> (its own handoff mechanism) Tiancore.
> > > > >
> > > >
> > > > If Tianocore is the payload, it is either implemented as a EFI app, in
> > > > which case it has access to EFI services, or it is not, in which case
> > > > it doesn't care about UEFI semantics of the existing reserved regions,
> > > > and it only needs to know which regions exist and which of those are
> > > > reserved.
> > > >
> > > > And I think the same applies to all other rows in your table: either
> > > > the existence of UEFI needs to be carried forward, which needs to be
> > > > done via EFI services, or it doesn't, in which case the UEFI specific
> > > > reservations can be dropped, and only reserved and available memory is
> > > > relevant.
> > > >
> > > > > Some Platform Init may create runtime code which needs to accessible 
> > > > > later.
> > > > >
> > > >
> > > > But not UEFI runtime code, right? If the payload is not UEFI based,
> > > > the OS would never be able to call that runtime code unless it is
> > > > described in a different, non-UEFI way. This is fine, but it is not
> > > > UEFI so we shouldn't call it UEFI runtime memory.
> > > >
> > > > > The way I think of it is that we need to generalise the memory map a
> > > > > bit. Saying that you must use UEFI boot services to discover it is too
> > >

Re: [PATCH v3 1/2] schemas: Add a schema for memory map

[Ard Biesheuvel]

On Thu, 31 Aug 2023 at 21:03, Simon Glass  wrote:
>
> Hi Ard,
>
> On Thu, 31 Aug 2023 at 06:28, Ard Biesheuvel  wrote:
> >
> > On Wed, 30 Aug 2023 at 23:11, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Tue, 29 Aug 2023 at 15:32, Ard Biesheuvel  wrote:
> > > >
> > > > On Tue, 29 Aug 2023 at 21:18, Simon Glass  wrote:
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > On Thu, 24 Aug 2023 at 03:10, Ard Biesheuvel  wrote:
> > ...
> > > > > > In summary, I don't see why a non-UEFI payload would care about UEFI
> > > > > > semantics for pre-existing memory reservations, or vice versa. Note
> > > > > > that EDK2 will manage its own memory map, and expose it via UEFI 
> > > > > > boot
> > > > > > services and not via DT.
> > > > >
> > > > > Bear in mind that one or both sides of this interface may be UEFI.
> > > > > There is no boot-services link between the two parts that I have
> > > > > outlined.
> > > > >
> > > >
> > > > I don't understand what this means.
> > > >
> > > > UEFI specifies how one component invokes another, and it is not based
> > > > on a DT binding. If the second component calls UEFI boot or runtime
> > > > services, it should be invoked in this manner. If it doesn't, then it
> > > > doesn't care about these memory reservations (and the OS will not be
> > > > booted via UEFI either)
> > > >
> > > > So I feel I am missing something here. Perhaps a practical example
> > > > would be helpful?
> > >
> > > Let's say we want to support these combinations:
> > >
> > > Platform Init -> Payload
> > > 
> > > U-Boot -> Tianocore
> > > coreboot -> U-Boot
> > > Tianocore -> U-Boot
> > > Tianocore -> Tianocore
> > > U-Boot -> U-Boot
> > >
> > > Some of the above things have UEFI interfaces, some don't. But in the
> > > case of Tianocore -> Tianocore we want things to work as if it were
> > > Tianocore -> (its own handoff mechanism) Tiancore.
> > >
> >
> > If Tianocore is the payload, it is either implemented as a EFI app, in
> > which case it has access to EFI services, or it is not, in which case
> > it doesn't care about UEFI semantics of the existing reserved regions,
> > and it only needs to know which regions exist and which of those are
> > reserved.
> >
> > And I think the same applies to all other rows in your table: either
> > the existence of UEFI needs to be carried forward, which needs to be
> > done via EFI services, or it doesn't, in which case the UEFI specific
> > reservations can be dropped, and only reserved and available memory is
> > relevant.
> >
> > > Some Platform Init may create runtime code which needs to accessible 
> > > later.
> > >
> >
> > But not UEFI runtime code, right? If the payload is not UEFI based,
> > the OS would never be able to call that runtime code unless it is
> > described in a different, non-UEFI way. This is fine, but it is not
> > UEFI so we shouldn't call it UEFI runtime memory.
> >
> > > The way I think of it is that we need to generalise the memory map a
> > > bit. Saying that you must use UEFI boot services to discover it is too
> > > UEFI-specific.
> > >
> >
> > What I am questioning is why a memory map with UEFI semantics is even
> > relevant when those boot services do not exist.
> >
> > Could you be more specific about why a payload would have to be aware
> > of the existence of UEFI boot/runtime service regions if it does not
> > consume the UEFI interfaces of the platform init? And if the payload
> > exposes UEFI services to the OS, why would it consume a memory map
> > with UEFI semantics rather than a simple list of memblocks and memory
> > reservations?
>
> It seems like you are thinking of the Payload as grub, or something
> like that? This is not about grub. If there are EFI boot services to
> be provided, they are provided by the Payload, not Platform Init. I am
> not that familiar with Tianocore, but if you are, perhaps think of it
> as splitting Tianocore into two pieces, one of which inits the silicon
> and the other which provides the EFI boot services.
>
> Again, if you are familiar with Tianocore, it ca

Re: [PATCH v3 1/2] schemas: Add a schema for memory map

[Ard Biesheuvel]

On Wed, 30 Aug 2023 at 23:11, Simon Glass  wrote:
>
> Hi Ard,
>
> On Tue, 29 Aug 2023 at 15:32, Ard Biesheuvel  wrote:
> >
> > On Tue, 29 Aug 2023 at 21:18, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Thu, 24 Aug 2023 at 03:10, Ard Biesheuvel  wrote:
...
> > > > In summary, I don't see why a non-UEFI payload would care about UEFI
> > > > semantics for pre-existing memory reservations, or vice versa. Note
> > > > that EDK2 will manage its own memory map, and expose it via UEFI boot
> > > > services and not via DT.
> > >
> > > Bear in mind that one or both sides of this interface may be UEFI.
> > > There is no boot-services link between the two parts that I have
> > > outlined.
> > >
> >
> > I don't understand what this means.
> >
> > UEFI specifies how one component invokes another, and it is not based
> > on a DT binding. If the second component calls UEFI boot or runtime
> > services, it should be invoked in this manner. If it doesn't, then it
> > doesn't care about these memory reservations (and the OS will not be
> > booted via UEFI either)
> >
> > So I feel I am missing something here. Perhaps a practical example
> > would be helpful?
>
> Let's say we want to support these combinations:
>
> Platform Init -> Payload
> 
> U-Boot -> Tianocore
> coreboot -> U-Boot
> Tianocore -> U-Boot
> Tianocore -> Tianocore
> U-Boot -> U-Boot
>
> Some of the above things have UEFI interfaces, some don't. But in the
> case of Tianocore -> Tianocore we want things to work as if it were
> Tianocore -> (its own handoff mechanism) Tiancore.
>

If Tianocore is the payload, it is either implemented as a EFI app, in
which case it has access to EFI services, or it is not, in which case
it doesn't care about UEFI semantics of the existing reserved regions,
and it only needs to know which regions exist and which of those are
reserved.

And I think the same applies to all other rows in your table: either
the existence of UEFI needs to be carried forward, which needs to be
done via EFI services, or it doesn't, in which case the UEFI specific
reservations can be dropped, and only reserved and available memory is
relevant.

> Some Platform Init may create runtime code which needs to accessible later.
>

But not UEFI runtime code, right? If the payload is not UEFI based,
the OS would never be able to call that runtime code unless it is
described in a different, non-UEFI way. This is fine, but it is not
UEFI so we shouldn't call it UEFI runtime memory.

> The way I think of it is that we need to generalise the memory map a
> bit. Saying that you must use UEFI boot services to discover it is too
> UEFI-specific.
>

What I am questioning is why a memory map with UEFI semantics is even
relevant when those boot services do not exist.

Could you be more specific about why a payload would have to be aware
of the existence of UEFI boot/runtime service regions if it does not
consume the UEFI interfaces of the platform init? And if the payload
exposes UEFI services to the OS, why would it consume a memory map
with UEFI semantics rather than a simple list of memblocks and memory
reservations?

Again, I am inclined to treat this as a firmware implementation
detail, and the OS must never consume this binding. But I am still
puzzled about what exact purpose it is expected to serve.

Re: [PATCH v3 1/2] schemas: Add a schema for memory map

[Ard Biesheuvel]

On Tue, 29 Aug 2023 at 21:18, Simon Glass  wrote:
>
> Hi Ard,
>
> On Thu, 24 Aug 2023 at 03:10, Ard Biesheuvel  wrote:
> >
> > On Wed, 23 Aug 2023 at 22:04, Simon Glass  wrote:
> > >
> > > Hi,
> > >
> > > On Wed, 23 Aug 2023 at 08:24, Ard Biesheuvel  wrote:
> > > >
> > > > On Wed, 23 Aug 2023 at 10:59, Mark Rutland  wrote:
> > > > >
> > > > > On Tue, Aug 22, 2023 at 02:34:42PM -0600, Simon Glass wrote:
> > > > > > The Devicetree specification skips over handling of a logical view 
> > > > > > of
> > > > > > the memory map, pointing users to the UEFI specification.
> > > > > >
> > > > > > It is common to split firmware into 'Platform Init', which does the
> > > > > > initial hardware setup and a "Payload" which selects the OS to be 
> > > > > > booted.
> > > > > > Thus an handover interface is required between these two pieces.
> > > > > >
> > > > > > Where UEFI boot-time services are not available, but UEFI firmware 
> > > > > > is
> > > > > > present on either side of this interface, information about memory 
> > > > > > usage
> > > > > > and attributes must be presented to the "Payload" in some form.
> > > >
> > > > Not quite.
> > > >
> > > > This seems to be intended for consumption by Linux booting in ACPI
> > > > mode, but not via UEFI, right?
> > >
> > > Actually, this is for consumption by firmware. The goal is to allow
> > > edk2 to boot into U-Boot and vice versa, i.e. provide some
> > > interoperability between firmware projects. I will use the "Platform
> > > Init" and "Payload" terminology here too.
> > >
> >
> > OK. It was the cc to linux-acpi@ and the authors of the
> > ACPI/SMBIOS-without-UEFI patches that threw me off here.
> >
> > If we are talking about an internal interface for firmware components,
> > I'd be inclined to treat this as an implementation detail, as long as
> > the OS is not expected to consume these DT nodes.
> >
> > However, I struggle to see the point of framing this information as a
> > 'UEFI memory map'. Neither EDK2 nor u-boot consume this information
> > natively, and there is already prior art in both projects to consume
> > nodes following the existing bindings for device_type=memory and the
> > /reserved-memory node. UEFI runtime memory is generally useless
> > without UEFI runtime services, and UEFI boot services memory is just
> > free memory.
> >
> > There is also an overlap with the handover between secure and
> > non-secure firmware on arm64, which is also DT based, and communicates
> > available memory as well as RAM regions that are reserved for firmware
> > use.
> >
> > In summary, I don't see why a non-UEFI payload would care about UEFI
> > semantics for pre-existing memory reservations, or vice versa. Note
> > that EDK2 will manage its own memory map, and expose it via UEFI boot
> > services and not via DT.
>
> Bear in mind that one or both sides of this interface may be UEFI.
> There is no boot-services link between the two parts that I have
> outlined.
>

I don't understand what this means.

UEFI specifies how one component invokes another, and it is not based
on a DT binding. If the second component calls UEFI boot or runtime
services, it should be invoked in this manner. If it doesn't, then it
doesn't care about these memory reservations (and the OS will not be
booted via UEFI either)

So I feel I am missing something here. Perhaps a practical example
would be helpful?


> >
> > ...
> > >
> > > There is no intent to implement the UEFI spec, here. It is simply that
> > > some payloads (EDK2) are used to having this information.
> > >
> > > Imagine splitting EDK2 into two parts, one of which does platform init
> > > and the other which (the payload) boots the OS. The payload wants
> > > information from Platform Init and it needs to be in a devicetree,
> > > since that is what we have chosen for this interface. So to some
> > > extent this is unrelated to whether you have EFI boot services. We
> > > just need to be able to pass the information across the interface.
> > > Note that the user can (without recompilation, etc.) replace the
> > > second part with U-Boot (for example) and it must still work.
> > 

Re: [PATCH v3 1/2] schemas: Add a schema for memory map

[Ard Biesheuvel]

On Wed, 23 Aug 2023 at 22:04, Simon Glass  wrote:
>
> Hi,
>
> On Wed, 23 Aug 2023 at 08:24, Ard Biesheuvel  wrote:
> >
> > On Wed, 23 Aug 2023 at 10:59, Mark Rutland  wrote:
> > >
> > > On Tue, Aug 22, 2023 at 02:34:42PM -0600, Simon Glass wrote:
> > > > The Devicetree specification skips over handling of a logical view of
> > > > the memory map, pointing users to the UEFI specification.
> > > >
> > > > It is common to split firmware into 'Platform Init', which does the
> > > > initial hardware setup and a "Payload" which selects the OS to be 
> > > > booted.
> > > > Thus an handover interface is required between these two pieces.
> > > >
> > > > Where UEFI boot-time services are not available, but UEFI firmware is
> > > > present on either side of this interface, information about memory usage
> > > > and attributes must be presented to the "Payload" in some form.
> >
> > Not quite.
> >
> > This seems to be intended for consumption by Linux booting in ACPI
> > mode, but not via UEFI, right?
>
> Actually, this is for consumption by firmware. The goal is to allow
> edk2 to boot into U-Boot and vice versa, i.e. provide some
> interoperability between firmware projects. I will use the "Platform
> Init" and "Payload" terminology here too.
>

OK. It was the cc to linux-acpi@ and the authors of the
ACPI/SMBIOS-without-UEFI patches that threw me off here.

If we are talking about an internal interface for firmware components,
I'd be inclined to treat this as an implementation detail, as long as
the OS is not expected to consume these DT nodes.

However, I struggle to see the point of framing this information as a
'UEFI memory map'. Neither EDK2 nor u-boot consume this information
natively, and there is already prior art in both projects to consume
nodes following the existing bindings for device_type=memory and the
/reserved-memory node. UEFI runtime memory is generally useless
without UEFI runtime services, and UEFI boot services memory is just
free memory.

There is also an overlap with the handover between secure and
non-secure firmware on arm64, which is also DT based, and communicates
available memory as well as RAM regions that are reserved for firmware
use.

In summary, I don't see why a non-UEFI payload would care about UEFI
semantics for pre-existing memory reservations, or vice versa. Note
that EDK2 will manage its own memory map, and expose it via UEFI boot
services and not via DT.

...
>
> There is no intent to implement the UEFI spec, here. It is simply that
> some payloads (EDK2) are used to having this information.
>
> Imagine splitting EDK2 into two parts, one of which does platform init
> and the other which (the payload) boots the OS. The payload wants
> information from Platform Init and it needs to be in a devicetree,
> since that is what we have chosen for this interface. So to some
> extent this is unrelated to whether you have EFI boot services. We
> just need to be able to pass the information across the interface.
> Note that the user can (without recompilation, etc.) replace the
> second part with U-Boot (for example) and it must still work.
>

OK, so device tree makes sense for this. This is how I implemented the
EDK2 port that targets QEMU/mach-virt - it consumes the DT to discover
the UART, RTC,, memory, PCI host bridge, etc.

But I don't see a use case for a UEFI memory map here.


> >
> > >
> > > Today Linux does that by passing:
> > >
> > >   /chosen/linux,uefi-mmap-start
> > >   /chosen/linux,uefi-mmap-size
> > >   /chosen/linux,uefi-mmap-desc-size
> > >   /chosen/linux,uefi-mmap-desc-ver
> > >
> > > ... or /chosen/xen,* variants of those.
> > >
> > > Can't we document / genericise that?
>
> That seems to me to be the fields from the EFI memory-map call, but
> where is the actual content? I looked in the kernel but it seems to be
> an internal interface (between the stub and the kernel)?
>
> > >
> >
> > Given the ACPI angle, promoting this to external ABI would introduce a
> > DT dependency to ACPI boot. So we'll at least have to be very clear
> > about which takes precedence, or maybe disregard everything except the
> > /chosen node when doing ACPI boot?
> >
> > This also argues for not creating an ordinary binding for this (i.e.,
> > describing it as part of the platform topology), but putting it under
> > /chosen as a Linux-only boot tweak.
> >
> > > Pointing to that rather than re-encoding it in DT means that it stays 
> > > in-s

Re: [PATCH v3 1/2] schemas: Add a schema for memory map

[Ard Biesheuvel]

On Wed, 23 Aug 2023 at 10:59, Mark Rutland  wrote:
>
> On Tue, Aug 22, 2023 at 02:34:42PM -0600, Simon Glass wrote:
> > The Devicetree specification skips over handling of a logical view of
> > the memory map, pointing users to the UEFI specification.
> >
> > It is common to split firmware into 'Platform Init', which does the
> > initial hardware setup and a "Payload" which selects the OS to be booted.
> > Thus an handover interface is required between these two pieces.
> >
> > Where UEFI boot-time services are not available, but UEFI firmware is
> > present on either side of this interface, information about memory usage
> > and attributes must be presented to the "Payload" in some form.

Not quite.

This seems to be intended for consumption by Linux booting in ACPI
mode, but not via UEFI, right? Some proposed changes to support that
were rejected on the basis that ACPI on non-x86 is strictly tied to
ACPI boot, not only because the ACPI root table (rsdp) can only be
discovered via UEFI, but also because the ACPI subsystem in Linux
cross-references any memory mappings created from AML code against the
UEFI memory map.

Unfortunately, having a vague, non-exhaustive approximation of the
UEFI memory map is unlikely to be sufficient here. The existing logic
assumes that addresses not covered by the UEFI memory map are MMIO,
which means that either a) the UEFI memory map needs to describe all
RAM exhaustively or b) the existing logic needs to be modified to take
memblock or other information sources into account as well in order to
reason about whether a certain address requires device or normal
memory attributes.

Note that the ACPI spec only lists EFI as a valid way to obtain the
root table pointer on architectures other than x86. If other ways are
needed, they should be contributed to the spec, rather than being
added to Linux as an ad hoc workaround for bootloaders that have
trouble implementing the spec as is.

>
> Today Linux does that by passing:
>
>   /chosen/linux,uefi-mmap-start
>   /chosen/linux,uefi-mmap-size
>   /chosen/linux,uefi-mmap-desc-size
>   /chosen/linux,uefi-mmap-desc-ver
>
> ... or /chosen/xen,* variants of those.
>
> Can't we document / genericise that?
>

Given the ACPI angle, promoting this to external ABI would introduce a
DT dependency to ACPI boot. So we'll at least have to be very clear
about which takes precedence, or maybe disregard everything except the
/chosen node when doing ACPI boot?

This also argues for not creating an ordinary binding for this (i.e.,
describing it as part of the platform topology), but putting it under
/chosen as a Linux-only boot tweak.

> Pointing to that rather than re-encoding it in DT means that it stays in-sync
> with the EFI spec and we won't back ourselves into a corner where we cannot
> encode something due to a structural difference. I don't think it's a good 
> idea
> to try to re-encode it, or we're just setting ourselves up for futher pain.
>

What I would prefer is to formalize pseudo-EFI boot and define the
bare required minimum (system table + memory map + config tables) in
an arch-agnostic manner. That way, the only thing that needs to be
passed via DT/boot_params/etc is the (pseudo-)EFI system table
address, and everything else (SMBIOS, ACPI as well as the EFI memory
map and even the initrd) can be passed via config tables as usual, all
of which is already supported in (mostly) generic kernel code.

This means that booting via the EFI stub would not be required, nor is
implementing boot services or runtime services or any of the other
things that people appear to hate with such a passion.

I'd actually prefer not to use those /chosen DT nodes, but pass the
memory map via a config table. This, however, requires* that the
runtime services memory regions are mapped 1:1 so it is not something
we can do for all currently supported systems. But for pseudo-EFI
boot, stipulating 1:1 runtime mappings is fine (or no runtime mappings
at all if the firmware does not expose runtime services)

* SetVirtualAddressMap() relocates the config table array, and without
a memory map, it is not possible to convert those address back to
physical. SetVirtualAddressMap() is evil and needs to die, but this is
off-topic for the thread at hand.

> >
> > This aims to provide an initial schema for this mapping.
> >
> > Note that this is separate from the existing /memory and /reserved-memory
> > nodes, since it is mostly concerned with what the memory is used for. It
> > may cover only a small fraction of available memory.
> >
> > For now, no attempt is made to create an exhaustive binding, so there are
> > some example types listed. This can be completed once this has passed
> > initial review.
> >
> > This binding does not include a binding for the memory 'attribute'
> > property, defined by EFI_BOOT_SERVICES.GetMemoryMap(). It may be useful
> > to have that as well, but perhaps not as a bit mask.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v3:

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.

Re: [PATCH] efi_loader: Get rid of kaslr-seed

[Ard Biesheuvel]

On Thu, 16 Dec 2021 at 18:55, Mark Kettenis  wrote:
>
> > From: Ard Biesheuvel 
> > Date: Thu, 16 Dec 2021 18:12:02 +0100
> >
> > On Thu, 16 Dec 2021 at 17:56, Mark Kettenis  wrote:
> > >
> > > > From: Ard Biesheuvel 
> > > > Date: Thu, 16 Dec 2021 15:54:55 +0100
> > >
> > > Hi Ard, Ilias,
> > >
> > > > On Thu, 16 Dec 2021 at 15:52, Ilias Apalodimas
> > > >  wrote:
> > > > >
> > > > > Right now we unconditionally pass a 'kaslr-seed' property to the 
> > > > > kernel
> > > > > if the DTB we ended up in EFI includes the entry.  However the kernel
> > > > > EFI stub completely ignores it and only relies on EFI_RNG_PROTOCOL.
> > > > > So let's get rid of it unconditionally since it would mess up the
> > > > > (upcoming) DTB TPM measuring as well.
> > > > >
> > > > > Signed-off-by: Ilias Apalodimas 
> > > >
> > > > Acked-by: Ard Biesheuvel 
> > > >
> > > > Note that the EFI stub itself does not consume the DTB /chosen entry
> > > > for its own randomness needs (i.e., the randomization of the physical
> > > > placement of the kernel, which also affects low order virtual
> > > > placement [bits 16-20]), and will blindly overwrite the seed with
> > > > whatever the EFI_RNG_PROTOCOL returns.
> > >
> > > But it will only do that if EFI_RNG_PROTOCOL is implemented and
> > > sucessfully returns some random data.  Otherwise "kaslr-seed" will
> > > survive as-is.  At least that is how I read the code in
> > > drivers/firmware/efi/libstub/fdt.c:update_fdt().
> > >
> > > And this is good.  On Apple M1 systems, the Apple bootloader actually
> > > provides a block of entropy the the kernel in their version of the
> > > device tree.  The m1n1 bootloader uses this entropy to populate the
> > > kaslr-seed property in the device tree it passes on.  And U-Boot is
> > > used to provide an EFI implementation such that we can boot a wide
> > > variety of OSes.  At this point we don't know yet whether the SoC
> > > includes an RNG that we can use to implement EFI_RNG_PROTOCOL in
> > > U-Boot.
> > >
> >
> > Wouldn't it be better to use this block of entropy to seed a DRBG and
> > subsequently use that as a source of random numbers?
>
> Hmm, I didn't consider that as an option.  We actually get 512 bits of
> entropy from m1n1, which should be good enough to seed a DRBG isn't
> it?  Not really my area of expertise though.  So I'll need some help
> here.
>

Yes, all the DRBGs defined by NIST SP800-90A take a seed in the order
of 300 - 500 bits IIRC.

On an arm64 system that implements the crypto extensions, stringing
together a couple of AES instructions to implement the AES-CTR of
flavor of DRBG should be rather straight-forward, and tiny in terms of
code size.

Of course, reusing an existing implementation would be even better but
I don't know from the top of my head if anything suitable exists under
an appropriate license that we can just drop in.

Re: [PATCH] efi_loader: Get rid of kaslr-seed

[Ard Biesheuvel]

On Thu, 16 Dec 2021 at 17:56, Mark Kettenis  wrote:
>
> > From: Ard Biesheuvel 
> > Date: Thu, 16 Dec 2021 15:54:55 +0100
>
> Hi Ard, Ilias,
>
> > On Thu, 16 Dec 2021 at 15:52, Ilias Apalodimas
> >  wrote:
> > >
> > > Right now we unconditionally pass a 'kaslr-seed' property to the kernel
> > > if the DTB we ended up in EFI includes the entry.  However the kernel
> > > EFI stub completely ignores it and only relies on EFI_RNG_PROTOCOL.
> > > So let's get rid of it unconditionally since it would mess up the
> > > (upcoming) DTB TPM measuring as well.
> > >
> > > Signed-off-by: Ilias Apalodimas 
> >
> > Acked-by: Ard Biesheuvel 
> >
> > Note that the EFI stub itself does not consume the DTB /chosen entry
> > for its own randomness needs (i.e., the randomization of the physical
> > placement of the kernel, which also affects low order virtual
> > placement [bits 16-20]), and will blindly overwrite the seed with
> > whatever the EFI_RNG_PROTOCOL returns.
>
> But it will only do that if EFI_RNG_PROTOCOL is implemented and
> sucessfully returns some random data.  Otherwise "kaslr-seed" will
> survive as-is.  At least that is how I read the code in
> drivers/firmware/efi/libstub/fdt.c:update_fdt().
>
> And this is good.  On Apple M1 systems, the Apple bootloader actually
> provides a block of entropy the the kernel in their version of the
> device tree.  The m1n1 bootloader uses this entropy to populate the
> kaslr-seed property in the device tree it passes on.  And U-Boot is
> used to provide an EFI implementation such that we can boot a wide
> variety of OSes.  At this point we don't know yet whether the SoC
> includes an RNG that we can use to implement EFI_RNG_PROTOCOL in
> U-Boot.
>

Wouldn't it be better to use this block of entropy to seed a DRBG and
subsequently use that as a source of random numbers?

> So the effect of tis change is that a Linux kernel on this platform
> will run without KASLR.  That doesn't seem acceptable to me.
>

I agree that this kind of regression should be avoided. But the
reality is that /chosen/kaslr-seed is Linux internal ABI (EFI
stub<->kernel) that somehow got promoted to boot protocol, in a way
that doesn't even work correctly with the EFI stub itself, since
nobody ever proposed a way to *consume* this kaslr-seed in a way that
permits the EFI stub itself to perform load address randomization when
EFI_RNG_PROTOCOL is absent. Note that randomization of the physical
placement is important not only for physical KASLR but also for
virtual KASLR in Linux. (The virtual placement modulo 2 MiB is decided
by the physical placement directly)

So in my opinion, this is a blatant layering violation, and EFI boot
should be fixed, by implementing EFI_RNG_PROTOCOL in all cases where
u-boot apparently has a source of entropy, as it is able to populate
the kaslr-seed property.

For non-EFI boot, the situation is obviously different, and it's
perfectly fine to use /chosen/kaslr-seed directly for the the parts of
KASLR that can still be used in this case.



> > > ---
> > >  cmd/bootefi.c |  2 ++
> > >  include/efi_loader.h  |  2 ++
> > >  lib/efi_loader/efi_dt_fixup.c | 22 ++
> > >  3 files changed, 26 insertions(+)
> > >
> > > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > > index d77d3b6e943d..25f9bfce9b84 100644
> > > --- a/cmd/bootefi.c
> > > +++ b/cmd/bootefi.c
> > > @@ -310,6 +310,8 @@ efi_status_t efi_install_fdt(void *fdt)
> > > /* Create memory reservations as indicated by the device tree */
> > > efi_carve_out_dt_rsv(fdt);
> > >
> > > +   efi_purge_kaslr_seed(fdt);
> > > +
> > > /* Install device tree as UEFI table */
> > > ret = efi_install_configuration_table(&efi_guid_fdt, fdt);
> > > if (ret != EFI_SUCCESS) {
> > > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > > index 9dd6c2033634..e560401ac54f 100644
> > > --- a/include/efi_loader.h
> > > +++ b/include/efi_loader.h
> > > @@ -519,6 +519,8 @@ efi_status_t EFIAPI efi_convert_pointer(efi_uintn_t 
> > > debug_disposition,
> > > void **address);
> > >  /* Carve out DT reserved memory ranges */
> > >  void efi_carve_out_dt_rsv(void *fdt);
> > > +/* Purge unused kaslr-seed */
> > > +void efi_purge_kaslr_seed(void *fdt);
> > >  /* Called by bootefi to make console interface available */
> > >  efi_status_t efi_console_register(void);
> > 

Re: [PATCH] efi_loader: Get rid of kaslr-seed

[Ard Biesheuvel]

On Thu, 16 Dec 2021 at 16:25, Mark Kettenis  wrote:
>
> > From: Ilias Apalodimas 
> > Date: Thu, 16 Dec 2021 16:52:08 +0200
> >
> > Right now we unconditionally pass a 'kaslr-seed' property to the kernel
> > if the DTB we ended up in EFI includes the entry.  However the kernel
> > EFI stub completely ignores it and only relies on EFI_RNG_PROTOCOL.
> > So let's get rid of it unconditionally since it would mess up the
> > (upcoming) DTB TPM measuring as well.
>
> NAK
>
> OpenBSD uses the kaslr-seed property in the bootloader to mix in some
> additional entropy.  (It will also use EFI_RNG_PROTOCOL if it is
> avilable, but most U-Boot boards don't provide that, or at least not
> yet).
>

What is the point of using both the DT property and the protocol if
both are available?

> Even on Linux the EFI stub isn't the only way to load a Linux kernel.
> You can use a conventional EFI bootloader like grub.
>

No, you cannot, at least not on architectures other than x86. GRUB on
ARM always boots via the EFI stub.

Re: [PATCH] efi_loader: Get rid of kaslr-seed

[Ard Biesheuvel]

On Thu, 16 Dec 2021 at 15:52, Ilias Apalodimas
 wrote:
>
> Right now we unconditionally pass a 'kaslr-seed' property to the kernel
> if the DTB we ended up in EFI includes the entry.  However the kernel
> EFI stub completely ignores it and only relies on EFI_RNG_PROTOCOL.
> So let's get rid of it unconditionally since it would mess up the
> (upcoming) DTB TPM measuring as well.
>
> Signed-off-by: Ilias Apalodimas 

Acked-by: Ard Biesheuvel 

Note that the EFI stub itself does not consume the DTB /chosen entry
for its own randomness needs (i.e., the randomization of the physical
placement of the kernel, which also affects low order virtual
placement [bits 16-20]), and will blindly overwrite the seed with
whatever the EFI_RNG_PROTOCOL returns.


> ---
>  cmd/bootefi.c |  2 ++
>  include/efi_loader.h  |  2 ++
>  lib/efi_loader/efi_dt_fixup.c | 22 ++
>  3 files changed, 26 insertions(+)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index d77d3b6e943d..25f9bfce9b84 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -310,6 +310,8 @@ efi_status_t efi_install_fdt(void *fdt)
> /* Create memory reservations as indicated by the device tree */
> efi_carve_out_dt_rsv(fdt);
>
> +   efi_purge_kaslr_seed(fdt);
> +
> /* Install device tree as UEFI table */
> ret = efi_install_configuration_table(&efi_guid_fdt, fdt);
> if (ret != EFI_SUCCESS) {
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 9dd6c2033634..e560401ac54f 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -519,6 +519,8 @@ efi_status_t EFIAPI efi_convert_pointer(efi_uintn_t 
> debug_disposition,
> void **address);
>  /* Carve out DT reserved memory ranges */
>  void efi_carve_out_dt_rsv(void *fdt);
> +/* Purge unused kaslr-seed */
> +void efi_purge_kaslr_seed(void *fdt);
>  /* Called by bootefi to make console interface available */
>  efi_status_t efi_console_register(void);
>  /* Called by bootefi to make all disk storage accessible as EFI objects */
> diff --git a/lib/efi_loader/efi_dt_fixup.c b/lib/efi_loader/efi_dt_fixup.c
> index b6fe5d2e5a34..02f7de73872e 100644
> --- a/lib/efi_loader/efi_dt_fixup.c
> +++ b/lib/efi_loader/efi_dt_fixup.c
> @@ -40,6 +40,28 @@ static void efi_reserve_memory(u64 addr, u64 size, bool 
> nomap)
> addr, size);
>  }
>
> +/**
> + * efi_remove_kaslr_seed() - Removed unused kaslr-seed
> + *
> + * Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for randomization
> + * and completely ignores the kaslr-seed.  Weed it out from the DTB we
> + * hand over, which would mess up our DTB TPM measurements as well.
> + *
> + * @fdt: Pointer to device tree
> + */
> +void efi_purge_kaslr_seed(void *fdt)
> +{
> +   int nodeoff = fdt_path_offset(fdt, "/chosen");
> +   int err = 0;
> +
> +   if (nodeoff < 0)
> +   return;
> +
> +   err = fdt_delprop(fdt, nodeoff, "kaslr-seed");
> +   if (err < 0)
> +   log_err("Error deleting kaslr-seed\n");
> +}
> +
>  /**
>   * efi_carve_out_dt_rsv() - Carve out DT reserved memory ranges
>   *
> --
> 2.30.2
>

Re: [PATCH] efi_loader: Fix loaded image alignment

[Ard Biesheuvel]

On Mon, 11 Oct 2021 at 15:51, Ilias Apalodimas
 wrote:
>
> Hi Heinrich,
>
> On Mon, 11 Oct 2021 at 16:45, Heinrich Schuchardt
>  wrote:
> >
> >
> >
> > On 10/11/21 14:10, Ilias Apalodimas wrote:
> > > We are ignoring the alignment communicated via the PE/COFF header.
> > > Starting 5.10 the Linux kernel will loudly complain about it. For more
> > > details look at [1] (in linux kernel).
> > >
> > > So add a function that can allocate aligned EFI memory and use it for our
> > > relocated loaded image.
> > >
> > > [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at 
> > > entry")
> > >
> > > Signed-off-by: Ilias Apalodimas 
> > > ---
>
> [...]
>
> > > + */
> > > +void *efi_alloc_aligned_pages(u64 len, int memory_type, size_t align)
> > > +{
> > > + u64 req_pages = efi_size_in_pages(len);
> > > + u64 true_pages = req_pages + efi_size_in_pages(align) - 1;
> > > + u64 free_pages = 0;
> >
> > The assigned value is never used. Please, remove the assignment.
> >
> > > + u64 aligned_mem;
> > > + efi_status_t r;
> > > + u64 mem;
> > > +
> >
> > Please add a comment:
> >
> > /* Align must be a power of two */
> >
> > I can apply these changes when merging.
>
> Ok the changes seem fine to me.   Wait a few days in case Ard sees
> this, so he can verify the changes are what the kernel expects.
>

Should be fine if it results in the correct alignment, and makes the
error message go away.

Acked-by: Ard Biesheuvel 

Re: Fwd: Re: [PATCH] efi_loader: Omit memory with "no-map" when returning memory map.

[Ard Biesheuvel]

On Thu, 2 Sept 2021 at 10:43, Kristian Amlie
 wrote:
>
> On 31/08/2021 13:12, Kristian Amlie wrote:
> > On 31/08/2021 12:46, Heinrich Schuchardt wrote:
> >>
> >>
> >> --------
> >> *Von:* Ard Biesheuvel 
> >> *Gesendet:* 31. August 2021 12:33:56 MESZ
> >> *An:* Heinrich Schuchardt 
> >> *CC:* Kristian Amlie 
> >> *Betreff:* Re: [PATCH] efi_loader: Omit memory with "no-map" when
> >> returning memory map.
> >>
> >> On Tue, 31 Aug 2021 at 08:41, Heinrich Schuchardt  
> >> wrote:
> >>
> >>
> >> On 8/27/21 9:55 AM, Kristian Amlie wrote:
> >>
> >> You can use scripts/get_maintainer.pl to find the right addressees for
> >> your patches.
> >>
> >> efi_reserve_memory() states that memory marked with "no-map"
> >> shall not
> >> be accessed by the UEFI payload. Make sure efi_get_memory_map()
> >> honors
> >> this.
> >>
> >>
> >> Accessing memory and describing memory are two different things.
> >> Describing reserved memory in the memory map is important, because it
> >> helps us distinguish it from MMIO regions.
> >
> > Ok, my mistake, I thought the kernel would deduce this separately
> > through the DTB.
> >
> >>
> >> This helps the case when booting vexpress_ca9x4 under QEMU. Because
> >> the kernel wants to use an address in the lowest 128MiB of the
> >> range,
> >> but this range is reserved with "no-map", the kernel complains
> >> that it
> >> can not allocate the low memory it needs. In reality the actual
> >> usable
> >> memory starts much higher, which is reflected correctly in the
> >> memory
> >> map after this fix.
> >>
> >>
> >>
> >> This is a u-boot patch right? (I cannot tell from the context, as
> >> there are no mailing lists on cc)
> >>
> >> It is u-boot's job to describe all the memory, no matter how it is
> >> used. Even if the kernel itself may not use it as system memory, there
> >> are cases where kernel infrastructure is used to map these regions:
> >> for instance, the ACPI core may need to map a SystemMemory OpRegion,
> >> and we need the EFI memory map to tell us whether to use memory or I/O
> >> semantics.
> >>
> >> As for the 128 MB issue: can you reproduce this with a recent kernel?
> >> We made some changes recently to the EFI stub as well as the
> >> decompressor code to prevent the decompressor code from relocating
> >> itself to the base of DRAM, and to allow the decompressed kernel to
> >> reside at any 2 MB aligned offset in memory.
> >
> > I'll try this and get back to you!
>
> The result have been a bit inconclusive. I *think* it works, but the
> system later crashes because init is killed. Which may be a problem with
> that kernel in general, I don't know. I would require more time to
> figure out exactly what's causing it. The early boot and all the memory
> initialization seems to work just fine though.
>
> I have pasted the log below if you want to look at it, but to me the
> error looks unrelated.
>

Agreed. systemd-init crashes for some reason, but this is highly
unlikely to be caused by the EFI memory map containing reserved memory
regions.

-- 
Ard.

Re: Fwd: Re: [PATCH] efi_loader: Omit memory with "no-map" when returning memory map.

[Ard Biesheuvel]

On Tue, 31 Aug 2021 at 18:59, Heinrich Schuchardt  wrote:
>
>
>
> On 8/31/21 1:12 PM, Kristian Amlie wrote:
> > On 31/08/2021 12:46, Heinrich Schuchardt wrote:
> >>
> >>
> >> --------
> >> *Von:* Ard Biesheuvel 
> >> *Gesendet:* 31. August 2021 12:33:56 MESZ
> >> *An:* Heinrich Schuchardt 
> >> *CC:* Kristian Amlie 
> >> *Betreff:* Re: [PATCH] efi_loader: Omit memory with "no-map" when
> >> returning memory map.
> >>
> >> On Tue, 31 Aug 2021 at 08:41, Heinrich Schuchardt  
> >> wrote:
> >>
> >>
> >>  On 8/27/21 9:55 AM, Kristian Amlie wrote:
> >>
> >>  You can use scripts/get_maintainer.pl to find the right addressees for
> >>  your patches.
> >>
> >>  efi_reserve_memory() states that memory marked with "no-map"
> >>  shall not
> >>  be accessed by the UEFI payload. Make sure efi_get_memory_map()
> >>  honors
> >>  this.
> >>
> >>
> >> Accessing memory and describing memory are two different things.
> >> Describing reserved memory in the memory map is important, because it
> >> helps us distinguish it from MMIO regions.
> >
> > Ok, my mistake, I thought the kernel would deduce this separately
> > through the DTB.
> >
> >>
> >>  This helps the case when booting vexpress_ca9x4 under QEMU. 
> >> Because
> >>  the kernel wants to use an address in the lowest 128MiB of the
> >>  range,
> >>  but this range is reserved with "no-map", the kernel complains
> >>  that it
> >>  can not allocate the low memory it needs. In reality the actual
> >>  usable
> >>  memory starts much higher, which is reflected correctly in the
> >>  memory
> >>  map after this fix.
> >>
> >>
> >>
> >> This is a u-boot patch right? (I cannot tell from the context, as
> >> there are no mailing lists on cc)
> >>
> >> It is u-boot's job to describe all the memory, no matter how it is
> >> used. Even if the kernel itself may not use it as system memory, there
> >> are cases where kernel infrastructure is used to map these regions:
> >> for instance, the ACPI core may need to map a SystemMemory OpRegion,
> >> and we need the EFI memory map to tell us whether to use memory or I/O
> >> semantics.
> >>
> >> As for the 128 MB issue: can you reproduce this with a recent kernel?
> >> We made some changes recently to the EFI stub as well as the
> >> decompressor code to prevent the decompressor code from relocating
> >> itself to the base of DRAM, and to allow the decompressed kernel to
> >> reside at any 2 MB aligned offset in memory.
>
> This would allow putting the kernel at the very top of memory.

No, not at all. The way Linux/ARM defines its linear map is tied to
the placement of the kernel image, and any memory below it cannot be
used by the OS. IOW, placing the kernel at the very top of memory
would result in zero MB of lowmem being available, and therefore no
successful boot.

Formerly, the decompressor would simply round down the decompressor's
load address to 128 MB, and use the resulting value as the load
address of the decompressed kernel. This meant that
a) systems where the DRAM banks are not on a 128 MB boundary were
difficult to support
b) having reserved regions at the start of memory was problematic,
because the decompressor did not look at the device tree at all (this
is why we have all these TEXT_OFFSET hacks in the ARM kernel)
c) the EFI stub was forced to relocate itself into the first 128 MB of
memory, or the decompressor would misidentify the start of DRAM.

This has been fixed now: we can find the start of DRAM in the device
tree when necessary, but for EFI boot, we use the memory map to define
that kernel load address and pass it directly. This means we no longer
need to move the decompressor before invoking it
(d0f9ca9be11f25ef4151195eab7ea36d136084f6)

This uncovered another issue, though: the minimal relative alignment
of physical vs. virtual addresses was 16 MB, to ensure that the
PA-to-VA and vice versa routines worked correctly. So the tiniest
memory reservation at the start of DRAM would mean losing ~16 MB of
memory (given that DRAM below the kernel is not usable)

I fixed this in 9443076e4330a14ae2c6114307668b98a8293b77, and so now,
the kernel is loaded at the lowest available 2 MB boundary.

> But
> cons

Re: [PATCH v3 5/7] image-fdt: save no-map parameter of reserve-memory

[Ard Biesheuvel]

On Thu, 29 Apr 2021 at 18:11, Simon Glass  wrote:
>
> Hi Patrick,
>
> On Wed, 28 Apr 2021 at 03:23, Patrick Delaunay
>  wrote:
> >
> > Save the no-map information present in 'reserved-memory' node to allow
> > correct handling when the MMU is configured in board to avoid
> > speculative access.
> >
> > Signed-off-by: Patrick Delaunay 
> > ---
> >
> > (no changes since v1)
> >
> >  common/image-fdt.c | 23 +++
> >  1 file changed, 15 insertions(+), 8 deletions(-)
>
> Where is no-map documented?
>
> Reviewed-by: Simon Glass 

I don't remember exactly where the discussion ended up the last time,
so please disregard this if we settled it, but I still don't think
that secure-only memory should be described in the DT at all.

The v7 and v8 documentation are not 100% aligned on this, but the S
bit is now considered a true address bit, and so secure address 0x0
and non-secure address zero could be decoded by different peripherals
at the same time, even if some TZ firewall implementations don't
implement it that way.

Since DT addresses don't carry the S bit at all, any address described
in DT must be assumed to be a non-secure address. This means that the
no-map region essentially describes a non-secure region that does not
exist, in order to prevent a secure region at the same offset (which
DT cannot describe in the first place) from being covered by the
linear mapping.

So, apologies if we are going around in circles here, but could you
please explain again why the DT is describing secure memory as
non-secure memory, and then reserving it again using no-map?

Re: [PATCH v1] qemu-arm: round down memory to multiple of 2MB

[Ard Biesheuvel]

On Thu, 11 Feb 2021 at 16:34, Heinrich Schuchardt  wrote:
>
> On 11.02.21 15:56, Ard Biesheuvel wrote:
> > On Thu, 11 Feb 2021 at 15:18, Heinrich Schuchardt  
> > wrote:
> >>
> >> On 11.02.21 13:04, Igor Opaniuk wrote:
> >>> From: Igor Opaniuk 
> >>>
> >>> When LPAE is enabled, 1:1 mapping is created using 2 MB blocks.
> >>> In case amount of memory provided to QEMU is not multiple
> >>> of 2 MB, round down the amount of available memory to avoid hang
> >>> during MMU initialization.
> >>>
> >>> How to reproduce:
> >>> qemu-system-arm -machine virt -m 1058 -nographic -bios u-boot.bin - boots
> >>> qemu-system-arm -machine virt -m 1057 -nographic -bios u-boot.bin - hangs
> >>>
> >>> DRAM:  1 GiB
> >>> initcall: 60011df8
> >>> initcall: 60011904
> >>> New Stack Pointer is: 80fffe90
> >>> initcall: 60011a20
> >>> initcall: 60011bcc
> >>> initcall: 60011bd4
> >>> initcall: 600119b4
> >>> Relocation Offset is: 22042000
> >>> Relocating to 82042000, new gd at 81001ed0, sp at 80fffe90
> >>> initcall: 60011b8c
> >>> initcall: 82053ea0
> >>> initcall: 82053ea8
> >>> initcall: 60012040 (relocated to 82054040)
> >>> dram_bank_mmu_setup: bank: 0
> >>> --- hang here during mmu init ---
> >>>
> >>> Fixes: 3fa914af82("arm: qemu: implement enable_caches()")
> >>> Signed-off-by: Igor Opaniuk 
> >>>
> >>> ---
> >>>
> >>>  board/emulation/qemu-arm/qemu-arm.c | 12 
> >>>  1 file changed, 12 insertions(+)
> >>>
> >>> diff --git a/board/emulation/qemu-arm/qemu-arm.c 
> >>> b/board/emulation/qemu-arm/qemu-arm.c
> >>> index aa68bef469..841dd7af0e 100644
> >>> --- a/board/emulation/qemu-arm/qemu-arm.c
> >>> +++ b/board/emulation/qemu-arm/qemu-arm.c
> >>> @@ -84,6 +84,18 @@ int dram_init(void)
> >>>   if (fdtdec_setup_mem_size_base() != 0)
> >>>   return -EINVAL;
> >>>
> >>> + /*
> >>> +  * When LPAE is enabled (ARMv7),
> >>> +  * 1:1 mapping is created using 2 MB blocks.
> >>> +  *
> >>> +  * In case amount of memory provided to QEMU
> >>> +  * is not multiple of 2 MB, round down the amount
> >>> +  * of available memory to avoid hang during MMU
> >>> +  * initialization.
> >>> +  */
> >>> + if (CONFIG_IS_ENABLED(ARMV7_LPAE))
> >>> + gd->ram_size -= (gd->ram_size % 0x20);
> >>
> >> Is the problem LPAE specific?
> >> Couldn't you provoke same problem using an odd memory size without LPAE,
> >> e.g qemu-system-arm -m 536870908 (512 MiB - 4)?
> >>
> >
> > The above value means 512 GiB - 4 MiB, so that shouldn't be a problem.
> > I don't think QEMU's -m option takes fractional megabyte values.
> >
>
> $ qemu-system-arm -machine virt -cpu cortex-a15 -m 15k \
> -bios denx/u-boot.bin -nographic
>
> => fdt addr $fdt_addr
> => fdt print /memory@4000
> memory@4000 {
> reg = <0x 0x4000 0x 0x061aa000>;
> device_type = "memory";
> };
>
> Granularity seems to be 0x2000 = 8 KiB.
>

In that case, it seems easiest to me to always round down to the
nearest multiple of 2MB

Re: [PATCH v1] qemu-arm: round down memory to multiple of 2MB

[Ard Biesheuvel]

On Thu, 11 Feb 2021 at 15:18, Heinrich Schuchardt  wrote:
>
> On 11.02.21 13:04, Igor Opaniuk wrote:
> > From: Igor Opaniuk 
> >
> > When LPAE is enabled, 1:1 mapping is created using 2 MB blocks.
> > In case amount of memory provided to QEMU is not multiple
> > of 2 MB, round down the amount of available memory to avoid hang
> > during MMU initialization.
> >
> > How to reproduce:
> > qemu-system-arm -machine virt -m 1058 -nographic -bios u-boot.bin - boots
> > qemu-system-arm -machine virt -m 1057 -nographic -bios u-boot.bin - hangs
> >
> > DRAM:  1 GiB
> > initcall: 60011df8
> > initcall: 60011904
> > New Stack Pointer is: 80fffe90
> > initcall: 60011a20
> > initcall: 60011bcc
> > initcall: 60011bd4
> > initcall: 600119b4
> > Relocation Offset is: 22042000
> > Relocating to 82042000, new gd at 81001ed0, sp at 80fffe90
> > initcall: 60011b8c
> > initcall: 82053ea0
> > initcall: 82053ea8
> > initcall: 60012040 (relocated to 82054040)
> > dram_bank_mmu_setup: bank: 0
> > --- hang here during mmu init ---
> >
> > Fixes: 3fa914af82("arm: qemu: implement enable_caches()")
> > Signed-off-by: Igor Opaniuk 
> >
> > ---
> >
> >  board/emulation/qemu-arm/qemu-arm.c | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/board/emulation/qemu-arm/qemu-arm.c 
> > b/board/emulation/qemu-arm/qemu-arm.c
> > index aa68bef469..841dd7af0e 100644
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
> > @@ -84,6 +84,18 @@ int dram_init(void)
> >   if (fdtdec_setup_mem_size_base() != 0)
> >   return -EINVAL;
> >
> > + /*
> > +  * When LPAE is enabled (ARMv7),
> > +  * 1:1 mapping is created using 2 MB blocks.
> > +  *
> > +  * In case amount of memory provided to QEMU
> > +  * is not multiple of 2 MB, round down the amount
> > +  * of available memory to avoid hang during MMU
> > +  * initialization.
> > +  */
> > + if (CONFIG_IS_ENABLED(ARMV7_LPAE))
> > + gd->ram_size -= (gd->ram_size % 0x20);
>
> Is the problem LPAE specific?
> Couldn't you provoke same problem using an odd memory size without LPAE,
> e.g qemu-system-arm -m 536870908 (512 MiB - 4)?
>

The above value means 512 GiB - 4 MiB, so that shouldn't be a problem.
I don't think QEMU's -m option takes fractional megabyte values.

Re: qemu-arm: hang during MMU initialization

[Ard Biesheuvel]

On Fri, 5 Feb 2021 at 18:38, Igor Opaniuk  wrote:
>
> Hi,
>
> With this commit 3fa914af82("arm: qemu: implement enable_caches()") 
> introduced,
> which enables instruction/data caches for qemu-arm target,
> U-Boot sometimes hangs during MMU init procedure :
>
> DRAM:  1 GiB
> initcall: 60011df8
> initcall: 60011904
> New Stack Pointer is: 80fffe90
> initcall: 60011a20
> initcall: 60011bcc
> initcall: 60011bd4
> initcall: 600119b4
> Relocation Offset is: 22042000
> Relocating to 82042000, new gd at 81001ed0, sp at 80fffe90
> initcall: 60011b8c
> initcall: 82053ea0
> initcall: 82053ea8
> initcall: 60012040 (relocated to 82054040)
> dram_bank_mmu_setup: bank: 0
>
> This issue reproduces every time when the amount of memory provided to QEMU
> is not 2MB granular. Looks like it might be some unexpected alignment issue.
>
> Test results (QEMU v5.2.0 release):
> qemu-system-arm -machine virt -m 1058 -nographic -bios u-boot.bin - boots OK
> qemu-system-arm -machine virt -m 1057 -nographic -bios u-boot.bin - hangs
> qemu-system-arm -machine virt -m 1056 -nographic -bios u-boot.bin - boots OK
> qemu-system-arm -machine virt -m 1055 -nographic -bios u-boot.bin - hangs
>
> Unfortunately I didn't have a chance to investigate this further, so
> just sharing my current observations. Thanks for any input.
>

Hello Igor,

enable_caches() results in a 1:1 mapping to be created, and since LPAE
has been enabled as well, the 1:1 mapping is created using 2 MB
blocks. So I am not surprised that using a value that is not a
multiple of 2 MB causes problems.

I'd suggest implementing a simple fix, e.g., just round down the
amount of available memory, as this is not something that is likely to
ever be a problem on real systems.

-- 
Ard.

Re: [Uboot-stm32] [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property

[Ard Biesheuvel]

On Thu, 29 Oct 2020 at 17:06, Etienne Carriere
 wrote:
>
> On Thu, 29 Oct 2020 at 12:26, Ard Biesheuvel  wrote:
> >
> > On Thu, 29 Oct 2020 at 11:40, Etienne Carriere
> >  wrote:
> > >
> > > Dear all,
> > >
> > > CC some fellow OP-TEE guys for this secure memory description topic.
> > >
> > >
> > > On Wed, 28 Oct 2020 at 11:33, Patrick DELAUNAY  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > > From: Ard Biesheuvel 
> > > > > Sent: mardi 27 octobre 2020 22:05
> > > > >
> > > > > On Tue, 27 Oct 2020 at 18:25, Tom Rini  wrote:
> > > > > >
> > > > > > On Fri, Oct 09, 2020 at 05:00:44PM +, Patrick DELAUNAY wrote:
> > > > > > > Hi Ard,
> > > > > > >
> > > > > > > > From: Ard Biesheuvel 
> > > > > > > > Sent: mercredi 7 octobre 2020 15:16
> > > > > > > >
> > > > > > > > On Wed, 7 Oct 2020 at 13:53, Ahmad Fatoum 
> > > > > > > > 
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > > > On 10/7/20 1:23 PM, Ahmad Fatoum wrote:
> > > > > > > > > > My findings[1] back then were that U-Boot did set the 
> > > > > > > > > > eXecute
> > > > > > > > > > Never bit only on OMAP, but not for other platforms.  So I
> > > > > > > > > > could imagine this being the root cause of Patrick's issues 
> > > > > > > > > > as well:
> > > > > > > > >
> > > > > > > > > Rereading my own link, my memory is a little less fuzzy: 
> > > > > > > > > eXecute
> > > > > > > > > Never was being set, but was without effect due Manager mode
> > > > > > > > > being set in the
> > > > > > > > DACR:
> > > > > > > > >
> > > > > > > > > > The ARM Architecture Reference Manual notes[1]:
> > > > > > > > > > > When using the Short-descriptor translation table format,
> > > > > > > > > > > the XN attribute is not checked for domains marked as 
> > > > > > > > > > > Manager.
> > > > > > > > > > > Therefore, the system must not include read-sensitive 
> > > > > > > > > > > memory
> > > > > > > > > > > in domains marked as Manager, because the XN bit does not
> > > > > > > > > > > prevent speculative fetches from a Manager domain.
> > > > > > > > >
> > > > > > > > > > To avoid speculative access to read-sensitive memory-mapped
> > > > > > > > > > peripherals on ARMv7, we'll need U-Boot to use client domain
> > > > > > > > > > permissions, so the XN bit can function.
> > > > > > > > >
> > > > > > > > > > This issue has come up before and was fixed in de63ac278
> > > > > > > > > > ("ARM: mmu: Set domain permissions to client access") for 
> > > > > > > > > > OMAP2
> > > > > only.
> > > > > > > > > > It's equally applicable to all ARMv7-A platforms where 
> > > > > > > > > > caches
> > > > > > > > > > are enabled.
> > > > > > > > > > [1]: B3.7.2 - Execute-never restrictions on instruction
> > > > > > > > > > fetching
> > > > > > > > >
> > > > > > > > > Hope this helps,
> > > > > > > > > Ahmad
> > > > > > > > >
> > > > > > > >
> > > > > > > > It most definitely does, thanks a lot.
> > > > > > > >
> > > > > > > > U-boot's mmu_setup() currently sets DACR to manager for all
> > > > > > > > domains, so this is broken for all non-LPAE configurations 
> > > > > > > > running
> > > > > > > > on v7 CPUs (except OMAP and perhaps others tha

Re: [Uboot-stm32] [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property

[Ard Biesheuvel]

On Thu, 29 Oct 2020 at 11:40, Etienne Carriere
 wrote:
>
> Dear all,
>
> CC some fellow OP-TEE guys for this secure memory description topic.
>
>
> On Wed, 28 Oct 2020 at 11:33, Patrick DELAUNAY  
> wrote:
> >
> > Hi,
> >
> > > From: Ard Biesheuvel 
> > > Sent: mardi 27 octobre 2020 22:05
> > >
> > > On Tue, 27 Oct 2020 at 18:25, Tom Rini  wrote:
> > > >
> > > > On Fri, Oct 09, 2020 at 05:00:44PM +, Patrick DELAUNAY wrote:
> > > > > Hi Ard,
> > > > >
> > > > > > From: Ard Biesheuvel 
> > > > > > Sent: mercredi 7 octobre 2020 15:16
> > > > > >
> > > > > > On Wed, 7 Oct 2020 at 13:53, Ahmad Fatoum 
> > > wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > On 10/7/20 1:23 PM, Ahmad Fatoum wrote:
> > > > > > > > My findings[1] back then were that U-Boot did set the eXecute
> > > > > > > > Never bit only on OMAP, but not for other platforms.  So I
> > > > > > > > could imagine this being the root cause of Patrick's issues as 
> > > > > > > > well:
> > > > > > >
> > > > > > > Rereading my own link, my memory is a little less fuzzy: eXecute
> > > > > > > Never was being set, but was without effect due Manager mode
> > > > > > > being set in the
> > > > > > DACR:
> > > > > > >
> > > > > > > > The ARM Architecture Reference Manual notes[1]:
> > > > > > > > > When using the Short-descriptor translation table format,
> > > > > > > > > the XN attribute is not checked for domains marked as Manager.
> > > > > > > > > Therefore, the system must not include read-sensitive memory
> > > > > > > > > in domains marked as Manager, because the XN bit does not
> > > > > > > > > prevent speculative fetches from a Manager domain.
> > > > > > >
> > > > > > > > To avoid speculative access to read-sensitive memory-mapped
> > > > > > > > peripherals on ARMv7, we'll need U-Boot to use client domain
> > > > > > > > permissions, so the XN bit can function.
> > > > > > >
> > > > > > > > This issue has come up before and was fixed in de63ac278
> > > > > > > > ("ARM: mmu: Set domain permissions to client access") for OMAP2
> > > only.
> > > > > > > > It's equally applicable to all ARMv7-A platforms where caches
> > > > > > > > are enabled.
> > > > > > > > [1]: B3.7.2 - Execute-never restrictions on instruction
> > > > > > > > fetching
> > > > > > >
> > > > > > > Hope this helps,
> > > > > > > Ahmad
> > > > > > >
> > > > > >
> > > > > > It most definitely does, thanks a lot.
> > > > > >
> > > > > > U-boot's mmu_setup() currently sets DACR to manager for all
> > > > > > domains, so this is broken for all non-LPAE configurations running
> > > > > > on v7 CPUs (except OMAP and perhaps others that fixed it
> > > > > > individually). This affects all device mappings: not just secure
> > > > > > DRAM for OP-TEE, but any MMIO register for any peripheral that is 
> > > > > > mapped
> > > into the CPU's address space.
> > > > > >
> > > > > > Patrick, could you please check whether this fixes the issue as 
> > > > > > well?
> > > > > >
> > > > > > --- a/arch/arm/lib/cache-cp15.c
> > > > > > +++ b/arch/arm/lib/cache-cp15.c
> > > > > > @@ -202,9 +202,9 @@ static inline void mmu_setup(void)
> > > > > > asm volatile("mcr p15, 0, %0, c2, c0, 0"
> > > > > >  : : "r" (gd->arch.tlb_addr) : "memory");  
> > > > > > #endif
> > > > > > -   /* Set the access control to all-supervisor */
> > > > > > +   /* Set the access control to client (0b01) for each of the
> > > > > > + 16 domains */
> > > > &g

Re: [Uboot-stm32] [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property

[Ard Biesheuvel]

On Tue, 27 Oct 2020 at 18:25, Tom Rini  wrote:
>
> On Fri, Oct 09, 2020 at 05:00:44PM +, Patrick DELAUNAY wrote:
> > Hi Ard,
> >
> > > From: Ard Biesheuvel 
> > > Sent: mercredi 7 octobre 2020 15:16
> > >
> > > On Wed, 7 Oct 2020 at 13:53, Ahmad Fatoum  wrote:
> > > >
> > > > Hello,
> > > >
> > > > On 10/7/20 1:23 PM, Ahmad Fatoum wrote:
> > > > > My findings[1] back then were that U-Boot did set the eXecute Never
> > > > > bit only on OMAP, but not for other platforms.  So I could imagine
> > > > > this being the root cause of Patrick's issues as well:
> > > >
> > > > Rereading my own link, my memory is a little less fuzzy: eXecute Never
> > > > was being set, but was without effect due Manager mode being set in the
> > > DACR:
> > > >
> > > > > The ARM Architecture Reference Manual notes[1]:
> > > > > > When using the Short-descriptor translation table format, the XN
> > > > > > attribute is not checked for domains marked as Manager.
> > > > > > Therefore, the system must not include read-sensitive memory in
> > > > > > domains marked as Manager, because the XN bit does not prevent
> > > > > > speculative fetches from a Manager domain.
> > > >
> > > > > To avoid speculative access to read-sensitive memory-mapped
> > > > > peripherals on ARMv7, we'll need U-Boot to use client domain
> > > > > permissions, so the XN bit can function.
> > > >
> > > > > This issue has come up before and was fixed in de63ac278
> > > > > ("ARM: mmu: Set domain permissions to client access") for OMAP2 only.
> > > > > It's equally applicable to all ARMv7-A platforms where caches are
> > > > > enabled.
> > > > > [1]: B3.7.2 - Execute-never restrictions on instruction fetching
> > > >
> > > > Hope this helps,
> > > > Ahmad
> > > >
> > >
> > > It most definitely does, thanks a lot.
> > >
> > > U-boot's mmu_setup() currently sets DACR to manager for all domains, so 
> > > this is
> > > broken for all non-LPAE configurations running on v7 CPUs (except OMAP and
> > > perhaps others that fixed it individually). This affects all device 
> > > mappings: not just
> > > secure DRAM for OP-TEE, but any MMIO register for any peripheral that is
> > > mapped into the CPU's address space.
> > >
> > > Patrick, could you please check whether this fixes the issue as well?
> > >
> > > --- a/arch/arm/lib/cache-cp15.c
> > > +++ b/arch/arm/lib/cache-cp15.c
> > > @@ -202,9 +202,9 @@ static inline void mmu_setup(void)
> > > asm volatile("mcr p15, 0, %0, c2, c0, 0"
> > >  : : "r" (gd->arch.tlb_addr) : "memory");  #endif
> > > -   /* Set the access control to all-supervisor */
> > > +   /* Set the access control to client (0b01) for each of the 16
> > > + domains */
> > > asm volatile("mcr p15, 0, %0, c3, c0, 0"
> > > -: : "r" (~0));
> > > +: : "r" (0x));
> > >
> > > arm_init_domains();
> >
> > The test will take some time to be sure that solve my remaining issue 
> > because  issue is not always reproductible.
> >
> > At fist chek, I wasn't sure of DACR bahavior, but I found in [1] the line :
> >
> >   The XN attribute is not checked for domains marked as Manager. 
> > Read-sensitive memory must
> >   not be included in domains marked as Manager, because the XN bit does 
> > not prevent prefetches
> >   in these cases.
> >
> > So, I need  to test your patch +  DCACHE_OFF instead of INVALID
> > (to map with XN the OP-TEE region) in my patchset.
> >
> > FYI: I found the same DACR configuration is done in:
> >   arch/arm/cpu/armv7/ls102xa/cpu.c:199
> >
> > [1] 
> > https://developer.arm.com/documentation/ddi0406/b/System-Level-Architecture/Virtual-Memory-System-Architecture--VMSA-/Memory-access-control/The-Execute-Never--XN--attribute-and-instruction-prefetching?lang=en
> >
> > Patrick
> >
> > For information:
> >
> > At the beginning I wasn't sure that the current DACR configuration is an 
> > issue because in found
> > in p

Re: [Uboot-stm32] [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property

[Ard Biesheuvel]

On Mon, 12 Oct 2020 at 11:51, Etienne Carriere
 wrote:
>
> On Mon, 12 Oct 2020 at 11:20, Ard Biesheuvel  wrote:
> >
> > On Mon, 12 Oct 2020 at 11:09, Etienne Carriere
> >  wrote:
> > >
> > > On Fri, 9 Oct 2020 at 19:13, Ahmad Fatoum  wrote:
> > > >
> > > > Hello Patrick,
> > > >
> > > > On 10/9/20 5:52 PM, Patrick DELAUNAY wrote:
> > > > > I checked DACR behavior and CheckDomain /  CheckPermission
> > > > >
> > > > > In my case the cortex A7 try to access to part of DDR / mapped 
> > > > > cacheable and bufferable, protected by firewall.
> > > > >
> > > > > So to use DACR I always need to configure the MMU with several Domain
> > > > > - unsecure part of DDR as Domain 0 (DCACHE_WRITEALLOC)
> > > > > - secure part of DDR as  Domain 1 (DCACHE_OFF)
> > > > >
> > > > > For other part of MMU region, the I/O registers are mapped as 
> > > > > register with Domain 0 (D_CACHE_OFF)
> > > > >
> > > > > Then I can set DACR = 0x
> > > > > => Client Accesses are checked against the access permission bits in 
> > > > > the TLB entry
> > > > >
> > > > > You ar right, the access permission is check only for domain 
> > > > > configurated as client in DACR
> > > > >
> > > > > But in ARM architecture
> > > > >
> > > > > B2.4.8 Access permission checking
> > > > >
> > > > > CheckPermission() pseudo code
> > > > > Only check perms.ap is checked
> > > > > And perms.xp is not checked
> > > > >
> > > > > But as the secure memory is mapped cacheable by secure OS, OP-TEE
> > > > > I think to avoid to map the region is the ARM preconized solution
> > > > > As explain in my answer to ard in [1]
> > > > >
> > > > > [1] 
> > > > > http://u-boot.10912.n7.nabble.com/PATCH-0-7-arm-cache-cp15-don-t-map-reserved-region-with-no-map-property-tt428715.html#a428958
> > > >
> > > > I don't think the aliasing described in "A3.5.7 Memory access 
> > > > restrictions" applies if the
> > > > same memory is mapped twice only, once in secure and another in normal 
> > > > world.
> > > > Data is already segregated in the caches by means of a NS bit. Only 
> > > > thing you should need
> > > > to do within normal world is mapping it XN, cacheable and not be in 
> > > > manager domain.
> > > > Unmapping sounds unnecessary to me. (You don't unmap peripherals you 
> > > > aren't using either.
> > > > Why handle OP-TEE DRAM specially?)
> > >
> > > This is right regarding the secure memory/NS=0. But the
> > > reserved-memory node for OP-TEE can also cover non-secure (shared)
> > > memory that OP-TEE secure world maps Normal/NS=1. So U-boot should not
> > > map such memory as Device/NS=0. That would jeopardize non-secure
> > > memory content.
> > >
> >
> > Agreed. If secure and non-secure need to have a coherent, cacheable
> > view of that shared memory, non-secure device mappings must be
> > avoided.
> >
> > But is no-map really needed for that memory? It needs to be mapped in
> > any case to be usable for the non-secure world to communicate with the
> > secure world, right?
> >
> > I'd assume the no-map is only needed if cacheable, inner shareable
> > mappings are a problem.
>
> The non-secure (shared) reserved-memory gets mapped by the related
> driver (drivers/tee/optee/) at run time.
> Hmm... actually, U-Boot driver does map or use this shared memory,
> only Linux does.
> But even if U-Boot optee driver does not map the shared memory, OP-TEE
> secure world still likely does.
>
> >
> > > Note that platforms can define either a single reserved-memory node in
> > > the FDT for both contiguous secure and shared DDR
> > > or platforms can alternatively define 2 reserved_memory nodes: one for
> > > the secure DDR and one for the non-secure shared DDR.
> > >
> > > In the 1st case, the no-map property of the single reserved-memory
> > > node should really not map the area in U-Boot.
> > >
> > > In the 2nd case, the no-map property on the secure DDR reserved-memory
> > > node must prevent U-Boot speculative accesses while node for shared
> > >

Re: [Uboot-stm32] [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property

[Ard Biesheuvel]

On Mon, 12 Oct 2020 at 11:09, Etienne Carriere
 wrote:
>
> On Fri, 9 Oct 2020 at 19:13, Ahmad Fatoum  wrote:
> >
> > Hello Patrick,
> >
> > On 10/9/20 5:52 PM, Patrick DELAUNAY wrote:
> > > I checked DACR behavior and CheckDomain /  CheckPermission
> > >
> > > In my case the cortex A7 try to access to part of DDR / mapped cacheable 
> > > and bufferable, protected by firewall.
> > >
> > > So to use DACR I always need to configure the MMU with several Domain
> > > - unsecure part of DDR as Domain 0 (DCACHE_WRITEALLOC)
> > > - secure part of DDR as  Domain 1 (DCACHE_OFF)
> > >
> > > For other part of MMU region, the I/O registers are mapped as register 
> > > with Domain 0 (D_CACHE_OFF)
> > >
> > > Then I can set DACR = 0x
> > > => Client Accesses are checked against the access permission bits in the 
> > > TLB entry
> > >
> > > You ar right, the access permission is check only for domain configurated 
> > > as client in DACR
> > >
> > > But in ARM architecture
> > >
> > > B2.4.8 Access permission checking
> > >
> > > CheckPermission() pseudo code
> > > Only check perms.ap is checked
> > > And perms.xp is not checked
> > >
> > > But as the secure memory is mapped cacheable by secure OS, OP-TEE
> > > I think to avoid to map the region is the ARM preconized solution
> > > As explain in my answer to ard in [1]
> > >
> > > [1] 
> > > http://u-boot.10912.n7.nabble.com/PATCH-0-7-arm-cache-cp15-don-t-map-reserved-region-with-no-map-property-tt428715.html#a428958
> >
> > I don't think the aliasing described in "A3.5.7 Memory access restrictions" 
> > applies if the
> > same memory is mapped twice only, once in secure and another in normal 
> > world.
> > Data is already segregated in the caches by means of a NS bit. Only thing 
> > you should need
> > to do within normal world is mapping it XN, cacheable and not be in manager 
> > domain.
> > Unmapping sounds unnecessary to me. (You don't unmap peripherals you aren't 
> > using either.
> > Why handle OP-TEE DRAM specially?)
>
> This is right regarding the secure memory/NS=0. But the
> reserved-memory node for OP-TEE can also cover non-secure (shared)
> memory that OP-TEE secure world maps Normal/NS=1. So U-boot should not
> map such memory as Device/NS=0. That would jeopardize non-secure
> memory content.
>

Agreed. If secure and non-secure need to have a coherent, cacheable
view of that shared memory, non-secure device mappings must be
avoided.

But is no-map really needed for that memory? It needs to be mapped in
any case to be usable for the non-secure world to communicate with the
secure world, right?

I'd assume the no-map is only needed if cacheable, inner shareable
mappings are a problem.

> Note that platforms can define either a single reserved-memory node in
> the FDT for both contiguous secure and shared DDR
> or platforms can alternatively define 2 reserved_memory nodes: one for
> the secure DDR and one for the non-secure shared DDR.
>
> In the 1st case, the no-map property of the single reserved-memory
> node should really not map the area in U-Boot.
>
> In the 2nd case, the no-map property on the secure DDR reserved-memory
> node must prevent U-Boot speculative accesses while node for shared
> memory obviously doesn't need no-map.
>
> This is to say that mapping as Device memory that has the no-map
> property can be an issue.
>

So in summary, there are two separate requirements resulting from this:
- the DT should not describe secure world memory as ordinary memory,
as the S and NS address spaces could overlap, and the distinction only
makes sense for agents running in the secure world;
- no-map should be honored by u-boot, but it should only be used if
the existence of a cacheable, inner shareable mapping of that memory
poses a problem.

-- 
Ard.

Re: [Uboot-stm32] [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property

[Ard Biesheuvel]

On Fri, 9 Oct 2020 at 19:13, Ahmad Fatoum  wrote:
>
> Hello Patrick,
>
> On 10/9/20 5:52 PM, Patrick DELAUNAY wrote:
> > I checked DACR behavior and CheckDomain /  CheckPermission
> >
> > In my case the cortex A7 try to access to part of DDR / mapped cacheable 
> > and bufferable, protected by firewall.
> >
> > So to use DACR I always need to configure the MMU with several Domain
> > - unsecure part of DDR as Domain 0 (DCACHE_WRITEALLOC)
> > - secure part of DDR as  Domain 1 (DCACHE_OFF)
> >
> > For other part of MMU region, the I/O registers are mapped as register with 
> > Domain 0 (D_CACHE_OFF)
> >
> > Then I can set DACR = 0x
> > => Client Accesses are checked against the access permission bits in the 
> > TLB entry
> >
> > You ar right, the access permission is check only for domain configurated 
> > as client in DACR
> >
> > But in ARM architecture
> >
> > B2.4.8 Access permission checking
> >
> > CheckPermission() pseudo code
> > Only check perms.ap is checked
> > And perms.xp is not checked
> >
> > But as the secure memory is mapped cacheable by secure OS, OP-TEE
> > I think to avoid to map the region is the ARM preconized solution
> > As explain in my answer to ard in [1]
> >
> > [1] 
> > http://u-boot.10912.n7.nabble.com/PATCH-0-7-arm-cache-cp15-don-t-map-reserved-region-with-no-map-property-tt428715.html#a428958
>
> I don't think the aliasing described in "A3.5.7 Memory access restrictions" 
> applies if the
> same memory is mapped twice only, once in secure and another in normal world.
> Data is already segregated in the caches by means of a NS bit. Only thing you 
> should need
> to do within normal world is mapping it XN, cacheable and not be in manager 
> domain.
> Unmapping sounds unnecessary to me. (You don't unmap peripherals you aren't 
> using either.
> Why handle OP-TEE DRAM specially?)
>

Ah good point. The secure DDR is in the secure physical address space,
whereas the non-secure mapping refers to non-secure physical memory.
So from a coherency point of view, they are really not aliases of one
another, and so the mismatched attribute concern does not apply.

But this actually reinforces my previous point too: the secure and
non-secure physical address spaces are disjoint, and the DT can only
describe non-secure memory, so these regions don't belong in the DT
given to the OS in the first place.



>
>
> >
> >> Cheers
> >> Ahmad
> >>
> >> --
> >> Pengutronix e.K.   | |
> >> Steuerwalder Str. 21   | http://www.pengutronix.de/  |
> >> 31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
> >> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
>
> --
> Pengutronix e.K.   | |
> Steuerwalder Str. 21   | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property

[Ard Biesheuvel]

On Fri, 9 Oct 2020 at 13:19, Patrick DELAUNAY  wrote:
>
> Hi Ard,
>
> > From: Ard Biesheuvel 
> > Sent: mercredi 7 octobre 2020 12:27
> >
> > On Tue, 6 Oct 2020 at 18:36, Patrick Delaunay 
> > wrote:
> > >
> > >
> > > Hi,
> > >
> > > On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region
> > > protected by a firewall. This region is reserved in device with "no-map"
> > > property.
> > >
> > > But sometime the platform boot failed in U-boot on a Cortex A7 access
> > > to this region (depending of the binary and the issue can change with
> > > compiler version or with code alignment), then the firewall raise a
> > > error, for example:
> > >
> > > E/TC:0   tzc_it_handler:19 TZC permission failure
> > > E/TC:0   dump_fail_filter:420 Permission violation on filter 0
> > > E/TC:0   dump_fail_filter:425 Violation @0xde5c6bf0, non-secure privileged
> > read,
> > >  AXI ID 5c0
> > > E/TC:0   Panic
> > >
> > > After investigation, the forbidden access is a speculative request
> > > performed by the Cortex A7 because all the DDR is mapped as MEMORY
> > > with CACHEABLE property.
> > >
> > > The issue is solved only when the region reserved by OP-TEE is no more
> > > mapped in U-Boot (mapped as DEVICE/NON-CACHEABLE wasn't enough) as it
> > > is already done in Linux kernel.
> > >
> >
> > Spurious peculative accesses to device regions would be a severe silicon 
> > bug, so
> > I wonder what is going on here.
> >
> > (Apologies if we are rehashing stuff here that has already been discussed - 
> > I don't
> > remember the details)
> >
> > Are you sure that the speculative accesses were not caused by misconfigured
> > CPU or page tables, missing TLB maintenance, etc etc?
> > Because it really does smell like a software issue not a hardware issue.
> >
> > > I think that can be a general issue for ARM architecture: the no-map
> > > tag in device should be respected by U-boot, so I propose a  generic
> > > solution in arm/lib/cache-cp15.c:dram_bank_mmu_setup().
> > >
> > > This serie is composed by 7 patches
> > > - 1..4/7: preliminary steps to support flags in library in lmb
> > >   (as it is done in memblock.c in Linux)
> > > - 5/7: unitary test on the added feature in lmb lib
> > > - 6/7: save the no-map flags in lmb when the device tree is parsed
> > > - 7/7: update the generic behavior for "no-map" region in
> > >arm/lib/cache-cp15.c::dram_bank_mmu_setup()
> > >
> > > It is a rebase on master branch of previous RFC [2].
> > >
> > > I can change this last patch if this feature is note required by other
> > > ARM architecture; it is a weak function so I can avoid to map the
> > > region with "no-map" property in device tree only for STM32MP
> > > architecture (in arch/arm/mach-stm32mp/cpu.c).
> > >
> > > See also [1] which handle same speculative access on armv8 for area
> > > with Executable attribute.
> > >
> > > [1]
> > > http://patchwork.ozlabs.org/project/uboot/patch/20200903000106.5016-1-
> > > marek.bykow...@gmail.com/ [2]
> > > http://patchwork.ozlabs.org/project/uboot/list/?series=199486&archive=
> > > both&state=*
> > >
> > > Regards
> > > Patrick
> > >
> > >
> > > Patrick Delaunay (7):
> > >   lmb: Add support of flags for no-map properties
> > >   lmb: add lmb_is_reserved_flags
> > >   lmb: remove lmb_region.size
> > >   lmb: add lmb_dump_region() function
> > >   test: lmb: add test for lmb_reserve_flags
> > >   image-fdt: save no-map parameter of reserve-memory
> > >   arm: cache: cp15: don't map the reserved region with no-map property
> > >
> > >  arch/arm/include/asm/system.h |   3 +
> > >  arch/arm/lib/cache-cp15.c |  19 ++-
> > >  common/image-fdt.c|  23 +---
> > >  include/lmb.h |  22 +++-
> > >  lib/lmb.c | 100 +++---
> > >  test/lib/lmb.c|  89 ++
> > >  6 files changed, 212 insertions(+), 44 deletions(-)
> > >
> > > --
> > > 2.17.1
> > >
>
> No, I don't yet described the issue in details on mailing list.
> So I will explain the investigation done and

Re: [Uboot-stm32] [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property

[Ard Biesheuvel]

On Wed, 7 Oct 2020 at 16:55, Etienne Carriere
 wrote:
>
> Hello all,
>
> On Wed, 7 Oct 2020 at 15:16, Ard Biesheuvel  wrote:
> >
> > On Wed, 7 Oct 2020 at 13:53, Ahmad Fatoum  wrote:
> > >
> > > Hello,
> > >
> > > On 10/7/20 1:23 PM, Ahmad Fatoum wrote:
> > > > My findings[1] back then were that U-Boot did set the eXecute Never bit 
> > > > only on
> > > > OMAP, but not for other platforms.  So I could imagine this being the 
> > > > root cause
> > > > of Patrick's issues as well:
> > >
> > > Rereading my own link, my memory is a little less fuzzy: eXecute Never 
> > > was being
> > > set, but was without effect due Manager mode being set in the DACR:
> > >
> > > > The ARM Architecture Reference Manual notes[1]:
> > > > > When using the Short-descriptor translation table format, the XN
> > > > > attribute is not checked for domains marked as Manager.
> > > > > Therefore, the system must not include read-sensitive memory in
> > > > > domains marked as Manager, because the XN bit does not prevent
> > > > > speculative fetches from a Manager domain.
> > >
> > > > To avoid speculative access to read-sensitive memory-mapped peripherals
> > > > on ARMv7, we'll need U-Boot to use client domain permissions, so the XN
> > > > bit can function.
> > >
> > > > This issue has come up before and was fixed in de63ac278
> > > > ("ARM: mmu: Set domain permissions to client access") for OMAP2 only.
> > > > It's equally applicable to all ARMv7-A platforms where caches are
> > > > enabled.
> > > > [1]: B3.7.2 - Execute-never restrictions on instruction fetching
> > >
> > > Hope this helps,
> > > Ahmad
> > >
> >
> > It most definitely does, thanks a lot.
> >
> > U-boot's mmu_setup() currently sets DACR to manager for all domains,
> > so this is broken for all non-LPAE configurations running on v7 CPUs
> > (except OMAP and perhaps others that fixed it individually). This
> > affects all device mappings: not just secure DRAM for OP-TEE, but any
> > MMIO register for any peripheral that is mapped into the CPU's address
> > space.
>
> Despite the change proposed below seems to fix permissions bypass,
> I think that not mapping the memory address ranges that are explicitly
> expected to be not mapped (as in Patrick proposal) seems a consistent 
> approach.
>

Agreed.

But the issue Patrick is addressing uncovered a real bug that affects
many platforms, so let's please take advantage of this, and get it
fixed for everyone.

Then, we can decide whether unmapping the secure DRAM is worth it or
not, on its own merit, and not based on the justification that it
fixes a bug that should be fixed in a different way in the first
place.

Re: [Uboot-stm32] [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property

[Ard Biesheuvel]

On Wed, 7 Oct 2020 at 13:53, Ahmad Fatoum  wrote:
>
> Hello,
>
> On 10/7/20 1:23 PM, Ahmad Fatoum wrote:
> > My findings[1] back then were that U-Boot did set the eXecute Never bit 
> > only on
> > OMAP, but not for other platforms.  So I could imagine this being the root 
> > cause
> > of Patrick's issues as well:
>
> Rereading my own link, my memory is a little less fuzzy: eXecute Never was 
> being
> set, but was without effect due Manager mode being set in the DACR:
>
> > The ARM Architecture Reference Manual notes[1]:
> > > When using the Short-descriptor translation table format, the XN
> > > attribute is not checked for domains marked as Manager.
> > > Therefore, the system must not include read-sensitive memory in
> > > domains marked as Manager, because the XN bit does not prevent
> > > speculative fetches from a Manager domain.
>
> > To avoid speculative access to read-sensitive memory-mapped peripherals
> > on ARMv7, we'll need U-Boot to use client domain permissions, so the XN
> > bit can function.
>
> > This issue has come up before and was fixed in de63ac278
> > ("ARM: mmu: Set domain permissions to client access") for OMAP2 only.
> > It's equally applicable to all ARMv7-A platforms where caches are
> > enabled.
> > [1]: B3.7.2 - Execute-never restrictions on instruction fetching
>
> Hope this helps,
> Ahmad
>

It most definitely does, thanks a lot.

U-boot's mmu_setup() currently sets DACR to manager for all domains,
so this is broken for all non-LPAE configurations running on v7 CPUs
(except OMAP and perhaps others that fixed it individually). This
affects all device mappings: not just secure DRAM for OP-TEE, but any
MMIO register for any peripheral that is mapped into the CPU's address
space.

Patrick, could you please check whether this fixes the issue as well?

--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -202,9 +202,9 @@ static inline void mmu_setup(void)
asm volatile("mcr p15, 0, %0, c2, c0, 0"
 : : "r" (gd->arch.tlb_addr) : "memory");
 #endif
-   /* Set the access control to all-supervisor */
+   /* Set the access control to client (0b01) for each of the 16 domains */
asm volatile("mcr p15, 0, %0, c3, c0, 0"
-: : "r" (~0));
+: : "r" (0x));

arm_init_domains();

Re: [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property

[Ard Biesheuvel]

On Tue, 6 Oct 2020 at 18:36, Patrick Delaunay  wrote:
>
>
> Hi,
>
> On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region
> protected by a firewall. This region is reserved in device with "no-map"
> property.
>
> But sometime the platform boot failed in U-boot on a Cortex A7 access to
> this region (depending of the binary and the issue can change with compiler
> version or with code alignment), then the firewall raise a error,
> for example:
>
> E/TC:0   tzc_it_handler:19 TZC permission failure
> E/TC:0   dump_fail_filter:420 Permission violation on filter 0
> E/TC:0   dump_fail_filter:425 Violation @0xde5c6bf0, non-secure privileged 
> read,
>  AXI ID 5c0
> E/TC:0   Panic
>
> After investigation, the forbidden access is a speculative request performed
> by the Cortex A7 because all the DDR is mapped as MEMORY with CACHEABLE
> property.
>
> The issue is solved only when the region reserved by OP-TEE is no more
> mapped in U-Boot (mapped as DEVICE/NON-CACHEABLE wasn't enough) as it is
> already done in Linux kernel.
>

Spurious peculative accesses to device regions would be a severe
silicon bug, so I wonder what is going on here.

(Apologies if we are rehashing stuff here that has already been
discussed - I don't remember the details)

Are you sure that the speculative accesses were not caused by
misconfigured CPU or page tables, missing TLB maintenance, etc etc?
Because it really does smell like a software issue not a hardware
issue.

> I think that can be a general issue for ARM architecture: the no-map tag
> in device should be respected by U-boot, so I propose a  generic solution
> in arm/lib/cache-cp15.c:dram_bank_mmu_setup().
>
> This serie is composed by 7 patches
> - 1..4/7: preliminary steps to support flags in library in lmb
>   (as it is done in memblock.c in Linux)
> - 5/7: unitary test on the added feature in lmb lib
> - 6/7: save the no-map flags in lmb when the device tree is parsed
> - 7/7: update the generic behavior for "no-map" region in
>arm/lib/cache-cp15.c::dram_bank_mmu_setup()
>
> It is a rebase on master branch of previous RFC [2].
>
> I can change this last patch if this feature is note required by other
> ARM architecture; it is a weak function so I can avoid to map the region
> with "no-map" property in device tree only for STM32MP architecture
> (in arch/arm/mach-stm32mp/cpu.c).
>
> See also [1] which handle same speculative access on armv8 for area
> with Executable attribute.
>
> [1] 
> http://patchwork.ozlabs.org/project/uboot/patch/20200903000106.5016-1-marek.bykow...@gmail.com/
> [2] 
> http://patchwork.ozlabs.org/project/uboot/list/?series=199486&archive=both&state=*
>
> Regards
> Patrick
>
>
> Patrick Delaunay (7):
>   lmb: Add support of flags for no-map properties
>   lmb: add lmb_is_reserved_flags
>   lmb: remove lmb_region.size
>   lmb: add lmb_dump_region() function
>   test: lmb: add test for lmb_reserve_flags
>   image-fdt: save no-map parameter of reserve-memory
>   arm: cache: cp15: don't map the reserved region with no-map property
>
>  arch/arm/include/asm/system.h |   3 +
>  arch/arm/lib/cache-cp15.c |  19 ++-
>  common/image-fdt.c|  23 +---
>  include/lmb.h |  22 +++-
>  lib/lmb.c | 100 +++---
>  test/lib/lmb.c|  89 ++
>  6 files changed, 212 insertions(+), 44 deletions(-)
>
> --
> 2.17.1
>

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
>
>

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
>
>

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 

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
&

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.

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.

Re: [PATCH 1/5] arm64: PIE: Skip fixups if distance is zero

[Ard Biesheuvel]

On Thu, 24 Sep 2020 at 16:45, André Przywara  wrote:
>
> On 24/09/2020 01:17, Andre Przywara wrote:
> > When the actual offset between link and runtime address is zero, there
> > is no need for patching up U-Boot early when running with
> > CONFIG_POSITION_INDEPENDENT.
>
> That turns out to be not fully true.
> Some toolchains (all Linaro cross compilers?) don't handle this well,
> they keep the original locations in the binary uninitialised, and rely
> on the reldyn fixup table to patch in the actual values.
> Other compilers (GCC 9.2 vanilla, Ubuntu GCC 7.5.0, Arm website 9.2)
> fill in the addresses both into the binary and the fixup, so this patch
> works.
>

This was changed in binutils-2.27, to align with other architectures.
A new command line option for ld '--no-apply-dynamic-relocs' was also
added at the same time, to revert to the old behavior.

Re: [PATCH 0/5] qemu-arm64: Allow booting via Trusted Firmware

[Ard Biesheuvel]

On Thu, 24 Sep 2020 at 09:58, Amit Tomar  wrote:
>
> Hi,
>
> Andre Przywara (5):
>>
>>   arm64: PIE: Skip fixups if distance is zero
>>   arm64: PIE: Allow fixed stack pointer
>>   qemu-arm: Remove need to specify flash banks
>>   qemu: Drop ARCH_SUPPORT_TFABOOT
>>   qemu/arm64: Enable POSITION_INDEPENDENT
>>
>>  arch/arm/Kconfig | 4 ++--
>>  arch/arm/cpu/armv8/start.S   | 3 ++-
>>  configs/qemu_arm64_defconfig | 1 +
>>  include/configs/qemu-arm.h   | 8 +---
>>  4 files changed, 6 insertions(+), 10 deletions(-)
>>
>> --
>> 2.17.5
>>
>
> I tried testing this series but don't see any output while loading U-Boot 
> from ROM:
>
> # ./qemu-system-aarch64 -M virt -cpu cortex-a57 -nographic -smp 1 -bios 
> u-boot.bin
>
> strangely enough SP is having a value of 0 after execution:
>
> (qemu) info registers
>  PC=1a00 X00=54a0f100303f X01=0007c000
> X02= X03=401fe000 X04=
> X05= X06=0030 X07=401fe008
> X08= X09=1408d51e115f X10=
> X11= X12= X13=
> X14= X15= X16=
> X17= X18= X19=
> X20= X21= X22=
> X23= X24= X25=
> X26= X27= X28=
> X29=00c8 X30=1408d51e39cb  SP=
> PSTATE=03c5  EL1h FPCR= FPSR=
>
> Wondering , if I have missed something ?
>

Did you regenerate the .config? Otherwise, CONFIG_INIT_SP_RELATIVE may
still be enabled.

Re: [RFC PATCH 0/7]

[Ard Biesheuvel]

On Fri, 4 Sep 2020 at 13:51, Patrick Delaunay  wrote:
>
> arm: cache: cp15: don't map reserved region with no-map property
>
> Hi,
>
> On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region protected
> by a firewall. This region is reserved in device with "no-map" property.
>
> But sometime the platform boot failed in U-boot on a Cortex A7 access to this
> region (depending of the binary and the issue can change with compiler 
> version or
> with code alignment), then the firewall raise a error, for example:
>
> E/TC:0   tzc_it_handler:19 TZC permission failure
> E/TC:0   dump_fail_filter:420 Permission violation on filter 0
> E/TC:0   dump_fail_filter:425 Violation @0xde5c6bf0, non-secure privileged 
> read, AXI ID 5c0
> E/TC:0   Panic
>
> After investigation, the forbidden access is a speculative request performed 
> by
> the Cortex A7 because all the DDR is mapped as MEMORY with CACHEABLE property.
>
> The issue is solved only when the region reserved by OP-TEE is no more mapped
> in U-Boot (mapped as DEVICE/NON-CACHEABLE wasn't enough) as it is already done
> in Linux kernel.
>

The only speculative accesses to such regions permitted by the
architecture are instruction fetches, which is why setting the nx
attribute is required on v7 for device mappings.

Does uboot currently honour this requirement?


> I think that can be a general issue for ARM architecture: the no-map tag in
> device should be respected by U-boot, so I propose a  generic solution in
> arm/lib/cache-cp15.c:dram_bank_mmu_setup().
>
> This RFC serie is composed by 7 patches
> - 1..4/7: preliminary steps to support flags in library in lmb
>   (as it is done in memblock.c in Linux)
> - 5/7: unitary test on the added feature in lmb lib
> - 6/7: save the no-map flags in lmb when the device tree is parsed
> - 7/7: update the generic behavior for "no-map" region in
>arm/lib/cache-cp15.c::dram_bank_mmu_setup()
>
> I can change this last patch if it is required by other ARM architecture;
> it is a weak function so I can avoid to map the region with "no-map"
> property in device tree only for STM32MP architecture
> (in arch/arm/mach-stm32mp/cpu.c).
>
> See also [1] which handle same speculative access on armv8 for area
> with Executable attribute.
>
> [1] 
> http://patchwork.ozlabs.org/project/uboot/patch/20200903000106.5016-1-marek.bykow...@gmail.com/
>
> Regards
> Patrick
>
>
> Patrick Delaunay (7):
>   lmb: Add support of flags for no-map properties
>   lmb: add lmb_is_reserved_flags
>   lmb: remove lmb_region.size
>   lmb: add lmb_dump_region() function
>   test: lmb: add test for lmb_reserve_flags
>   image-fdt: save no-map parameter of reserve-memory
>   arm: cache: cp15: don't map the reserved region with no-map property
>
>  arch/arm/include/asm/system.h |   3 +
>  arch/arm/lib/cache-cp15.c |  17 +-
>  common/image-fdt.c|  23 +---
>  include/lmb.h |  22 +++-
>  lib/lmb.c | 100 +++---
>  test/lib/lmb.c|  89 ++
>  6 files changed, 210 insertions(+), 44 deletions(-)
>
> --
> 2.17.1
>

[PATCH v3 0/5] Fixes for running U-boot under QEMU/KVM

[Ard Biesheuvel]

This series fixes a number of issues that exist in the QEMU/mach-virt
port of u-boot, and that prevent it from executing correctly under
virtualization (as opposed to TCG emulation)

As the Linux EFI subsystem maintainer, I am looking to increase test
coverage for the EFI related changes that are under development for
Linux, and one of the things I plan to do is start using U-boot as
test firmware for boot testing. This can be done under TCG emulation,
but given how loosely TCG implements the architecture, it is better
to test under virtualization as well.

With these changes applied, u-boot can boot Linux in EFI mode under
KVM.

Changes since v2:
- reinstate flash write accessors (patch #5)
- rebase onto 2020.07

Changes since v1:
- fix LPAE memory type for DCACHE_WRITETHROUGH as well, and add some
  comments to clarify what the values are based on (patch #1)
- only override the flash accessors that we need to (patch #5)
- add Heinrich's ack to #2 and #4

Cc: Tom Rini 
Cc: Andre Przywara 
Cc: Heinrich Schuchardt 
Cc: Tuomas Tynkkynen 

Ard Biesheuvel (5):
  arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK/_WRITETHROUGH
  arm: qemu: enable LPAE on 32-bit
  arm: qemu: implement enable_caches()
  arm: qemu: disable the EFI workaround for older GRUB
  arm: qemu: override flash accessors to use virtualizable instructions

 arch/arm/include/asm/system.h   | 23 +++--
 board/emulation/qemu-arm/qemu-arm.c | 52 
 configs/qemu_arm_defconfig  |  2 +
 include/configs/qemu-arm.h  |  1 +
 4 files changed, 74 insertions(+), 4 deletions(-)

-- 
2.27.0

[PATCH v3 4/5] arm: qemu: disable the EFI workaround for older GRUB

[Ard Biesheuvel]

The QEMU/mach-virt targeted port of u-boot currently only runs on
QEMU under TCG emulation, which does not model the caches at all,
and so no users can exist that are relying on the GRUB hack for
EFI boot.

We will shortly enable support for running under KVM, but the GRUB
hack (which disables all caches without doing cache cleaning by VA
during ExitBootServices()) is likely to cause more problems than it
solves, given that KVM hosts require correct maintenance if they
incorporate non-architected system caches.

So let's disable the GRUB hack by default on the QEMU/mach-virt
port.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Heinrich Schuchardt 
---
 configs/qemu_arm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index 75bdce7708c7..1d2b4437cb07 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -47,3 +47,4 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_PCI=y
+# CONFIG_EFI_GRUB_ARM32_WORKAROUND is not set
-- 
2.27.0

[PATCH v3 2/5] arm: qemu: enable LPAE on 32-bit

[Ard Biesheuvel]

QEMU's mach-virt machine only supports selecting CPU models that
implement the virtualization extensions, and are therefore guaranteed
to support LPAE as well.

Initially, QEMU would not allow emulating these CPUs running in HYP
mode (or EL2, for AArch64), but today, it also contains a complete
implementation of the virtualization extensions themselves.

This means we could be running U-Boot in HYP mode, in which case the
LPAE long descriptor page table format is the only format that is
supported. If we are not running in HYP mode, we can use either.

So let's enable CONFIG_ARMV7_LPAE for qemu_arm_defconfig so that we
get the best support for running with the MMU and caches enabled at
any privilege level.

Signed-off-by: Ard Biesheuvel 
Acked-by: Heinrich Schuchardt 
---
 configs/qemu_arm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index a8473988bd76..75bdce7708c7 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARM_SMCCC=y
+CONFIG_ARMV7_LPAE=y
 CONFIG_ARCH_QEMU=y
 CONFIG_ENV_SIZE=0x4
 CONFIG_ENV_SECT_SIZE=0x4
-- 
2.27.0

[PATCH v3 5/5] arm: qemu: override flash accessors to use virtualizable instructions

[Ard Biesheuvel]

Some instructions in the ARM ISA have multiple output registers, such
as ldrd/ldp (load pair), where two registers are loaded from memory,
but also ldr with indexing, where the memory base register is incremented
as well when the value is loaded to the destination register.

MMIO emulation under KVM is based on using the architecturally defined
syndrome information that is provided when an exception is taken to the
hypervisor. This syndrome information describes whether the instruction
that triggered the exception is a load or a store, what the faulting
address was, and which register was the destination register.

This syndrome information can only describe one destination register, and
when the trapping instruction is one with multiple outputs, KVM throws an
error like

  kvm [615929]: Data abort outside memslots with no valid syndrome info

on the host and kills the QEMU process with the following error:

  U-Boot 2020.07-rc3-00208-g88bd5b179360-dirty (Jun 06 2020 - 11:59:22 +0200)

  DRAM:  1 GiB
  Flash: error: kvm run failed Function not implemented
  R00=0001 R01=0040 R02=7ee0ce20 R03=
  R04=7ffd9eec R05=0004 R06=7ffda3f8 R07=0055
  R08=7ffd9eec R09=7ef0ded0 R10=7ee0ce20 R11=
  R12=0004 R13=7ee0cdf8 R14= R15=7ff72d08
  PSR=21d3 --C- A svc32
  QEMU: Terminated

This means that, in order to run U-Boot in QEMU under KVM, we need to
avoid such instructions when accessing emulated devices. For the flash
in particular, which is a hybrid between a ROM (backed by a read-only
KVM memslot) when in array mode, and an emulated MMIO device (when in
write mode), we need to take care to only use instructions that KVM can
deal with when they trap.

So override the flash read accessors that are used when running on QEMU
under KVM. Note that the the 64-bit wide read and write accessors have
been omitted: they are never used when running under QEMU given that it
does not emulate CFI flash that supports it.

Signed-off-by: Ard Biesheuvel 
---
 board/emulation/qemu-arm/qemu-arm.c | 45 
 include/configs/qemu-arm.h  |  1 +
 2 files changed, 46 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c 
b/board/emulation/qemu-arm/qemu-arm.c
index 1b0d543b93c1..f18f2ed7da3a 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -142,3 +142,48 @@ efi_status_t platform_get_rng_device(struct udevice **dev)
return EFI_SUCCESS;
 }
 #endif /* CONFIG_EFI_RNG_PROTOCOL */
+
+#ifdef CONFIG_ARM64
+#define __W"w"
+#else
+#define __W
+#endif
+
+u8 flash_read8(void *addr)
+{
+   u8 ret;
+
+   asm("ldrb %" __W "0, %1" : "=r"(ret) : "m"(*(u8 *)addr));
+   return ret;
+}
+
+u16 flash_read16(void *addr)
+{
+   u16 ret;
+
+   asm("ldrh %" __W "0, %1" : "=r"(ret) : "m"(*(u16 *)addr));
+   return ret;
+}
+
+u32 flash_read32(void *addr)
+{
+   u32 ret;
+
+   asm("ldr %" __W "0, %1" : "=r"(ret) : "m"(*(u32 *)addr));
+   return ret;
+}
+
+void flash_write8(u8 value, void *addr)
+{
+   asm("strb %" __W "1, %0" : "=m"(*(u8 *)addr) : "r"(value));
+}
+
+void flash_write16(u16 value, void *addr)
+{
+   asm("strh %" __W "1, %0" : "=m"(*(u16 *)addr) : "r"(value));
+}
+
+void flash_write32(u32 value, void *addr)
+{
+   asm("str %" __W "1, %0" : "=m"(*(u32 *)addr) : "r"(value));
+}
diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index 1ef75a87836b..bc8b7c5c1238 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -53,5 +53,6 @@
 #define CONFIG_SYS_MAX_FLASH_BANKS 2
 #endif
 #define CONFIG_SYS_MAX_FLASH_SECT  256 /* Sector: 256K, Bank: 64M */
+#define CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
 
 #endif /* __CONFIG_H */
-- 
2.27.0

[PATCH v3 1/5] arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK/_WRITETHROUGH

[Ard Biesheuvel]

The LPAE versions of DCACHE_WRITEBACK and DCACHE_WRITETHROUGH are currently
defined as no-allocate for both reads and writes, which deviates from the
non-LPAE definition, and mostly defeats the purpose of enabling the caches
in the first place.

So align LPAE with !LPAE, and enable allocate-on-read for both. And while
at it, add some clarification about the meaning of the chosen values.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/include/asm/system.h | 23 
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 7a40b56acdca..3a1501a0623c 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -442,10 +442,16 @@ static inline void set_dacr(unsigned int val)
 #define TTBCR_EPD0 (0 << 7)
 
 /*
- * Memory types
+ * VMSAv8-32 Long-descriptor format memory region attributes
+ * (ARM Architecture Reference Manual section G5.7.4 [DDI0487E.a])
+ *
+ * MAIR0[ 7: 0] 0x00 Device-nGnRnE (aka Strongly-Ordered)
+ * MAIR0[15: 8] 0xaa Outer/Inner Write-Through, Read-Allocate No Write-Allocate
+ * MAIR0[23:16] 0xee Outer/Inner Write-Back, Read-Allocate No Write-Allocate
+ * MAIR0[31:24] 0xff Outer/Inner Write-Back, Read-Allocate Write-Allocate
  */
-#define MEMORY_ATTRIBUTES  ((0x00 << (0 * 8)) | (0x88 << (1 * 8)) | \
-(0xcc << (2 * 8)) | (0xff << (3 * 8)))
+#define MEMORY_ATTRIBUTES  ((0x00 << (0 * 8)) | (0xaa << (1 * 8)) | \
+(0xee << (2 * 8)) | (0xff << (3 * 8)))
 
 /* options available for data cache on each page */
 enum dcache_option {
@@ -468,7 +474,16 @@ enum dcache_option {
 #define TTB_SECT_B_MASK(1 << 2)
 #define TTB_SECT   (2 << 0)
 
-/* options available for data cache on each page */
+/*
+ * Short-descriptor format memory region attributes, without TEX remap
+ * (ARM Architecture Reference Manual section G5.7.2 [DDI0487E.a])
+ *
+ * TEX[0] C  B
+ *   00  0   Device-nGnRnE (aka Strongly-Ordered)
+ *   01  0   Outer/Inner Write-Through, Read-Allocate No Write-Allocate
+ *   01  1   Outer/Inner Write-Back, Read-Allocate No Write-Allocate
+ *   11  1   Outer/Inner Write-Back, Read-Allocate Write-Allocate
+ */
 enum dcache_option {
DCACHE_OFF = TTB_SECT_DOMAIN(0) | TTB_SECT_XN_MASK | TTB_SECT,
DCACHE_WRITETHROUGH = DCACHE_OFF | TTB_SECT_C_MASK,
-- 
2.27.0

[PATCH v3 3/5] arm: qemu: implement enable_caches()

[Ard Biesheuvel]

Add an override for enable_caches to enable the I and D caches, along
with the cached 1:1 mapping of all of DRAM. This is needed for running
U-Boot under virtualization with QEMU/kvm.

Signed-off-by: Ard Biesheuvel 
---
 board/emulation/qemu-arm/qemu-arm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c 
b/board/emulation/qemu-arm/qemu-arm.c
index 69e8ef46f1f5..1b0d543b93c1 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -94,6 +95,12 @@ void *board_fdt_blob_setup(void)
return (void *)CONFIG_SYS_SDRAM_BASE;
 }
 
+void enable_caches(void)
+{
+icache_enable();
+dcache_enable();
+}
+
 #if defined(CONFIG_EFI_RNG_PROTOCOL)
 #include 
 #include 
-- 
2.27.0

Re: [PATCH v2 5/5] arm: qemu: override flash accessors to use virtualizable instructions

[Ard Biesheuvel]

On Thu, 11 Jun 2020 at 10:17, Ard Biesheuvel  wrote:
>
> Some instructions in the ARM ISA have multiple output registers, such
> as ldrd/ldp (load pair), where two registers are loaded from memory,
> but also ldr with indexing, where the memory base register is incremented
> as well when the value is loaded to the destination register.
>
> MMIO emulation under KVM is based on using the architecturally defined
> syndrome information that is provided when an exception is taken to the
> hypervisor. This syndrome information describes whether the instruction
> that triggered the exception is a load or a store, what the faulting
> address was, and which register was the destination register.
>
> This syndrome information can only describe one destination register, and
> when the trapping instruction is one with multiple outputs, KVM throws an
> error like
>
>   kvm [615929]: Data abort outside memslots with no valid syndrome info
>
> on the host and kills the QEMU process with the following error:
>
>   U-Boot 2020.07-rc3-00208-g88bd5b179360-dirty (Jun 06 2020 - 11:59:22 +0200)
>
>   DRAM:  1 GiB
>   Flash: error: kvm run failed Function not implemented
>   R00=0001 R01=0040 R02=7ee0ce20 R03=
>   R04=7ffd9eec R05=0004 R06=7ffda3f8 R07=0055
>   R08=7ffd9eec R09=7ef0ded0 R10=7ee0ce20 R11=
>   R12=0004 R13=7ee0cdf8 R14= R15=7ff72d08
>   PSR=21d3 --C- A svc32
>   QEMU: Terminated
>
> This means that, in order to run U-Boot in QEMU under KVM, we need to
> avoid such instructions when accessing emulated devices. For the flash
> in particular, which is a hybrid between a ROM (backed by a read-only
> KVM memslot) when in array mode, and an emulated MMIO device (when in
> write mode), we need to take care to only use instructions that KVM can
> deal with when they trap.
>
> So override the flash read accessors that are used when running on QEMU
> under KVM. Note that the the 64-bit wide read accessors and all the write
> accessors have been omitted: they are either never used to begin with, or
> don't suffer from the MMIO emulation issue (as str instructions don't have
> multiple output registers)
>

This is inaccurate: str instructions do not have multiple output
registers, but they may have an output register (for pre/post
increment) as well as an input register (for the value being stored),
and this cannot be described by the syndrome information. So I will
need to respin this once more.


> Signed-off-by: Ard Biesheuvel 
> ---
>  board/emulation/qemu-arm/qemu-arm.c | 30 
>  include/configs/qemu-arm.h  |  1 +
>  2 files changed, 31 insertions(+)
>
> diff --git a/board/emulation/qemu-arm/qemu-arm.c 
> b/board/emulation/qemu-arm/qemu-arm.c
> index 1b0d543b93c1..524e302001ec 100644
> --- a/board/emulation/qemu-arm/qemu-arm.c
> +++ b/board/emulation/qemu-arm/qemu-arm.c
> @@ -142,3 +142,33 @@ efi_status_t platform_get_rng_device(struct udevice 
> **dev)
> return EFI_SUCCESS;
>  }
>  #endif /* CONFIG_EFI_RNG_PROTOCOL */
> +
> +#ifdef CONFIG_ARM64
> +#define __W"w"
> +#else
> +#define __W
> +#endif
> +
> +u8 flash_read8(void *addr)
> +{
> +   u8 ret;
> +
> +   asm("ldrb %" __W "0, %1" : "=r"(ret) : "m"(*(u8 *)addr));
> +   return ret;
> +}
> +
> +u16 flash_read16(void *addr)
> +{
> +   u16 ret;
> +
> +   asm("ldrh %" __W "0, %1" : "=r"(ret) : "m"(*(u16 *)addr));
> +   return ret;
> +}
> +
> +u32 flash_read32(void *addr)
> +{
> +   u32 ret;
> +
> +   asm("ldr %" __W "0, %1" : "=r"(ret) : "m"(*(u32 *)addr));
> +   return ret;
> +}
> diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
> index 1ef75a87836b..bc8b7c5c1238 100644
> --- a/include/configs/qemu-arm.h
> +++ b/include/configs/qemu-arm.h
> @@ -53,5 +53,6 @@
>  #define CONFIG_SYS_MAX_FLASH_BANKS 2
>  #endif
>  #define CONFIG_SYS_MAX_FLASH_SECT  256 /* Sector: 256K, Bank: 64M */
> +#define CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
>
>  #endif /* __CONFIG_H */
> --
> 2.26.2
>

[PATCH v2 5/5] arm: qemu: override flash accessors to use virtualizable instructions

[Ard Biesheuvel]

Some instructions in the ARM ISA have multiple output registers, such
as ldrd/ldp (load pair), where two registers are loaded from memory,
but also ldr with indexing, where the memory base register is incremented
as well when the value is loaded to the destination register.

MMIO emulation under KVM is based on using the architecturally defined
syndrome information that is provided when an exception is taken to the
hypervisor. This syndrome information describes whether the instruction
that triggered the exception is a load or a store, what the faulting
address was, and which register was the destination register.

This syndrome information can only describe one destination register, and
when the trapping instruction is one with multiple outputs, KVM throws an
error like

  kvm [615929]: Data abort outside memslots with no valid syndrome info

on the host and kills the QEMU process with the following error:

  U-Boot 2020.07-rc3-00208-g88bd5b179360-dirty (Jun 06 2020 - 11:59:22 +0200)

  DRAM:  1 GiB
  Flash: error: kvm run failed Function not implemented
  R00=0001 R01=0040 R02=7ee0ce20 R03=
  R04=7ffd9eec R05=0004 R06=7ffda3f8 R07=0055
  R08=7ffd9eec R09=7ef0ded0 R10=7ee0ce20 R11=
  R12=0004 R13=7ee0cdf8 R14= R15=7ff72d08
  PSR=21d3 --C- A svc32
  QEMU: Terminated

This means that, in order to run U-Boot in QEMU under KVM, we need to
avoid such instructions when accessing emulated devices. For the flash
in particular, which is a hybrid between a ROM (backed by a read-only
KVM memslot) when in array mode, and an emulated MMIO device (when in
write mode), we need to take care to only use instructions that KVM can
deal with when they trap.

So override the flash read accessors that are used when running on QEMU
under KVM. Note that the the 64-bit wide read accessors and all the write
accessors have been omitted: they are either never used to begin with, or
don't suffer from the MMIO emulation issue (as str instructions don't have
multiple output registers)

Signed-off-by: Ard Biesheuvel 
---
 board/emulation/qemu-arm/qemu-arm.c | 30 
 include/configs/qemu-arm.h  |  1 +
 2 files changed, 31 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c 
b/board/emulation/qemu-arm/qemu-arm.c
index 1b0d543b93c1..524e302001ec 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -142,3 +142,33 @@ efi_status_t platform_get_rng_device(struct udevice **dev)
return EFI_SUCCESS;
 }
 #endif /* CONFIG_EFI_RNG_PROTOCOL */
+
+#ifdef CONFIG_ARM64
+#define __W"w"
+#else
+#define __W
+#endif
+
+u8 flash_read8(void *addr)
+{
+   u8 ret;
+
+   asm("ldrb %" __W "0, %1" : "=r"(ret) : "m"(*(u8 *)addr));
+   return ret;
+}
+
+u16 flash_read16(void *addr)
+{
+   u16 ret;
+
+   asm("ldrh %" __W "0, %1" : "=r"(ret) : "m"(*(u16 *)addr));
+   return ret;
+}
+
+u32 flash_read32(void *addr)
+{
+   u32 ret;
+
+   asm("ldr %" __W "0, %1" : "=r"(ret) : "m"(*(u32 *)addr));
+   return ret;
+}
diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index 1ef75a87836b..bc8b7c5c1238 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -53,5 +53,6 @@
 #define CONFIG_SYS_MAX_FLASH_BANKS 2
 #endif
 #define CONFIG_SYS_MAX_FLASH_SECT  256 /* Sector: 256K, Bank: 64M */
+#define CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
 
 #endif /* __CONFIG_H */
-- 
2.26.2

[PATCH v2 3/5] arm: qemu: implement enable_caches()

[Ard Biesheuvel]

Add an override for enable_caches to enable the I and D caches, along
with the cached 1:1 mapping of all of DRAM. This is needed for running
U-Boot under virtualization with QEMU/kvm.

Signed-off-by: Ard Biesheuvel 
---
 board/emulation/qemu-arm/qemu-arm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c 
b/board/emulation/qemu-arm/qemu-arm.c
index 69e8ef46f1f5..1b0d543b93c1 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -94,6 +95,12 @@ void *board_fdt_blob_setup(void)
return (void *)CONFIG_SYS_SDRAM_BASE;
 }
 
+void enable_caches(void)
+{
+icache_enable();
+dcache_enable();
+}
+
 #if defined(CONFIG_EFI_RNG_PROTOCOL)
 #include 
 #include 
-- 
2.26.2

[PATCH v2 4/5] arm: qemu: disable the EFI workaround for older GRUB

[Ard Biesheuvel]

The QEMU/mach-virt targeted port of u-boot currently only runs on
QEMU under TCG emulation, which does not model the caches at all,
and so no users can exist that are relying on the GRUB hack for
EFI boot.

We will shortly enable support for running under KVM, but the GRUB
hack (which disables all caches without doing cache cleaning by VA
during ExitBootServices()) is likely to cause more problems than it
solves, given that KVM hosts require correct maintenance if they
incorporate non-architected system caches.

So let's disable the GRUB hack by default on the QEMU/mach-virt
port.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Heinrich Schuchardt 
---
 configs/qemu_arm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index 75bdce7708c7..1d2b4437cb07 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -47,3 +47,4 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_PCI=y
+# CONFIG_EFI_GRUB_ARM32_WORKAROUND is not set
-- 
2.26.2

[PATCH v2 2/5] arm: qemu: enable LPAE on 32-bit

[Ard Biesheuvel]

QEMU's mach-virt machine only supports selecting CPU models that
implement the virtualization extensions, and are therefore guaranteed
to support LPAE as well.

Initially, QEMU would not allow emulating these CPUs running in HYP
mode (or EL2, for AArch64), but today, it also contains a complete
implementation of the virtualization extensions themselves.

This means we could be running U-Boot in HYP mode, in which case the
LPAE long descriptor page table format is the only format that is
supported. If we are not running in HYP mode, we can use either.

So let's enable CONFIG_ARMV7_LPAE for qemu_arm_defconfig so that we
get the best support for running with the MMU and caches enabled at
any privilege level.

Signed-off-by: Ard Biesheuvel 
Acked-by: Heinrich Schuchardt 
---
 configs/qemu_arm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index a8473988bd76..75bdce7708c7 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARM_SMCCC=y
+CONFIG_ARMV7_LPAE=y
 CONFIG_ARCH_QEMU=y
 CONFIG_ENV_SIZE=0x4
 CONFIG_ENV_SECT_SIZE=0x4
-- 
2.26.2

[PATCH v2 1/5] arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK/_WRITETHROUGH

[Ard Biesheuvel]

The LPAE versions of DCACHE_WRITEBACK and DCACHE_WRITETHROUGH are currently
defined as no-allocate for both reads and writes, which deviates from the
non-LPAE definition, and mostly defeats the purpose of enabling the caches
in the first place.

So align LPAE with !LPAE, and enable allocate-on-read for both. And while
at it, add some clarification about the meaning of the chosen values.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/include/asm/system.h | 23 
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 7a40b56acdca..3a1501a0623c 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -442,10 +442,16 @@ static inline void set_dacr(unsigned int val)
 #define TTBCR_EPD0 (0 << 7)
 
 /*
- * Memory types
+ * VMSAv8-32 Long-descriptor format memory region attributes
+ * (ARM Architecture Reference Manual section G5.7.4 [DDI0487E.a])
+ *
+ * MAIR0[ 7: 0] 0x00 Device-nGnRnE (aka Strongly-Ordered)
+ * MAIR0[15: 8] 0xaa Outer/Inner Write-Through, Read-Allocate No Write-Allocate
+ * MAIR0[23:16] 0xee Outer/Inner Write-Back, Read-Allocate No Write-Allocate
+ * MAIR0[31:24] 0xff Outer/Inner Write-Back, Read-Allocate Write-Allocate
  */
-#define MEMORY_ATTRIBUTES  ((0x00 << (0 * 8)) | (0x88 << (1 * 8)) | \
-(0xcc << (2 * 8)) | (0xff << (3 * 8)))
+#define MEMORY_ATTRIBUTES  ((0x00 << (0 * 8)) | (0xaa << (1 * 8)) | \
+(0xee << (2 * 8)) | (0xff << (3 * 8)))
 
 /* options available for data cache on each page */
 enum dcache_option {
@@ -468,7 +474,16 @@ enum dcache_option {
 #define TTB_SECT_B_MASK(1 << 2)
 #define TTB_SECT   (2 << 0)
 
-/* options available for data cache on each page */
+/*
+ * Short-descriptor format memory region attributes, without TEX remap
+ * (ARM Architecture Reference Manual section G5.7.2 [DDI0487E.a])
+ *
+ * TEX[0] C  B
+ *   00  0   Device-nGnRnE (aka Strongly-Ordered)
+ *   01  0   Outer/Inner Write-Through, Read-Allocate No Write-Allocate
+ *   01  1   Outer/Inner Write-Back, Read-Allocate No Write-Allocate
+ *   11  1   Outer/Inner Write-Back, Read-Allocate Write-Allocate
+ */
 enum dcache_option {
DCACHE_OFF = TTB_SECT_DOMAIN(0) | TTB_SECT_XN_MASK | TTB_SECT,
DCACHE_WRITETHROUGH = DCACHE_OFF | TTB_SECT_C_MASK,
-- 
2.26.2

[PATCH v2 0/5] Fixes for running U-boot under QEMU/KVM

[Ard Biesheuvel]

This series fixes a number of issues that exist in the QEMU/mach-virt
port of u-boot, and that prevent it from executing correctly under
virtualization (as opposed to TCG emulation)

As the Linux EFI subsystem maintainer, I am looking to increase test
coverage for the EFI related changes that are under development for
Linux, and one of the things I plan to do is start using U-boot as
test firmware for boot testing. This can be done under TCG emulation,
but given how loosely TCG implements the architecture, it is better
to test under virtualization as well.

With these changes applied, u-boot can boot Linux in EFI mode under
KVM.

Changes since v1:
- fix LPAE memory type for DCACHE_WRITETHROUGH as well, and add some
  comments to clarify what the values are based on (patch #1)
- only override the flash accessors that we need to (patch #5)
- add Heinrich's ack to #2 and #4

Cc: Tom Rini 
Cc: Andre Przywara 
Cc: Heinrich Schuchardt 
Cc: Tuomas Tynkkynen 

Ard Biesheuvel (5):
  arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK/_WRITETHROUGH
  arm: qemu: enable LPAE on 32-bit
  arm: qemu: implement enable_caches()
  arm: qemu: disable the EFI workaround for older GRUB
  arm: qemu: override flash accessors to use virtualizable instructions

 arch/arm/include/asm/system.h   | 23 +---
 board/emulation/qemu-arm/qemu-arm.c | 37 
 configs/qemu_arm_defconfig  |  2 ++
 include/configs/qemu-arm.h  |  1 +
 4 files changed, 59 insertions(+), 4 deletions(-)

-- 
2.26.2

Re: [PATCH 2/5] arm: qemu: enable LPAE on 32-bit

[Ard Biesheuvel]

On Sun, 7 Jun 2020 at 13:03, Heinrich Schuchardt  wrote:
>
> Am June 7, 2020 8:59:00 AM UTC schrieb Ard Biesheuvel :
> >On Sat, 6 Jun 2020 at 22:49, Heinrich Schuchardt 
> >wrote:
> >>
> >> On 6/6/20 10:32 PM, Heinrich Schuchardt wrote:
> >> > On 6/6/20 7:15 PM, Ard Biesheuvel wrote:
> >> >> QEMU's mach-virt machine only supports selecting CPU models that
> >> >> implement the virtualization extensions, and are therefore
> >guaranteed
> >> >> to support LPAE as well.
> >> >
> >> > I wonder why
> >> > qemu-system-arm -machine virt -cpu help
> >> > lists cortex-a9 (which is not LPAE enabled).
> >> >
> >> > But when I try to use it I get
> >> > qemu-system-arm: mach-virt: CPU type cortex-a9-arm-cpu not
> >supported
> >> > This looks like a missing feature in QEMU.
> >> >
> >
> >This is not a missing feature. The virt board uses PSCI for powerdown
> >and reset, and to bring up secondary cores.
> >PSCI requires the HVC instruction, which is only available if the virt
> >extensions are implemented.
>
> By missing feature I meant  -cpu help output should be filtered according to 
> the -machine value if provided.
>


Ah fair enough. Yes, that would be useful.

Unfortunately, ARM does not permit me to contribute to QEMU, so
hopefully someone else can take this on.

Re: [PATCH 2/5] arm: qemu: enable LPAE on 32-bit

[Ard Biesheuvel]

On Sat, 6 Jun 2020 at 22:49, Heinrich Schuchardt  wrote:
>
> On 6/6/20 10:32 PM, Heinrich Schuchardt wrote:
> > On 6/6/20 7:15 PM, Ard Biesheuvel wrote:
> >> QEMU's mach-virt machine only supports selecting CPU models that
> >> implement the virtualization extensions, and are therefore guaranteed
> >> to support LPAE as well.
> >
> > I wonder why
> > qemu-system-arm -machine virt -cpu help
> > lists cortex-a9 (which is not LPAE enabled).
> >
> > But when I try to use it I get
> > qemu-system-arm: mach-virt: CPU type cortex-a9-arm-cpu not supported
> > This looks like a missing feature in QEMU.
> >

This is not a missing feature. The virt board uses PSCI for powerdown
and reset, and to bring up secondary cores.
PSCI requires the HVC instruction, which is only available if the virt
extensions are implemented.

So emulating CPUs without the virt extensions would require a
replacement for PSCI to be implemented as well, which seems rather
pointless to me.

> > The default CPU for machine=virt is arm,cortex-a15.
> >
> > Acked-by: Heinrich Schuchardt  >

Thanks.

> >>
> >> Initially, QEMU would not allow emulating these CPUs running in HYP
> >> mode (or EL2, for AArch64), but today, it also contains a complete
> >> implementation of the virtualization extensions themselves.
> >>
> >> This means we could be running U-Boot in HYP mode, in which case the
> >> LPAE long descriptor page table format is the only format that is
> >> supported. If we are not running in HYP mode, we can use either.
> >>
> >> So let's enable CONFIG_ARMV7_LPAE for qemu_arm_defconfig so that we
> >> get the best support for running with the MMU and caches enabled at
> >> any privilege level.
> >>
> >> Signed-off-by: Ard Biesheuvel 
>
> You missed to CC the maintainer of QEMU ARM 'VIRT' BOARD. - We have
> scripts/get_maintainer.pl to find the maintainers.
>
> Cc: Tuomas Tynkkynen 
>

Apologies. I will cc Tuomas for v2.

Re: [PATCH 1/5] arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK

[Ard Biesheuvel]

On Sat, 6 Jun 2020 at 22:14, Heinrich Schuchardt  wrote:
>
> On 6/6/20 7:15 PM, Ard Biesheuvel wrote:
> > The LPAE version of DCACHE_WRITEBACK is currently defined as no-allocate
> > for both reads and writes, which deviates from the non-LPAE definition,
> > and mostly defeats the purpose of enabling the caches in the first place.
> >
> > So align LPAE with !LPAE, and enable allocate-on-read.
>
> Hello Ard,
>
> thanks for analyzing why booting Linux on QEMU fails in some scenarios.
>
> Do you know where in U-Boot is the value for !LPAE is defined?
>

Non-LPAE ARMV7A has (in arch/arm/include/asm/system.h)

DCACHE_WRITETHROUGH = DCACHE_OFF | TTB_SECT_C_MASK,
DCACHE_WRITEBACK = DCACHE_WRITETHROUGH | TTB_SECT_B_MASK,
DCACHE_WRITEALLOC = DCACHE_WRITEBACK | TTB_SECT_TEX(1),

and so DCACHE_WRITEBACK has the C and B bits set in the block
descriptor, and the TEX field set to 0x0

G5.7.2 in the ARM ARM (DDI0487E.a) describes this as

Outer and Inner Write-Back, Read-Allocate
No Write-Allocate

DCACHE_WRITEALLOC has the C and B bits set in the block descriptor,
and the TEX field set to 0x1, which is described as

Outer and Inner Write-Back, Read-Allocate Write-Allocate

> >
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  arch/arm/include/asm/system.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> > index 7a40b56acdca..21b26557d28b 100644
> > --- a/arch/arm/include/asm/system.h
> > +++ b/arch/arm/include/asm/system.h
> > @@ -445,7 +445,7 @@ static inline void set_dacr(unsigned int val)
> >   * Memory types
> >   */
>
> To me the lines below look like black magic.
>
> In the comment above the definition, please, add a reference explaining
> where the values are defined and a comment explaining why the actual
> values are chosen.
>
> Maybe this could be a starting point for the description:
>
> "This constant is used define memory attribute encodings in a
> Long-descriptor format translation table entry for stage 1 translations.
> It is used to set the Memory Attribute Indirection Registers MAIR and
> HMAIR. For details see [1,2].
>
> [1] MAIR0, Memory Attribute Indirection Register 0
>
> https://developer.arm.com/docs/ddi0595/b/aarch32-system-registers/mair0/a/DDI0568A_b_armv8_r_supplement.pdf
> [2] HMAIR0, Hyp Memory Attribute Indirection Register 0
>
> https://developer.arm.com/docs/ddi0595/b/aarch32-system-registers/hmair0 "
>

Better refer to the ARM ARM for the A profile here (not R). [DDI0487E.a]

So the memory types are indexed: four fields of MAIR are populated
with the four chosen memory types:

[0] Device-nGnrnE
[1] Outer and Inner Write-Through, Read-Allocate No Write-Allocate
[2] Outer and Inner Write-Back, Read-Allocate No Write-Allocate
[3] Outer and Inner Write-Back, Read-Allocate Write-Allocate

and the enum just selects one of these fields:

DCACHE_OFF = TTB_SECT | TTB_SECT_MAIR(0) | TTB_SECT_XN_MASK,
DCACHE_WRITETHROUGH = TTB_SECT | TTB_SECT_MAIR(1),
DCACHE_WRITEBACK = TTB_SECT | TTB_SECT_MAIR(2),
DCACHE_WRITEALLOC = TTB_SECT | TTB_SECT_MAIR(3),

BTW it seems DCACHE_WRITETHROUGH is also incorrect: this should be
0xaa for read-allocate as well.


> >  #define MEMORY_ATTRIBUTES((0x00 << (0 * 8)) | (0x88 << (1 * 8)) | \
> > -  (0xcc << (2 * 8)) | (0xff << (3 * 8)))
> > +  (0xee << (2 * 8)) | (0xff << (3 * 8)))
> >
> >  /* options available for data cache on each page */
> >  enum dcache_option {
> >
>

Re: [PATCH 5/5] arm: qemu: override flash accessors to use virtualizable instructions

[Ard Biesheuvel]

On Sat, 6 Jun 2020 at 23:08, Heinrich Schuchardt  wrote:
>
> On 6/6/20 7:15 PM, Ard Biesheuvel wrote:
> > Some instructions in the ARM ISA have multiple output registers, such
> > as ldrd/ldp (load pair), where two registers are loaded from memory,
> > but also ldr with indexing, where the memory base register is incremented
> > as well when the value is loaded to the destination register.
> >
> > MMIO emulation under KVM is based on using the architecturally defined
> > syndrome information that is provided when an exception is taken to the
> > hypervisor. This syndrome information describes whether the instruction
> > that triggered the exception is a load or a store, what the faulting
> > address was, and which register was the destination register.
> >
> > This syndrome information can only describe one destination register, and
> > when the trapping instruction is one with multiple outputs, KVM throws an
> > error like
> >
> >   kvm [615929]: Data abort outside memslots with no valid syndrome info
> >
> > on the host and kills the QEMU process with the following error:
> >
> >   U-Boot 2020.07-rc3-00208-g88bd5b179360-dirty (Jun 06 2020 - 11:59:22 
> > +0200)
> >
> >   DRAM:  1 GiB
> >   Flash: error: kvm run failed Function not implemented
> >   R00=0001 R01=0040 R02=7ee0ce20 R03=
> >   R04=7ffd9eec R05=0004 R06=7ffda3f8 R07=0055
> >   R08=7ffd9eec R09=7ef0ded0 R10=7ee0ce20 R11=
> >   R12=0004 R13=7ee0cdf8 R14= R15=7ff72d08
> >   PSR=21d3 --C- A svc32
> >   QEMU: Terminated
> >
> > This means that, in order to run U-Boot in QEMU under KVM, we need to
> > avoid such instructions when accessing emulated devices. For the flash
> > in particular, which is a hybrid between a ROM (backed by a memslot)
> > when in array mode, and an emulated MMIO device (when in write mode),
> > we need to take care to only use instructions that KVM can deal with
> > when they trap.
> >
> > So override the flash accessors that are used when running on QEMU.
> > Note that the write accessors are included for completeness, but the
> > read accessors are the ones that need this special care.
> >
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  board/emulation/qemu-arm/qemu-arm.c | 55 
> >  include/configs/qemu-arm.h  |  1 +
> >  2 files changed, 56 insertions(+)
> >
> > diff --git a/board/emulation/qemu-arm/qemu-arm.c 
> > b/board/emulation/qemu-arm/qemu-arm.c
> > index 1b0d543b93c1..32e18fd8b985 100644
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
> > @@ -142,3 +142,58 @@ efi_status_t platform_get_rng_device(struct udevice 
> > **dev)
> >   return EFI_SUCCESS;
> >  }
> >  #endif /* CONFIG_EFI_RNG_PROTOCOL */
> > +
> > +#ifdef CONFIG_ARM64
> > +#define __W  "w"
> > +#else
> > +#define __W
> > +#endif
> > +
> > +void flash_write8(u8 value, void *addr)
> > +{
> > + asm("strb %" __W "1, %0" : "=m"(*(u8 *)addr) : "r"(value));
> > +}
> > +
> > +void flash_write16(u16 value, void *addr)
> > +{
> > + asm("strh %" __W "1, %0" : "=m"(*(u16 *)addr) : "r"(value));
> > +}
> > +
> > +void flash_write32(u32 value, void *addr)
> > +{
> > + asm("str %" __W "1, %0" : "=m"(*(u32 *)addr) : "r"(value));
> > +}
> > +
> > +void flash_write64(u64 value, void *addr)
> > +{
> > + BUG(); /* FLASH_CFI_64BIT is not implemented by QEMU */
>
> Why should this BUG() on aarch64?

QEMU's CFI emulation does not implement 8 byte width, so there is no
point in implementing this accessor, as it will never be called
anyway.

The BUG() is there to ensure that *if* QEMU ever does get support for
8 byte wide CFI flash, we notice immediately, rather than having to
debug weird failures.

> Why is panicking in U-Boot better than crashing in QEMU?

Because U-boot crashes in the guest, while QEMU crashes in the host.

> Why can't this be realized as two 32bit writes?
>

It could be but there is no point: QEMU will never exercise this code
path anyway.

> This seems to be wrong:
> drivers/mtd/cfi_flash.c:179:
> /* No architectures currently implement __raw_readq() */
>
> I find definitions for all architectures.
>
> So shouldn't you correct cfi_flash.c and override __arch_getq() and
> __arch_putq() instead?
>

If anyone wants to fix 8 byte CFI, the

[PATCH 4/5] arm: qemu: disable the EFI workaround for older GRUB

[Ard Biesheuvel]

The QEMU/mach-virt targeted port of u-boot currently only runs on
QEMU under TCG emulation, which does not model the caches at all,
and so no users can exist that are relying on the GRUB hack for
EFI boot.

We will shortly enable support for running under KVM, but the GRUB
hack (which disables all caches without doing cache cleaning by VA
during ExitBootServices()) is likely to cause more problems than it
solves, given that KVM hosts require correct maintenance if they
incorporate non-architected system caches.

So let's disable the GRUB hack by default on the QEMU/mach-virt
port.

Signed-off-by: Ard Biesheuvel 
---
 configs/qemu_arm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index 75bdce7708c7..1d2b4437cb07 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -47,3 +47,4 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_PCI=y
+# CONFIG_EFI_GRUB_ARM32_WORKAROUND is not set
-- 
2.26.2

[PATCH 5/5] arm: qemu: override flash accessors to use virtualizable instructions

[Ard Biesheuvel]

Some instructions in the ARM ISA have multiple output registers, such
as ldrd/ldp (load pair), where two registers are loaded from memory,
but also ldr with indexing, where the memory base register is incremented
as well when the value is loaded to the destination register.

MMIO emulation under KVM is based on using the architecturally defined
syndrome information that is provided when an exception is taken to the
hypervisor. This syndrome information describes whether the instruction
that triggered the exception is a load or a store, what the faulting
address was, and which register was the destination register.

This syndrome information can only describe one destination register, and
when the trapping instruction is one with multiple outputs, KVM throws an
error like

  kvm [615929]: Data abort outside memslots with no valid syndrome info

on the host and kills the QEMU process with the following error:

  U-Boot 2020.07-rc3-00208-g88bd5b179360-dirty (Jun 06 2020 - 11:59:22 +0200)

  DRAM:  1 GiB
  Flash: error: kvm run failed Function not implemented
  R00=0001 R01=0040 R02=7ee0ce20 R03=
  R04=7ffd9eec R05=0004 R06=7ffda3f8 R07=0055
  R08=7ffd9eec R09=7ef0ded0 R10=7ee0ce20 R11=
  R12=0004 R13=7ee0cdf8 R14= R15=7ff72d08
  PSR=21d3 --C- A svc32
  QEMU: Terminated

This means that, in order to run U-Boot in QEMU under KVM, we need to
avoid such instructions when accessing emulated devices. For the flash
in particular, which is a hybrid between a ROM (backed by a memslot)
when in array mode, and an emulated MMIO device (when in write mode),
we need to take care to only use instructions that KVM can deal with
when they trap.

So override the flash accessors that are used when running on QEMU.
Note that the write accessors are included for completeness, but the
read accessors are the ones that need this special care.

Signed-off-by: Ard Biesheuvel 
---
 board/emulation/qemu-arm/qemu-arm.c | 55 
 include/configs/qemu-arm.h  |  1 +
 2 files changed, 56 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c 
b/board/emulation/qemu-arm/qemu-arm.c
index 1b0d543b93c1..32e18fd8b985 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -142,3 +142,58 @@ efi_status_t platform_get_rng_device(struct udevice **dev)
return EFI_SUCCESS;
 }
 #endif /* CONFIG_EFI_RNG_PROTOCOL */
+
+#ifdef CONFIG_ARM64
+#define __W"w"
+#else
+#define __W
+#endif
+
+void flash_write8(u8 value, void *addr)
+{
+   asm("strb %" __W "1, %0" : "=m"(*(u8 *)addr) : "r"(value));
+}
+
+void flash_write16(u16 value, void *addr)
+{
+   asm("strh %" __W "1, %0" : "=m"(*(u16 *)addr) : "r"(value));
+}
+
+void flash_write32(u32 value, void *addr)
+{
+   asm("str %" __W "1, %0" : "=m"(*(u32 *)addr) : "r"(value));
+}
+
+void flash_write64(u64 value, void *addr)
+{
+   BUG(); /* FLASH_CFI_64BIT is not implemented by QEMU */
+}
+
+u8 flash_read8(void *addr)
+{
+   u8 ret;
+
+   asm("ldrb %" __W "0, %1" : "=r"(ret) : "m"(*(u8 *)addr));
+   return ret;
+}
+
+u16 flash_read16(void *addr)
+{
+   u16 ret;
+
+   asm("ldrh %" __W "0, %1" : "=r"(ret) : "m"(*(u16 *)addr));
+   return ret;
+}
+
+u32 flash_read32(void *addr)
+{
+   u32 ret;
+
+   asm("ldr %" __W "0, %1" : "=r"(ret) : "m"(*(u32 *)addr));
+   return ret;
+}
+
+u64 flash_read64(void *addr)
+{
+   BUG(); /* FLASH_CFI_64BIT is not implemented by QEMU */
+}
diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index 1ef75a87836b..bc8b7c5c1238 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -53,5 +53,6 @@
 #define CONFIG_SYS_MAX_FLASH_BANKS 2
 #endif
 #define CONFIG_SYS_MAX_FLASH_SECT  256 /* Sector: 256K, Bank: 64M */
+#define CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
 
 #endif /* __CONFIG_H */
-- 
2.26.2

[PATCH 3/5] arm: qemu: implement enable_caches()

[Ard Biesheuvel]

Add an override for enable_caches to enable the I and D caches, along
with the cached 1:1 mapping of all of DRAM. This is needed for running
U-Boot under virtualization with QEMU/kvm.

Signed-off-by: Ard Biesheuvel 
---
 board/emulation/qemu-arm/qemu-arm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c 
b/board/emulation/qemu-arm/qemu-arm.c
index 69e8ef46f1f5..1b0d543b93c1 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -94,6 +95,12 @@ void *board_fdt_blob_setup(void)
return (void *)CONFIG_SYS_SDRAM_BASE;
 }
 
+void enable_caches(void)
+{
+icache_enable();
+dcache_enable();
+}
+
 #if defined(CONFIG_EFI_RNG_PROTOCOL)
 #include 
 #include 
-- 
2.26.2

[PATCH 1/5] arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK

[Ard Biesheuvel]

The LPAE version of DCACHE_WRITEBACK is currently defined as no-allocate
for both reads and writes, which deviates from the non-LPAE definition,
and mostly defeats the purpose of enabling the caches in the first place.

So align LPAE with !LPAE, and enable allocate-on-read.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/include/asm/system.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 7a40b56acdca..21b26557d28b 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -445,7 +445,7 @@ static inline void set_dacr(unsigned int val)
  * Memory types
  */
 #define MEMORY_ATTRIBUTES  ((0x00 << (0 * 8)) | (0x88 << (1 * 8)) | \
-(0xcc << (2 * 8)) | (0xff << (3 * 8)))
+(0xee << (2 * 8)) | (0xff << (3 * 8)))
 
 /* options available for data cache on each page */
 enum dcache_option {
-- 
2.26.2

[PATCH 2/5] arm: qemu: enable LPAE on 32-bit

[Ard Biesheuvel]

QEMU's mach-virt machine only supports selecting CPU models that
implement the virtualization extensions, and are therefore guaranteed
to support LPAE as well.

Initially, QEMU would not allow emulating these CPUs running in HYP
mode (or EL2, for AArch64), but today, it also contains a complete
implementation of the virtualization extensions themselves.

This means we could be running U-Boot in HYP mode, in which case the
LPAE long descriptor page table format is the only format that is
supported. If we are not running in HYP mode, we can use either.

So let's enable CONFIG_ARMV7_LPAE for qemu_arm_defconfig so that we
get the best support for running with the MMU and caches enabled at
any privilege level.

Signed-off-by: Ard Biesheuvel 
---
 configs/qemu_arm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index a8473988bd76..75bdce7708c7 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARM_SMCCC=y
+CONFIG_ARMV7_LPAE=y
 CONFIG_ARCH_QEMU=y
 CONFIG_ENV_SIZE=0x4
 CONFIG_ENV_SECT_SIZE=0x4
-- 
2.26.2

[PATCH 0/5] Fixes for running U-boot under QEMU/KVM

[Ard Biesheuvel]

This series fixes a number of issues that exist in the QEMU/mach-virt
port of u-boot, and that prevent it from executing correctly under
virtualization (as opposed to TCG emulation)

As the Linux EFI subsystem maintainer, I am looking to increase test
coverage for the EFI related changes that are under development for
Linux, and one of the things I plan to do is start using U-boot as
test firmware for boot testing. This can be done under TCG emulation,
but given how loosely TCG implements the architecture, it is better
to test under virtualization as well.

With these changes applied, u-boot can boot Linux in EFI mode under
KVM.

Cc: Tom Rini 
Cc: Sughosh Ganu 
Cc: Heinrich Schuchardt 

Ard Biesheuvel (5):
  arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK
  arm: qemu: enable LPAE on 32-bit
  arm: qemu: implement enable_caches()
  arm: qemu: disable the EFI workaround for older GRUB
  arm: qemu: override flash accessors to use virtualizable instructions

 arch/arm/include/asm/system.h   |  2 +-
 board/emulation/qemu-arm/qemu-arm.c | 62 
 configs/qemu_arm_defconfig  |  2 +
 include/configs/qemu-arm.h  |  1 +
 4 files changed, 66 insertions(+), 1 deletion(-)

-- 
2.26.2

Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI

[Ard Biesheuvel]

On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt  wrote:
>
> On 4/6/20 11:01 PM, Ard Biesheuvel wrote:
> > On Mon, 6 Apr 2020 at 22:45, Atish Patra  wrote:
> >>
> >> This series adds few DT related fixes required for Linux EFI stub to work
> >> on RISC-V.
> >>
> >
> > I'm not sure how this is supposed to work, since DT reserved memory
> > regions are not used by EFI. If you want to reserve memory on a UEFI
> > system, you have to reserve it in the UEFI memory map from firmware.
> > The DT reserved-memory node is taken into account too late, the
> > /memreserve/ entries are ignored entirely.
>
> Hello Ard,
>
> thanks for reviewing.
>
> What do you mean by "The DT reserved-memory node is taken into account
> too late"?
>
> Cf. commit 7be64b885a36 ("cmd: bootefi: Parse reserved-memory node from DT")
>

What I mean is that the EFI stub in Linux uses memory allocation
functions, expecting the firmware to ensure that those allocations do
not conflict with memory descriptions and reservations in DT. So if
the firmware wants to express this redundantly, by passing
reservations in both reserved-memory and in the EFI memory map, that
is probably fine.

Also, I must sheepishly admit that I only realize now that this patch
set is against u-boot not Linux :-)

So if fixed reserved-memory regions are only being used to seed the
reserved regions in the EFI memory map, you can safely ignore me.
Apologies for the noise.

Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI

[Ard Biesheuvel]

On Mon, 6 Apr 2020 at 22:45, Atish Patra  wrote:
>
> This series adds few DT related fixes required for Linux EFI stub to work
> on RISC-V.
>

I'm not sure how this is supposed to work, since DT reserved memory
regions are not used by EFI. If you want to reserve memory on a UEFI
system, you have to reserve it in the UEFI memory map from firmware.
The DT reserved-memory node is taken into account too late, the
/memreserve/ entries are ignored entirely.


> Patch 1 adds the boot hartid property under /chosen node. The related
> discussion can be found here.
>
> https://patchwork.ozlabs.org/patch/1233664/
> https://lists.denx.de/pipermail/u-boot/2020-March/402085.html
>
> Patch 2 fixes a generic issue in fdtdec related to reserved memory node.
>
> Patch 3,4,5 provide one of the option to update reserved-memory node for next
> stage. It depends on master OpenSBI branch.
>
> The other options are SBI extension and trap/emulate on PMP csr access.
> The detaild discussion can be found here.
> https://github.com/riscv/riscv-sbi-doc/pull/37
>
> Patch 1 & 2 can be applied independently from 3 and 4. I want to keep all
> the patches together to provide a holistic view of changes required for
> RISC-V UEFI.
>
> Changes v4->v5:
> 1. Added comments for new functions.
>
> Changes v3->v4:
> 1. Dropped generic efi fix patch as it is already merged.
> 2. Moved all the fdt fixups to a common file.
> 3. Addressed few nit comments.
>
> Changes from v2->v3:
> 1. Update the DT meant for OS if it is different from the one used by U-Boot
> 2. Use different FDT api to obtain "reg" address & size to honor the cell 
> count.
>
> Changes from v1->v2:
> 1. Fix the issue if chosen node is not present.
>
> Changes from previous version:
> 1. Renamed the DT node property to "boot-hartid" from "efi-boot-hartid".
> 2. Changed the property type to u32 instead of u64 for RV32 compatibility.
>
> Atish Patra (6):
> riscv: Add boot hartid to Device tree
> fdtdec: Fix boundary check
> riscv: Provide a mechanism to fix DT for reserved memory
> riscv: Setup reserved-memory node for FU540
> riscv: Copy the reserved-memory nodes to final DT
> riscv: Move all fdt fixups together
>
> arch/riscv/cpu/start.S|   1 +
> arch/riscv/include/asm/global_data.h  |   1 +
> arch/riscv/include/asm/u-boot-riscv.h |   2 +
> arch/riscv/lib/Makefile   |   1 +
> arch/riscv/lib/asm-offsets.c  |   1 +
> arch/riscv/lib/bootm.c|   5 -
> arch/riscv/lib/fdt_fixup.c| 150 ++
> configs/sifive_fu540_defconfig|   1 +
> lib/fdtdec.c  |   3 +-
> 9 files changed, 159 insertions(+), 6 deletions(-)
> create mode 100644 arch/riscv/lib/fdt_fixup.c
>
> --
> 2.25.1
>

Re: [RFC PATCH 0/1] Add boot hartid to a Device tree

[Ard Biesheuvel]

On Thu, 5 Mar 2020 at 04:28, Schaefer, Daniel (DualStudy)
 wrote:
>
> Hi,
>
> I have started to implement the corresponding changes in EDK2: 
> https://github.com/changab/edk2-staging-riscv/compare/5f63e9249751ccb9302514455b9a1a7038f34547...RISC-V-DT-fixup
> What happens is: The DTB is embedded in the FW image and passed to sbi_init 
> in SEC phase. We initialize OpenSBI as early as possible and because it also 
> wants to modify the device tree, I have to pass it the DTB as next_arg1.
> Then it's passed to PEI in the firmware context and further to DXE via a HOB. 
> In DXE the boot-hartid is inserted and it's installed into the EFI system 
> config table from where the EFISTUB reads it.
>
> Unfortunately I don't get any console output after the EFISTUB calls 
> ExitBootServices, so my patch is still WIP.
> Atish, which platform file in OpenSBI did you use to test your changes? 
> platform/qemu/virt/platform.c or platform/sifive/fu540/platform.c ?
> Maybe the failure is unrelated to the new patches - we've never booted Linux 
> from EDKII yet.
>
>
> I'm a bit skeptical whether DT is the best way to pass the boothartid to the 
> kernel. Ard has argued that it's good because it's independent from UEFI, but 
> the proper kernel doesn't read the hartid from there - it gets it from a0. 
> Only the EFISTUB reads the hartid from the device tree. Therefore the 
> solution we need is EFI specific anyways, right?
> One of the design goals is that we don't want to force bootloaders, which 
> load the EFISTUB (e.g. UEFI Shell, grub chainloading, systemd-boot), to 
> change.
>
> If we let the firmware embed the hartid in the DT, the user cannot swap out 
> the DT later for their custom one. They need to use the one given by the 
> firmware.
> Of course we could add commands and config to bootloaders to load and fixup 
> (embed hartid) the device tree... but, as mentioned earlier, we want to avoid 
> that.
> Additionally from EDKII side we're also planning to run later stages, 
> including the bootloader, in S-Mode, where they wouldn't even have access to 
> mhartid and thus couldn't fixup the DT.
>
> If instead the firmware writes the hartid into the EFI system config table, 
> the EFISTUB can read it from there, just like it does the device tree 
> already. Then bootloaders can put a user supplied DT in the config table, 
> too, like they always have.
>
> What do you all think - does that make sense?
>

It doesn't really matter from the EFI stub pov if the information
comes from the DT or from another config table. But the idea that
RISC-V is 'special', and that you have to pass *two* pieces of
information around instead of just one like on every other platform is
something that you should really think about carefully - there may be
other places where it will bite you down the road.

Also, the idea that a DT is a file that you ship with the kernel is
giving a *lot* of grief in the ARM world. The DT describes the
hardware, not the software, and so it is the responsibility of the
platform to provide it. If the platform gives you some way to drop in
another version of the DT in one way or the other, that is absolutely
fine, but in this case, the platform should know how to update
/chosen/boot-hartid (which it already can, in any case). But don't
make it part of the boot protocol, it really doesn't belong there.

Re: [RFC PATCH 0/1] Add boot hartid to a Device tree

[Ard Biesheuvel]

On Tue, 25 Feb 2020 at 09:59, Chang, Abner (HPS SW/FW Technologist)
 wrote:
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Tuesday, February 25, 2020 4:48 PM
> > To: Chang, Abner (HPS SW/FW Technologist) 
> > Cc: Atish Patra ; Heinrich Schuchardt
> > ; Atish Patra ; U-Boot Mailing
> > List ; Alexander Graf ; Anup Patel
> > ; Bin Meng ; Joe
> > Hershberger ; Loic Pallardy
> > ; Lukas Auer ;
> > Marek Behún ; Marek Vasut
> > ; Patrick Delaunay ;
> > Peng Fan ; Philippe Reynes
> > ; Simon Glass ;
> > Simon Goldschmidt ; Stefano Babic
> > ; Thierry Reding ; Tom Rini
> > ; l...@nuviainc.com; Schaefer, Daniel (DualStudy)
> > 
> > Subject: Re: [RFC PATCH 0/1] Add boot hartid to a Device tree
> >
> > On Tue, 25 Feb 2020 at 09:28, Chang, Abner (HPS SW/FW Technologist)
> >  wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Atish Patra [mailto:ati...@atishpatra.org]
> >
> > 
> >
> > > >
> > > > On Mon, Feb 24, 2020 at 3:35 PM Ard Biesheuvel
> > > >  wrote:
> > > > >
> > > > > On Tue, 25 Feb 2020 at 00:22, Heinrich Schuchardt
> > > > > 
> > > > wrote:
> > > > > >
> > > > > > On 2/24/20 11:19 PM, Atish Patra wrote:
> > > > > > > The RISC-V booting protocol requires the hart id to be present in
> > "a0"
> > > > > > > register. This is not a problem for bootm/booti commands as
> > > > > > > they directly jump to Linux kernel. However, bootefi jumps to
> > > > > > > a EFI boot stub code in Linux kernel which acts a loader and
> > > > > > > jumps to real Linux after terminating the boot services. This
> > > > > > > boot stub code has to be aware of the boot hart id so that it
> > > > > > > can set it in "a0" before jumping to Linux kernel. Currently,
> > > > > > > UEFI protocol doesn't have any mechanism to pass the boot hart
> > > > > > > id to an EFI executable. We should keep it this way as this is
> > > > > > > a RISC-V specific requirement rather than a UEFI requirement.
> > > > > > > Out of the all
> > > > possible options, device tree seemed to be the best choice to do this 
> > > > job.
> > > > > > > The detailed discussion can be found in the following thread.
> > > > > > >
> > > > > > > INVALID URI REMOVED
> > > > > > >
> > > >
> > abs.org_patch_1233664_&d=DwIBaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=_S
> > > > N6FZB
> > > > > > >
> > > >
> > N4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=J8GY_HS3fV_cJH9duXP739y
> > > > 0hDK
> > > > > > > 3qfHGNx2Dpcf-UBY&s=iVpRlpTOME_A-
> > > > O5STNbXXawkW24gxy2yi56Q8AtZ2bI&e=
> > > > > >
> > > > > > The above mentioned patch is obsoleted by the new suggestion.
> > > > > >
> > > >
> > > > Thanks for pointing that out to avoid confusion.
> > > >
> > > > > > >
> > > > > > > This patch updates the device tree in arch_fixup_fdt() which
> > > > > > > is common for all booting commands. As a result, the DT
> > > > > > > modification doesn't require any efi related arch specific
> > > > > > > functions and all DT related modifications are contained at
> > > > > > > one place. However, the hart id node will be available for
> > > > > > > Linux even if the kernel is booted using
> > > > bootm command.
> > > > > > >
> > > > > > > If that is not acceptable, we can always move the code to an
> > > > > > > efi specific function.
> > > > > >
> > > > > > Does a related Linux patch already exist?
> > > >
> > > > Yes. But in my local tree ;). It will be included in RISC-V EFI stub
> > > > support series which I am planning to post in a couple of days.
> > > >
> > > > > > How about EDK2?
> > > > > >
> > > > >
> > > > > RISC-V is not supported at all yet in EDK2.
> > > > >
> > > >
> > > > The EDK2 patches are out there and reviewed. I guess it will be
> > > > available in mainline EDK2 pretty soon.
> > > Yes, currently we are working on edk2 CI testing for RISCV64 arch.  We
> > hope edk2 RISC-V port could be in mainstream in Mar.
> > >
> >
> > Excellent! Is this core support? Or do you have a platform implemented as
> > well that can be upstreamed?
> Yes we do have platform implementations to be upstreamed, below is the latest 
> status of RISC-V edk2 port. We will have to update status later because we 
> just merged OpenSBI tag 0.6 to edk2 RISC-V.
> https://github.com/riscv/riscv-uefi-edk2-docs
>

Good to know! I saw some patches going by on the mailing list, but it
is hard to derive the current state of affairs from that.

I'm glad to see you did not make the same mistake we made on ARM and
omit the PEI phase entirely.

What I did notice is the use of APRIORI PEI and APRIORI DXE sections
in your platform descriptions. I recommend you try to avoid that, as
it is a maintenance burden going forward: instead, please use dummy
protocols and NULL library class resolutions if you need to make
generic components depend on platform specific protocols. Also, please
document this - the APRIORI section does not explain *why* you have to
circumvent the ordinary dependency tree based module dispatch.

Re: [RFC PATCH 0/1] Add boot hartid to a Device tree

[Ard Biesheuvel]

On Tue, 25 Feb 2020 at 09:28, Chang, Abner (HPS SW/FW Technologist)
 wrote:
>
>
>
> > -Original Message-
> > From: Atish Patra [mailto:ati...@atishpatra.org]



> >
> > On Mon, Feb 24, 2020 at 3:35 PM Ard Biesheuvel
> >  wrote:
> > >
> > > On Tue, 25 Feb 2020 at 00:22, Heinrich Schuchardt 
> > wrote:
> > > >
> > > > On 2/24/20 11:19 PM, Atish Patra wrote:
> > > > > The RISC-V booting protocol requires the hart id to be present in "a0"
> > > > > register. This is not a problem for bootm/booti commands as they
> > > > > directly jump to Linux kernel. However, bootefi jumps to a EFI
> > > > > boot stub code in Linux kernel which acts a loader and jumps to
> > > > > real Linux after terminating the boot services. This boot stub
> > > > > code has to be aware of the boot hart id so that it can set it in
> > > > > "a0" before jumping to Linux kernel. Currently, UEFI protocol
> > > > > doesn't have any mechanism to pass the boot hart id to an EFI
> > > > > executable. We should keep it this way as this is a RISC-V
> > > > > specific requirement rather than a UEFI requirement. Out of the all
> > possible options, device tree seemed to be the best choice to do this job.
> > > > > The detailed discussion can be found in the following thread.
> > > > >
> > > > > INVALID URI REMOVED
> > > > >
> > abs.org_patch_1233664_&d=DwIBaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=_S
> > N6FZB
> > > > >
> > N4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=J8GY_HS3fV_cJH9duXP739y
> > 0hDK
> > > > > 3qfHGNx2Dpcf-UBY&s=iVpRlpTOME_A-
> > O5STNbXXawkW24gxy2yi56Q8AtZ2bI&e=
> > > >
> > > > The above mentioned patch is obsoleted by the new suggestion.
> > > >
> >
> > Thanks for pointing that out to avoid confusion.
> >
> > > > >
> > > > > This patch updates the device tree in arch_fixup_fdt() which is
> > > > > common for all booting commands. As a result, the DT modification
> > > > > doesn't require any efi related arch specific functions and all DT
> > > > > related modifications are contained at one place. However, the
> > > > > hart id node will be available for Linux even if the kernel is booted 
> > > > > using
> > bootm command.
> > > > >
> > > > > If that is not acceptable, we can always move the code to an efi
> > > > > specific function.
> > > >
> > > > Does a related Linux patch already exist?
> >
> > Yes. But in my local tree ;). It will be included in RISC-V EFI stub 
> > support series
> > which I am planning to post in a couple of days.
> >
> > > > How about EDK2?
> > > >
> > >
> > > RISC-V is not supported at all yet in EDK2.
> > >
> >
> > The EDK2 patches are out there and reviewed. I guess it will be available in
> > mainline EDK2 pretty soon.
> Yes, currently we are working on edk2 CI testing for RISCV64 arch.  We hope 
> edk2 RISC-V port could be in mainstream in Mar.
>

Excellent! Is this core support? Or do you have a platform implemented
as well that can be upstreamed?

> > Abner agreed that similar patch can be added to EDK2 as well in the previous
> > thread.
> Yes, this will be another TODO for edk2 to add similar DT changes if we want 
> to boot system from edk2 firmware to EFI Stub and Linux kernel. We do not 
> have that so far.
>
> >
> > > > I guess boot loaders like GRUB would not have to care about the
> > > > extra property?
> > > >
> > >
> > > Yes, that is basically the point.
> >
> >
> >
> > --
> > Regards,
> > Atish

Re: [RFC PATCH 1/1] riscv: Add boot hartid to Device tree

[Ard Biesheuvel]

On Mon, 24 Feb 2020 at 23:20, Atish Patra  wrote:
>
> Linux booting protocol mandates that register "a0" contains the hartid.
> However, U-boot can not pass the hartid via a0 during EFI boot without
> breaking the UEFI specification.
>

It is not about breaking or violating the UEFI specification. It is
about the firmware using a conduit that is already being used to
describe the hardware to the OS to pass an extra piece of information
that the OS needs.

> Add a DT node under chosen node to indicate the boot hartid. EFI stub
> in Linux kernel will parse this node and pass it to the real kernel
> in "a0" before jumping to it.
>
> Signed-off-by: Atish Patra 
> ---
>  arch/riscv/lib/bootm.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> index fad16901c5f2..b84cc2db2016 100644
> --- a/arch/riscv/lib/bootm.c
> +++ b/arch/riscv/lib/bootm.c
> @@ -28,6 +28,19 @@ __weak void board_quiesce_devices(void)
>
>  int arch_fixup_fdt(void *blob)
>  {
> +   u32 size;
> +   int chosen_offset, err;
> +
> +   size = fdt_totalsize(blob);
> +   err  = fdt_open_into(blob, blob, size + 32);
> +   if (err < 0) {
> +   printf("Device Tree can't be expanded to accmodate new node");

'accommodate'

> +   return -1;
> +   }
> +   chosen_offset = fdt_path_offset(blob, "/chosen");
> +   fdt_setprop_u64(blob, chosen_offset, "efi-boot-hartid",

I assume that boot hartid does not change value when you boot via
UEFI, so this should simply be /chosen/boot-hartid

> +  gd->arch.boot_hart);
> +
> return 0;
>  }
>
> --
> 2.24.0
>

Re: [RFC PATCH 0/1] Add boot hartid to a Device tree

[Ard Biesheuvel]

On Tue, 25 Feb 2020 at 00:22, Heinrich Schuchardt  wrote:
>
> On 2/24/20 11:19 PM, Atish Patra wrote:
> > The RISC-V booting protocol requires the hart id to be present in "a0"
> > register. This is not a problem for bootm/booti commands as they directly
> > jump to Linux kernel. However, bootefi jumps to a EFI boot stub code in
> > Linux kernel which acts a loader and jumps to real Linux after terminating
> > the boot services. This boot stub code has to be aware of the boot hart id
> > so that it can set it in "a0" before jumping to Linux kernel. Currently,
> > UEFI protocol doesn't have any mechanism to pass the boot hart id to an
> > EFI executable. We should keep it this way as this is a RISC-V specific
> > requirement rather than a UEFI requirement. Out of the all possible options,
> > device tree seemed to be the best choice to do this job.
> > The detailed discussion can be found in the following thread.
> >
> > https://patchwork.ozlabs.org/patch/1233664/
>
> The above mentioned patch is obsoleted by the new suggestion.
>
> >
> > This patch updates the device tree in arch_fixup_fdt() which is common for
> > all booting commands. As a result, the DT modification doesn't require any
> > efi related arch specific functions and all DT related modifications are
> > contained at one place. However, the hart id node will be available for
> > Linux even if the kernel is booted using bootm command.
> >
> > If that is not acceptable, we can always move the code to an efi specific
> > function.
>
> Does a related Linux patch already exist?
> How about EDK2?
>

RISC-V is not supported at all yet in EDK2.

> I guess boot loaders like GRUB would not have to care about the extra
> property?
>

Yes, that is basically the point.

Re: [PATCH 1/1] efi_loader: implement EFI_RT_PROPERTIES_TABLE

[Ard Biesheuvel]

On Wed, 19 Feb 2020 at 21:00, Heinrich Schuchardt  wrote:
>
> UEFI spec 2.8 errata A replaces the RuntimeServicesSupported variable
> defined in UEFI spec 2.8 by the configuration table
> EFI_RT_PROPERTIES_TABLE. So let's follow suit.
>
> Cc: Ard Biesheuvel 
> Signed-off-by: Heinrich Schuchardt 

I have tested this on u-boot+linux/arm64 running on QEMU, with my
kernel patches that take this table into account [0], and compared to
EDK2 (which implements variable services, and doesn't produce this
table), I get

--- edk2.log 2020-02-19 22:42:58.767456976 +0100
+++ uboot.log 2020-02-19 22:42:46.907642320 +0100
@@ -9,7 +9,6 @@
 [] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo
Giometti 
 [] PTP clock support registered
 [] EDAC MC: Ver: 3.0.0
-[] Registered efivars operations
 [] FPGA manager framework
 [] Advanced Linux Sound Architecture Driver Initialized.
 [] clocksource: Switched to clocksource arch_sys_counter

(modulo the timestamps, of course)
So the table is being taken into account, and the EFI variable drivers
are no longer loaded.

Thanks for getting this sorted so quickly, the errata A spec was only
released today :-)


Tested-by: Ard Biesheuvel 



[0] https://lore.kernel.org/linux-efi/20200219171907.11894-1-a...@kernel.org/

> ---
>  cmd/efidebug.c   |  4 
>  include/efi_api.h| 12 
>  lib/efi_loader/efi_runtime.c | 36 
>  lib/efi_loader/efi_setup.c   |  8 
>  4 files changed, 48 insertions(+), 12 deletions(-)
>
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index 576e95b395..d291ae54af 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -264,6 +264,10 @@ static const struct {
> "SMBIOS table",
> SMBIOS_TABLE_GUID,
> },
> +   {
> +   "Runtime properties",
> +   EFI_RT_PROPERTIES_TABLE_GUID,
> +   },
>  };
>
>  /**
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 22396172e1..b7b68cb7a1 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -228,6 +228,18 @@ struct efi_capsule_header {
>  #define EFI_RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES0x1000
>  #define EFI_RT_SUPPORTED_QUERY_VARIABLE_INFO   0x2000
>
> +#define EFI_RT_PROPERTIES_TABLE_GUID \
> +   EFI_GUID(0xeb66918a, 0x7eef, 0x402a, 0x84, 0x2e, \
> +0x93, 0x1d, 0x21, 0xc3, 0x8a, 0xe9)
> +
> +#define EFI_RT_PROPERTIES_TABLE_VERSION0x1
> +
> +struct efi_rt_properties_table {
> +   u16 version;
> +   u16 length;
> +   u32 runtime_services_supported;
> +};
> +
>  struct efi_runtime_services {
> struct efi_table_hdr hdr;
> efi_status_t (EFIAPI *get_time)(struct efi_time *time,
> diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
> index 4b3c843b2c..4be51335bc 100644
> --- a/lib/efi_loader/efi_runtime.c
> +++ b/lib/efi_loader/efi_runtime.c
> @@ -18,6 +18,10 @@
>  /* For manual relocation support */
>  DECLARE_GLOBAL_DATA_PTR;
>
> +/* GUID of the runtime properties table */
> +static const efi_guid_t efi_rt_properties_table_guid =
> +   EFI_RT_PROPERTIES_TABLE_GUID;
> +
>  struct efi_runtime_mmio_list {
> struct list_head link;
> void **ptr;
> @@ -94,9 +98,28 @@ static __efi_runtime_data efi_uintn_t efi_descriptor_size;
>   * handle a good number of runtime callbacks
>   */
>
> +/**
> + * efi_init_runtime_supported() - create runtime properties table
> + *
> + * Create a configuration table specifying which services are available at
> + * runtime.
> + *
> + * Return: status code
> + */
>  efi_status_t efi_init_runtime_supported(void)
>  {
> -   u16 efi_runtime_services_supported =
> +   efi_status_t ret;
> +   struct efi_rt_properties_table *rt_table;
> +
> +   ret = efi_allocate_pool(EFI_RUNTIME_SERVICES_DATA,
> +   sizeof(struct efi_rt_properties_table),
> +   (void **)&rt_table);
> +   if (ret != EFI_SUCCESS)
> +   return ret;
> +
> +   rt_table->version = EFI_RT_PROPERTIES_TABLE_VERSION;
> +   rt_table->length = sizeof(struct efi_rt_properties_table);
> +   rt_table->runtime_services_supported =
> EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP |
> EFI_RT_SUPPORTED_CONVERT_POINTER;
>
> @@ -105,15 +128,12 @@ efi_status_t efi_init_runtime_supported(void)
>  * as well as efi_runtime_services.
>  */
>  #ifdef CONFIG_EFI_HAVE_RUNTIME_RESET
> -   efi_runtime_services_supp

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Ard Biesheuvel]

On Fri, 14 Feb 2020 at 13:04, Chang, Abner (HPS SW/FW Technologist)
 wrote:
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Friday, February 14, 2020 7:33 PM
> > To: Chang, Abner (HPS SW/FW Technologist) 
> > Cc: Alexander Graf ; Atish Patra ;
> > Heinrich Schuchardt ; U-Boot Mailing List  > b...@lists.denx.de>; Atish Patra ;
> > l...@nuviainc.com
> > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> >
> > On Fri, 14 Feb 2020 at 12:27, Chang, Abner (HPS SW/FW Technologist)
> >  wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Alexander Graf [mailto:ag...@csgraf.de]
> > > > Sent: Friday, February 14, 2020 4:07 PM
> > > > To: Chang, Abner (HPS SW/FW Technologist) 
> > > > Cc: Atish Patra ; Ard Biesheuvel
> > > > ; Heinrich Schuchardt
> > > > ; U-Boot Mailing List ;
> > > > Atish Patra ; l...@nuviainc.com
> > > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI
> > > > setup
> > > >
> > > >
> > > >
> > > > > Am 14.02.2020 um 05:21 schrieb Chang, Abner (HPS SW/FW
> > > > > Technologist)
> > > > :
> > > > >
> >
> > ...
> > > > The table  from this link https://github.com/riscv/riscv-
> > > > smbios/blob/master/RISCV-SMBIOS.md
> > > > > Offset 3 is HART ID, and offset 13h is the boolean indicates this
> > > > > hart is the
> > > > boot hart.
> > > > >
> > > > >> kernel. How difficult is to modify the DT in EDK2 ?
> > > > >>
> > > > > I never used DT before on PC/Server project. However, the DT code
> > > > > is over
> > > > there in edk2 repo which mostly used by ARM platforms. I don’t think
> > > > it is difficult to adopt it though.
> > > >
> > > > Yes, some arm platforms already transform the DT just fine. Let's
> > > > really please not use SMBIOS for anything boot or system
> > > > configuration related: its purpose is in general purely informational.
> > > As DT to embedded system, SMBIOS provides system
> > information/configuration on most PC/Server platforms. Especially to pre-OS
> > applications such as EFI diagnostic tool, factory/customer deployment tools,
> > pre-OS system configuration, network boot image and EFI OS  boot loader as
> > well. The intention of RISC-V SMBIOS is support above applications using
> > single image for the RISC-V core variants, Non ACPI-aware OS is also part of
> > this scope, but it is rare though.
> > > If you are booting to OS which is actually well understand DT then just 
> > > use
> > DT, but for PC/Server industry, SMBIOS would be still our choice before OS.
> > > We may have to define the corresponding syntax If DT doesn't have it for
> > boot HART information. RISC-V System Description Task Group (f it formed)
> > would be a good place to bring this topic.
> > > Maybe you can support both DT or SMBIOS to retrieve the information you
> > need on demand...
> > >
> >
> > SMBIOS is an informational protocol. Firmware or OS loaders should not rely
> > on it for low-level things like the hart id.
> Hart ID is just one of the information in type 44 which is the same as the 
> processor information provided in type 4.
>

Fine. But that doesn't mean we should be parsing SMBIOS tables in the
Linux startup code.

> >
> > > >
> > > > So yes, unless I hear really good arguments against passing it via
> > > > /chosen in DT, I'd strongly prefer that mechanism. For ACPI (if it
> > > > ever happens), there would be a special ACPI table for it anyway.
> > > Yes, we do have an ECR for ACPI spec to report the RISC-V core
> > characteristic which is similar to what we done for SMBIOS.
> > >
> >
> > So we'll end up with a DT+SMBIOS or ACPI+SMBIOS boot protocol, and we'll
> > always have to parse two sets of tables, just to discover the hart id. I 
> > don't
> > think that makes sense at all, to be honest.
> As I said, SMBIOS is mostly for pre OS applications, Type 42 is a good 
> example, the Host interface used to talk to BMC and Redfish service in pre-OS 
> environment (also runtime OS).
> For OS boot, maybe OS (like Windows) still retrieves information from it 
> before ACPI enable.
>
> I have no preference of using which way to get boot hard ID for the boot 
> process, either to get it from DT, SMBIOS or  ACPI seems to me the same... 
> just the information is provided over there
>
> >
> > SMBIOS is wonderful for the sysadmin to look at the model numbers of the
> > installed DIMMs etc. But for core boot stuff, we really should avoid it.
> Security consideration?

What security considerations did you have in mind?

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Ard Biesheuvel]

On Fri, 14 Feb 2020 at 12:27, Chang, Abner (HPS SW/FW Technologist)
 wrote:
>
>
>
> > -Original Message-
> > From: Alexander Graf [mailto:ag...@csgraf.de]
> > Sent: Friday, February 14, 2020 4:07 PM
> > To: Chang, Abner (HPS SW/FW Technologist) 
> > Cc: Atish Patra ; Ard Biesheuvel
> > ; Heinrich Schuchardt ;
> > U-Boot Mailing List ; Atish Patra
> > ; l...@nuviainc.com
> > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> >
> >
> >
> > > Am 14.02.2020 um 05:21 schrieb Chang, Abner (HPS SW/FW Technologist)
> > :
> > >

...
> > The table  from this link https://github.com/riscv/riscv-
> > smbios/blob/master/RISCV-SMBIOS.md
> > > Offset 3 is HART ID, and offset 13h is the boolean indicates this hart is 
> > > the
> > boot hart.
> > >
> > >> kernel. How difficult is to modify the DT in EDK2 ?
> > >>
> > > I never used DT before on PC/Server project. However, the DT code is over
> > there in edk2 repo which mostly used by ARM platforms. I don’t think it is
> > difficult to adopt it though.
> >
> > Yes, some arm platforms already transform the DT just fine. Let's really
> > please not use SMBIOS for anything boot or system configuration related: its
> > purpose is in general purely informational.
> As DT to embedded system, SMBIOS provides system information/configuration on 
> most PC/Server platforms. Especially to pre-OS applications such as EFI 
> diagnostic tool, factory/customer deployment tools, pre-OS system 
> configuration, network boot image and EFI OS  boot loader as well. The 
> intention of RISC-V SMBIOS is support above applications using single image 
> for the RISC-V core variants, Non ACPI-aware OS is also part of this scope, 
> but it is rare though.
> If you are booting to OS which is actually well understand DT then just use 
> DT, but for PC/Server industry, SMBIOS would be still our choice before OS.
> We may have to define the corresponding syntax If DT doesn't have it for boot 
> HART information. RISC-V System Description Task Group (f it formed) would be 
> a good place to bring this topic.
> Maybe you can support both DT or SMBIOS to retrieve the information you need 
> on demand...
>

SMBIOS is an informational protocol. Firmware or OS loaders should not
rely on it for low-level things like the hart id.

> >
> > So yes, unless I hear really good arguments against passing it via /chosen 
> > in
> > DT, I'd strongly prefer that mechanism. For ACPI (if it ever happens), there
> > would be a special ACPI table for it anyway.
> Yes, we do have an ECR for ACPI spec to report the RISC-V core characteristic 
> which is similar to what we done for SMBIOS.
>

So we'll end up with a DT+SMBIOS or ACPI+SMBIOS boot protocol, and
we'll always have to parse two sets of tables, just to discover the
hart id. I don't think that makes sense at all, to be honest.

SMBIOS is wonderful for the sysadmin to look at the model numbers of
the installed DIMMs etc. But for core boot stuff, we really should
avoid it.

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Ard Biesheuvel]

On Thu, 13 Feb 2020 at 19:59, Atish Patra  wrote:
>
> On Tue, Feb 11, 2020 at 11:28 PM Ard Biesheuvel
>  wrote:
> >
> > On Wed, 12 Feb 2020 at 06:49, Chang, Abner (HPS SW/FW Technologist)
> >  wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > > > Sent: Wednesday, February 12, 2020 2:26 AM
> > > > To: Chang, Abner (HPS SW/FW Technologist) ;
> > > > Atish Patra ; Ard Biesheuvel
> > > > 
> > > > Cc: Alexander Graf ; U-Boot Mailing List  > > > b...@lists.denx.de>; Atish Patra ;
> > > > l...@nuviainc.com
> > > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> > > >
> > > > On 2/7/20 4:13 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> > > > >
> > > > >
> > > > >> -Original Message-
> > > > >> From: Atish Patra [mailto:ati...@atishpatra.org]
> > > > >> Sent: Friday, February 7, 2020 6:56 AM
> > > > >> To: Ard Biesheuvel ; Chang, Abner (HPS
> > > > >> SW/FW
> > > > >> Technologist) 
> > > > >> Cc: Alexander Graf ; Heinrich Schuchardt
> > > > >> ; U-Boot Mailing List ;
> > > > >> Atish Patra ; l...@nuviainc.com
> > > > >> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI
> > > > >> setup
> > > > >>
> > > > >> On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel
> > > > >> 
> > > > >> wrote:
> > > > >>>
> > > > >>> On Thu, 6 Feb 2020 at 21:06, Atish Patra  
> > > > >>> wrote:
> > > > >>>>
> > > > >>>> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf 
> > > > wrote:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> On 06.02.20 19:28, Atish Patra wrote:
> > > > >>>>>> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
> > > > >>>>>>  wrote:
> > > > >>>>>>> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt
> > > > >>  wrote:
> > > > >>>>>>>> RISC-V booting currently is based on a per boot stage lottery
> > > > >>>>>>>> to determine the active CPU. The Hart State Management (HSM)
> > > > >>>>>>>> SBI extension replaces this lottery by using a dedicated
> > > > >>>>>>>> primary
> > > > >> CPU.
> > > > >>>>>>>>
> > > > >>>>>>>> Cf. Hart State Management Extension, Extension ID: 0x48534D
> > > > >>>>>>>> (HSM)
> > > > >>>>>>>> https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.a
> > > > >>>>>>>> doc
> > > > >>>>>>>>
> > > > >>>>>>>> In this scenario the id of the active hart has to be passed
> > > > >>>>>>>> from boot stage to boot stage. Using a UEFI variable would
> > > > >>>>>>>> provide
> > > > >> an easy implementation.
> > > > >>>>>>>>
> > > > >>>>>>>> This patch provides a weak function that is called at the end
> > > > >>>>>>>> of the setup of U-Boot's UEFI sub-system. By overriding this
> > > > >>>>>>>> function architecture specific UEFI variables or configuration
> > > > >>>>>>>> tables
> > > > >> can be created.
> > > > >>>>>>>>
> > > > >>>>>>>> Signed-off-by: Heinrich Schuchardt 
> > > > >>>>>>>> Reviewed-by: Atish Patra 
> > > > >>>>>>> OK, so I have a couple of questions:
> > > > >>>>>>>
> > > > >>>>>>> - does RISC-V use device tree? if so, why are you not passing
> > > > >>>>>>> the active hart via a property in the /chosen node?
> > > > >>>>>> Yes. RISC-V uses device tree. Technically, we can pass the active
> > > > &g

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Ard Biesheuvel]

On Wed, 12 Feb 2020 at 06:49, Chang, Abner (HPS SW/FW Technologist)
 wrote:
>
>
>
> > -Original Message-
> > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > Sent: Wednesday, February 12, 2020 2:26 AM
> > To: Chang, Abner (HPS SW/FW Technologist) ;
> > Atish Patra ; Ard Biesheuvel
> > 
> > Cc: Alexander Graf ; U-Boot Mailing List  > b...@lists.denx.de>; Atish Patra ;
> > l...@nuviainc.com
> > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> >
> > On 2/7/20 4:13 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Atish Patra [mailto:ati...@atishpatra.org]
> > >> Sent: Friday, February 7, 2020 6:56 AM
> > >> To: Ard Biesheuvel ; Chang, Abner (HPS
> > >> SW/FW
> > >> Technologist) 
> > >> Cc: Alexander Graf ; Heinrich Schuchardt
> > >> ; U-Boot Mailing List ;
> > >> Atish Patra ; l...@nuviainc.com
> > >> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI
> > >> setup
> > >>
> > >> On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel
> > >> 
> > >> wrote:
> > >>>
> > >>> On Thu, 6 Feb 2020 at 21:06, Atish Patra  wrote:
> > >>>>
> > >>>> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf 
> > wrote:
> > >>>>>
> > >>>>>
> > >>>>> On 06.02.20 19:28, Atish Patra wrote:
> > >>>>>> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
> > >>>>>>  wrote:
> > >>>>>>> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt
> > >>  wrote:
> > >>>>>>>> RISC-V booting currently is based on a per boot stage lottery
> > >>>>>>>> to determine the active CPU. The Hart State Management (HSM)
> > >>>>>>>> SBI extension replaces this lottery by using a dedicated
> > >>>>>>>> primary
> > >> CPU.
> > >>>>>>>>
> > >>>>>>>> Cf. Hart State Management Extension, Extension ID: 0x48534D
> > >>>>>>>> (HSM)
> > >>>>>>>> https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.a
> > >>>>>>>> doc
> > >>>>>>>>
> > >>>>>>>> In this scenario the id of the active hart has to be passed
> > >>>>>>>> from boot stage to boot stage. Using a UEFI variable would
> > >>>>>>>> provide
> > >> an easy implementation.
> > >>>>>>>>
> > >>>>>>>> This patch provides a weak function that is called at the end
> > >>>>>>>> of the setup of U-Boot's UEFI sub-system. By overriding this
> > >>>>>>>> function architecture specific UEFI variables or configuration
> > >>>>>>>> tables
> > >> can be created.
> > >>>>>>>>
> > >>>>>>>> Signed-off-by: Heinrich Schuchardt 
> > >>>>>>>> Reviewed-by: Atish Patra 
> > >>>>>>> OK, so I have a couple of questions:
> > >>>>>>>
> > >>>>>>> - does RISC-V use device tree? if so, why are you not passing
> > >>>>>>> the active hart via a property in the /chosen node?
> > >>>>>> Yes. RISC-V uses device tree. Technically, we can pass the active
> > >>>>>> hart by a DT property but that means we have to modify the DT in
> > >>>>>> OpenSBI (RISC-V specific run time service provider).
> > >>>>>> We have been trying to avoid that if possible so that DT is not
> > >>>>>> bounced around. This also limits U-Boot to have its own device
> > >>>>>> tree.
> > >>>>>
> > >>>>>
> > >>>>> I don't understand how this is different from the UEFI variable
> > >>>>> scheme proposed here? If you want to create an SBI interface to
> > >>>>> propagate the active HART that U-Boot then uses to populate the
> > >>>>> /chosen property, that's probably fine as well.
> > >>>>>
> > >>>>
> > >&g

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Ard Biesheuvel]

On Thu, 6 Feb 2020 at 21:06, Atish Patra  wrote:
>
> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf  wrote:
> >
> >
> > On 06.02.20 19:28, Atish Patra wrote:
> > > On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
> > >  wrote:
> > >> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt  
> > >> wrote:
> > >>> RISC-V booting currently is based on a per boot stage lottery to 
> > >>> determine
> > >>> the active CPU. The Hart State Management (HSM) SBI extension replaces
> > >>> this lottery by using a dedicated primary CPU.
> > >>>
> > >>> Cf. Hart State Management Extension, Extension ID: 0x48534D (HSM)
> > >>> https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
> > >>>
> > >>> In this scenario the id of the active hart has to be passed from boot 
> > >>> stage
> > >>> to boot stage. Using a UEFI variable would provide an easy 
> > >>> implementation.
> > >>>
> > >>> This patch provides a weak function that is called at the end of the 
> > >>> setup
> > >>> of U-Boot's UEFI sub-system. By overriding this function architecture
> > >>> specific UEFI variables or configuration tables can be created.
> > >>>
> > >>> Signed-off-by: Heinrich Schuchardt 
> > >>> Reviewed-by: Atish Patra 
> > >> OK, so I have a couple of questions:
> > >>
> > >> - does RISC-V use device tree? if so, why are you not passing the
> > >> active hart via a property in the /chosen node?
> > > Yes. RISC-V uses device tree. Technically, we can pass the active hart
> > > by a DT property
> > > but that means we have to modify the DT in OpenSBI (RISC-V specific
> > > run time service provider).
> > > We have been trying to avoid that if possible so that DT is not
> > > bounced around. This also limits
> > > U-Boot to have its own device tree.
> >
> >
> > I don't understand how this is different from the UEFI variable scheme
> > proposed here? If you want to create an SBI interface to propagate the
> > active HART that U-Boot then uses to populate the /chosen property,
> > that's probably fine as well.
> >
>
> We don't want to create SBI interface to pass this information.
>
> > We already have hooks that allow you to modify the DT right before it
> > gets delivered to the payload. Just add it there?
> >
>
> Hmm. I guess it is true if the DT is loaded from MMC or network as well.
> How about EDK2 ? If we go DT route, it also has to modify the DT to
> pass the boot hart.
>
> As it requires DT modification in multiple projects, why not use efi
> configuration tables as
> suggested by Ard ?
>

Configuration tables are preferred over variables, but putting it in
the DT makes even more sense, since in that case, nothing that runs in
the UEFI context has to care about any of this.

> > >
> > >
> > >> I'd assume the EFI stub would not care at all about this information, 
> > >> and it would give
> > >> you a Linux/RISC-V specific way to convey this information that is
> > >> independent of EFI.
> > > Yes. EFI stub doesn't care about this information. However, it needs
> > > to save the information somewhere
> > > so that it can pass to the real kernel after exiting boot time services.
> >
> >
> > DT sounds like a pretty natural choice for that to me :).
> >

Indeed. DT has a /chosen node that is set aside for this purpose. It
does depend on how early you need the value (i.e., before or after you
can run C code), but since you are passing the DT address to the core
kernel, it makes way more sense to drop any additional information
that you need to pass in there.

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Ard Biesheuvel]

On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt  wrote:
>
> RISC-V booting currently is based on a per boot stage lottery to determine
> the active CPU. The Hart State Management (HSM) SBI extension replaces
> this lottery by using a dedicated primary CPU.
>
> Cf. Hart State Management Extension, Extension ID: 0x48534D (HSM)
> https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
>
> In this scenario the id of the active hart has to be passed from boot stage
> to boot stage. Using a UEFI variable would provide an easy implementation.
>
> This patch provides a weak function that is called at the end of the setup
> of U-Boot's UEFI sub-system. By overriding this function architecture
> specific UEFI variables or configuration tables can be created.
>
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Atish Patra 

OK, so I have a couple of questions:

- does RISC-V use device tree? if so, why are you not passing the
active hart via a property in the /chosen node? I'd assume the EFI
stub would not care at all about this information, and it would give
you a Linux/RISC-V specific way to convey this information that is
independent of EFI.
- using variables to pass information from firmware to OS only is
overkill, and config tables are preferred, given that they only
require access to the system table. If required, a RISC-V specific
data structure containing boot parameters could be installed as a
configuration table, and the address passed to the startup code in the
kernel proper [rather than just a hart id], allowing you to put any
piece of information you like in there.

Config tables work fine with kexec, btw. It is up to the first OS to
memblock_reserve() the table to guarantee that it is still there at
kexec time, but this applies equally to all other data structures
passed as config tables. Alternatively, in this case, you can
stipulate that it is passed as AcpiReclaim [ignore the 'Acpi' in the
name] which is intended for firmware tables (and we never reclaim it
in linux)

I'd also recommend that RISC-V adopt the same principle as ARM does
when it comes to EFI: call SetVirtualAddressMap in the stub, so that
the kernel proper always sees the same handover state, regardless of
kexec. Additionally, you shouldn't ever modify the EFI memory map
provided by the firmware, so that the kexec kernel sees the exact same
version.




> ---
> v2:
> reference the Hart State Management Extension in the commit message
> ---
>  include/efi_loader.h   |  3 +++
>  lib/efi_loader/efi_setup.c | 16 
>  2 files changed, 19 insertions(+)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index d4c59b54c4..d87de85e83 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -116,6 +116,9 @@ extern efi_uintn_t efi_memory_map_key;
>  extern struct efi_runtime_services efi_runtime_services;
>  extern struct efi_system_table systab;
>
> +/* Architecture specific initialization of the UEFI system */
> +efi_status_t efi_setup_arch_specific(void);
> +
>  extern struct efi_simple_text_output_protocol efi_con_out;
>  extern struct efi_simple_text_input_protocol efi_con_in;
>  extern struct efi_console_control_protocol efi_console_control;
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index de7b616c6d..8469f0f43c 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -22,6 +22,17 @@ void __weak allow_unaligned(void)
>  {
>  }
>
> +/**
> + * efi_setup_arch_specific() - architecture specific UEFI setup
> + *
> + * This routine can be used to define architecture specific variables
> + * or configuration tables, e.g. HART id for RISC-V
> + */
> +efi_status_t __weak efi_setup_arch_specific(void)
> +{
> +   return EFI_SUCCESS;
> +}
> +
>  /**
>   * efi_init_platform_lang() - define supported languages
>   *
> @@ -179,6 +190,11 @@ efi_status_t efi_init_obj_list(void)
> if (ret != EFI_SUCCESS)
> goto out;
>
> +   /* Architecture specific setup */
> +   ret = efi_setup_arch_specific();
> +   if (ret != EFI_SUCCESS)
> +   goto out;
> +
>  out:
> efi_obj_list_initialized = ret;
> return ret;
> --
> 2.24.1
>

Re: [U-Boot] Crash in U-Boot

[Ard Biesheuvel]

On Sun, 23 Jun 2019 at 23:47, Alexander Graf  wrote:
>
>
>
> > Am 23.06.2019 um 17:08 schrieb Heinrich Schuchardt :
> >
> > Hello Alex,
> >
> > on the i.MX6 Wandboard the Kernel crashes when booting via GRUB at least
> > since U-Boot v2019.01. See below.
> >
> > In the code for SetVirtualAddressMap I saw the that the pointer to the
> > list of configuration tables is adjusted:
> >
> > if ((map_start <= (uintptr_t)systab.tables) &&
> > (map_end >= (uintptr_t)systab.tables)) {
> > char *ptr = (char *)systab.tables;
> > ptr += off;
> > systab.tables = (struct efi_configuration_table *)ptr;
> > }
> >
> > Shouldn't the pointers to the individual configuration tables be
> > adjusted too? I found no such code.
>
> We have to adapt the systable, because RT code may use it. However, I thought 
> tables are not guaranteed to be around after SVAM? Ard?
>

Only the system table pointers are updated for virtual remapping. I'm
not entirely sure why, but this permits the runtime firmware
components themselves to access the array. However, runtime firmware
typically has no way to translate a physical address into a virtual
address, so if they need to access such tables, they have to grab the
address *before* SVAM(), which means it doesn't matter whether the
config table array point is translated as well.

> I tend to agree that in that case, adjusting the table pointer does not sound 
> very useful either. Can we legally just set the table count to 0 there?
>

No. The OS expects to be able to locate config tables, and the OS
itself does not care about runtime remapping.

> If however they are indeed legal to access via virtual addresses afterwards, 
> I do agree that we should patch the individual table pointers too, yes.
>
>

Please don't do the sane thing. Where's the fun in that? :-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] efi_loader: detaching runtime

[Ard Biesheuvel]

On Fri, 21 Jun 2019 at 09:37, Alexander Graf  wrote:
>
>
> On 20.06.19 23:59, Heinrich Schuchardt wrote:
> > Hello Alex,
> >
> > currently we have two code sections in U-Boot:
> >
> > * __efi_runtime/__efi_runtime_data (mapped to EFI_RUNTIME_SERVICES_CODE)
> > * all other code (mapped to EFI_LOADER_DATA by add_u_boot_and_runtime())
> >
> > All code and data that is not marked as __efi_runtime or
> > __efi_runtime_data lives in a memory area that the EFI application may
> > reuse after ExitBootServices().
> >
> > Code that is marked as __efi_runtime is relocated at
> > SetVirtualMemoryMap().
> >
> > I wonder in which section the relocation code should live.
> >
> > It cannot be __efi_runtime or it will mess up itself while relocating.
> > It cannot be in EFI_LOADER_DATA or it may be overwritten after
> > ExitBootServices().
> >
> > If this reasoning is right wouldn't we need a third code section living
> > in EFI_RUNTIME_SERVICES_CODE but which is excluded from the relocation
> > during SetVirtualMemoryMap()?
>
>
> Ard, are we guaranteed that during SetVirtualMemoryMap both the old as
> well as the new memory location are accessible?
>

No. Only the old mapping may be assumed to be active at this point. In
fact, the arm64 linux kernel does not create the new mapping until
much later, so this does not seem to be a problem in practice.

> If that's the case, we can't mess ourselves up. If not, I don't see how
> SetVirtualMemoryMap would work at all.
>
>
> > Another option of cause would be to put the whole U-Boot code into
> > EFI_RUNTIME_SERVICES_CODE which will incur a loss of less than 1 MiB for
> > the operating system.
>
>
> I'd rather not leak random U-Boot code into the runtime accessible area
> for both security and validation reasons. Chances that we accidently
> leak random MMIO accesses that are not runtime patched are really high.
>
>
> Alex
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory type from runtime data to boot services data

[Ard Biesheuvel]

On Fri, 12 Apr 2019 at 12:55, Heinrich Schuchardt  wrote:
>
> On 4/12/19 9:30 PM, Heinrich Schuchardt wrote:
> > On 4/12/19 8:26 PM, Ilias Apalodimas wrote:
> >> Following Ard's suggestion:
> >> Runtime data sections are intended for data that is used by the runtime
> >> services implementation.
> >> Let's change the type to EFI_BOOT_SERVICES_DATA
> >>
> >> This also fixes booting of armv7 using efi and fdtcontroladdr
> >>
> >> Suggested-by: Ard Biesheuvel 
> >> Signed-off-by: Ilias Apalodimas 
> >> Acked-by: Ard Biesheuvel 
> >
> > EfiBootServicesData is used by EDK II for installing the FDT.
> > GRUB uses EfiLoaderCode when installing its modified version of the FDT.
> >
> > Reviewed-by: Heinrich Schuchardt 
>
> Applied u-bootefi branch efi-2019-07

Thanks Heinrich.

I still have a question, though. The following code

new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
 EFI_BOOT_SERVICES_DATA, fdt_pages,
 &new_fdt_addr);

looks (from the patch context) like it sets new_fdt_addr to the FDT
size rounded up to 4 KB, and then uses that *size* as the max address
in the allocation. That seems a bit strange.

But the important point is that the EFI stub does not care at all
where the FDT is. The stub allocates a new fdt based on the firmware
provided one, and copies in all the data, and adds some data of its
own.

This means that the EFI code in u-boot really doesn't have to abide by
the same rules as the other code allocating FDTs. (It also means there
is no point in using ACPI reclaim memory for the FDT, as I suggested
earlier, so BS data is definitely the best choice here)

-- 
Ard.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim

[Ard Biesheuvel]

On Fri, 12 Apr 2019 at 10:44, Heinrich Schuchardt  wrote:
>
> On 4/12/19 7:24 PM, Ard Biesheuvel wrote:
> > On Fri, 12 Apr 2019 at 10:16, Heinrich Schuchardt  
> > wrote:
> >>
> >> On 4/11/19 10:50 PM, Ard Biesheuvel wrote:
> >>> On Thu, 11 Apr 2019 at 12:59, Heinrich Schuchardt  
> >>> wrote:
> >>>>
> >>>> On 4/11/19 9:41 PM, Ilias Apalodimas wrote:
> >>>>> Hi Heinrich,
> >>>>>> On 4/11/19 8:39 PM, Ilias Apalodimas wrote:
> >>>>>>> Following Ard's suggestion:
> >>>>>>> Runtime data sections are intended for data that is used by the 
> >>>>>>> runtime
> >>>>>>> services implementations.
> >>>>>>> Let's change they type to EFI_ACPI_RECLAIM_MEMORY
> >>>>>>>
> >>>>>>> Suggested-by: Ard Biesheuvel 
> >>>>>>> Signed-off-by: Ilias Apalodimas 
> >>>>>>> ---
> >>>>>>> cmd/bootefi.c | 4 ++--
> >>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> >>>>>>> index 3619a20e6433..b54181909aff 100644
> >>>>>>> --- a/cmd/bootefi.c
> >>>>>>> +++ b/cmd/bootefi.c
> >>>>>>> @@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp)
> >>>>>>>   new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
> >>>>>>>fdt_size, 0);
> >>>>>>>   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
> >>>>>>> -EFI_RUNTIME_SERVICES_DATA, fdt_pages,
> >>>>>>> +EFI_ACPI_RECLAIM_MEMORY, fdt_pages,
> >>>>>>
> >>>>>> GRUB uses EfiLoaderCode when installing its modified version of the 
> >>>>>> FDT.
> >>>>>>
> >>>>>> The "Embedded Base Boot Requirements (EBBR) Specification, Release 
> >>>>>> v1.0"
> >>>>>> does not require ACPI support. Can we expect EfiACPIReclaimMemory to be
> >>>>>> supported if we do not have any ACPI table?
> >>>>>>
> >>>>>> How about functions efi_smbios_register() and efi_acpi_register()?
> >>>>>>
> >>>>>> How about systab.tables assigned in efi_initialize_system_table()? 
> >>>>>> Which
> >>>>>> of the addresses in systab.tables should be updated upon relocation.
> >>>>>>
> >>>>>> The EFI Spec is really hazy: "A pointer to the table associated with
> >>>>>> VendorGuid. Whether this pointer is a physical address or a
> >>>>>> virtual address during runtime is determined by the VendorGuid."
> >>>>>>
> >>>>>> The FDT_TABLE_GUID or DEVICE_TREE_GUID as Linux calls it is not defined
> >>>>>> in the UEFI spec. So we can marvel about expected behavior. Is there 
> >>>>>> any
> >>>>>> other document specifying it?
> >>>>>
> >>>>> What about using EFI_BOOT_SERVICES_DATA instead of 
> >>>>> EFI_ACPI_RECLAIM_MEMORY?
> >>>>> This still fixes the issue and doesn't cause any of the potential 
> >>>>> problems you
> >>>>> mentioned
> >>>>
> >>>> Why services data and not loader data?
> >>>>
> >>>
> >>> Services data is used by the boot services and loader data by the
> >>> loader. GRUB is a loader so it uses loader data, u-boot is both boot
> >>> services and a loader so it could arguably use both, but boot services
> >>> data is more idiomatic.
> >>>
> >>> >From the pov of the OS, it makes no difference at all.
> >>>
> >>>> As said above we should consider all three supported tables ACPI,
> >>>> SMBIOS, and FDT when thinking about a fix. The UEFI spec describes that
> >>>> the addresses inside ACPI and SMBIOS tables are not fixed up when
> >>>> entering runtime.
> >>>>
> >>>> This indicates that at least these tables have to be accessible at
> >>