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

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,

Re: Firmware handoff status

On Thu, 9 Feb 2023 at 10:48, ff wrote: > > Hi > > Anyone knows what is the status of standardizing firmware handoff (when > starting BL33) ? > Here is a reference to the topic: > https://github.com/FirmwareHandoff/firmware_handoff > > I would be interested in both standard text and standard

Re: Native PE/COFF support for aarch64

On Fri, 10 Sept 2021 at 18:36, François Ozog wrote: > > > On Fri, 10 Sept 2021 at 18:34, Ard Biesheuvel wrote: > >> On Fri, 10 Sept 2021 at 18:12, François Ozog >> wrote: >> > >> > Hi, >> > >> > this mail just to inform you tha

Re: Native PE/COFF support for aarch64

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

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

On Tue, 20 Apr 2021 at 17:54, Rob Herring wrote: > > On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE > wrote: > > > > > > > > On 4/20/21 4:45 PM, Rob Herring wrote: > > > On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE > > > wrote: > > >> > > >> Hi, > > > > > > Greg or Sasha won't know what

Re: Glitching protection

On Fri, 26 Mar 2021 at 19:36, Heinrich Schuchardt wrote: > > On 26.03.21 15:12, François Ozog wrote: > > Hi > > > > Trusted Firmware M recently introduced protection against glitching at > > key decision points: > > https://github.com/mcu-tools/mcuboot/pull/776 > > > > To me this is a key

Re: EFI_LOAD_FILE2 for initrd standardization

hardt > > > Sent: Monday, March 1, 2021 2:39 PM > > > To: Ilias Apalodimas ; Grant Likely > > > > > > Cc: Boot Architecture Mailman List ; > > > Samer > > > El-Haj-Mahmoud ; Ard Biesheuvel > > > ; Leif Lindholm > > > Subject: R

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

On Mon, 15 Feb 2021 at 18:13, Heinrich Schuchardt wrote: > > Describes deviations for ConnectController() and LoadImage(). > > Signed-off-by: Heinrich Schuchardt Acked-by: Ard Biesheuvel > --- > source/chapter2-uefi.rst | 11 +++ > 1 file changed, 11 inserti

Re: [PATCH] Override UEFI section 2.6 requirements

On Wed, 3 Feb 2021 at 15:04, Grant Likely wrote: > > > > On 02/02/2021 16:46, Peter Robinson wrote: > > * - EFI_PXE_BASE_CODE_PROTOCOL > > - Booting via the Preboot Execution Environment (PXE) is insecure. > >Loading via PXE is typically executed before launching the

Re: EBBR Biweekly for 18 Jan 2021

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

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

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 ;-) >&

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

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

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

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

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

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

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

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 >

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

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.

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

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

Re: Specifying the boot flow

On Fri, 2 Oct 2020 at 15:12, Heinrich Schuchardt wrote: > ... > Please read > > https://u-boot.readthedocs.io/en/latest/uefi/uefi.html#launching-a-uefi-binary-from-a-fit-image > > Up to now the signed fit image can provide the UEFI binary and the FDT. > > We could easily and probably should

Re: Specifying the boot flow

On Thu, 1 Oct 2020 at 22:30, Simon Glass wrote: > > Hi Grant, > > [who is 'nd'?] > That would be our bot who kindly omits of the obnoxious email footer on outgoing email if cc'ed. > On Wed, 30 Sep 2020 at 09:26, Grant Likely wrote: > > > > Hi Simon, > > > > Heinrich provided some great answers

Re: EBBR: RISC-V handoff to OS

f gp and tp. > > It seems to be necessary and sufficient for the firmware to follow: > > * Don't trust the values of tp and gp when entered > from the payloads world. > * If you need to change them, restore the values before returning. > * Never touch tp and gp after ExitBootS

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

On Tue, 15 Sep 2020 at 17:33, Grant Likely wrote: > > > > On 15/09/2020 15:16, Ard Biesheuvel wrote: > > On Tue, 15 Sep 2020 at 17:05, Grant Likely wrote: > >> > >> > >> > >> On 15/09/2020 14:46, Leif Lindholm wrote: > >&

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

On Tue, 15 Sep 2020 at 17:05, Grant Likely wrote: > > > > On 15/09/2020 14:46, Leif Lindholm wrote: > > On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote: > >>> The EFI stub in Linux removes /memreserve/ entries from the DT before > >>> handing it to the kernel proper. > >>> > >>> commit

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

On Tue, 15 Sep 2020 at 16:15, Grant Likely wrote: > > On 15/09/2020 14:02, Ard Biesheuvel wrote: > > On Tue, 15 Sep 2020 at 15:59, Grant Likely wrote: > >> > >> > >> > >> On 15/09/2020 13:35, Ard Biesheuvel wrote: > &g

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

On Tue, 15 Sep 2020 at 15:59, Grant Likely wrote: > > > > On 15/09/2020 13:35, Ard Biesheuvel wrote: > > On Tue, 15 Sep 2020 at 15:34, Grant Likely wrote: > >> > >> > >> > >> On 15/09/2020 13:25, Ard Biesheuvel wrote: > >>> On T

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

On Tue, 15 Sep 2020 at 15:34, Grant Likely wrote: > > > > On 15/09/2020 13:25, Ard Biesheuvel wrote: > > On Tue, 15 Sep 2020 at 15:22, Grant Likely wrote: > >> > >> On 15/09/2020 09:33, Heinrich Schuchardt wrote: > >>> Closes: #52 > >>&

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

On Tue, 15 Sep 2020 at 15:22, Grant Likely wrote: > > On 15/09/2020 09:33, Heinrich Schuchardt wrote: > > Closes: #52 > > > > The no-map property of the /reserved-memory device tree nodes is used to > > signal that a memory region shall not be accessed by the operating system, > > even not via

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

On Tue, 8 Sep 2020 at 09:39, Heinrich Schuchardt wrote: > > On 07.09.20 16:56, Grant Likely wrote: > > > > > > On 07/09/2020 15:55, Daniel Thompson wrote: > >> On Mon, Sep 07, 2020 at 03:22:22PM +0100, Grant Likely wrote: > >>> I've not heard back, and I've got a conflict this afternoon. I'm

Re: [PATCH] Refine firmware shared storage requirements.

On Wed, 2 Sep 2020 at 15:26, Heinrich Schuchardt wrote: > > On 02.09.20 12:11, Daniel Thompson wrote: > > On Tue, Sep 01, 2020 at 04:53:49PM +0200, Heinrich Schuchardt wrote: > >> On 01.09.20 16:49, Daniel Thompson wrote: > >>> On Tue, Sep 01, 2020 at 03:55:15PM +0200, Heinrich Schuchardt wrote:

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

On Wed, 2 Sep 2020 at 09:48, Heinrich Schuchardt wrote: > > On 9/1/20 10:51 AM, Ard Biesheuvel wrote: > > On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt wrote: > >> > >> On 8/31/20 9:01 PM, Ard Biesheuvel wrote: > >>> On Mon, 31 Aug 2020 a

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

On Tue, 1 Sep 2020 at 14:26, Peter Robinson wrote: > > On Tue, Sep 1, 2020 at 12:21 PM Grant Likely wrote: > > > > > > > > On 01/09/2020 12:06, Heinrich Schuchardt wrote: > > > On 9/1/20 12:45 PM, Grant Likely wrote: > > >> Early in EBBR discussions the decision was made that firmware should not

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

On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt wrote: > > On 8/31/20 9:01 PM, Ard Biesheuvel wrote: > > On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt > > wrote: > >> > >> Closes: #52 > >> > >> The no-map property of the /r

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

On Mon, 31 Aug 2020 at 19:38, Heinrich Schuchardt wrote: > > Closes: #50 > > ResetSystem() has return type void. So it cannot return EFI_UNSUPPORTED. > > Signed-off-by: Heinrich Schuchardt Acked-by: Ard Biesheuvel > --- > source/chapter2-uefi.rst | 7 --- > 1

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

On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt wrote: > > Closes: #52 > > The no-map property of the /reserved-memory DT node is used by Linux to > signal that a memory region shall not be mapped and that speculative access > shall not be permitted. > > The memory map returned by

Re: Storage of public key certificates for capsule authentication

On Mon, 31 Aug 2020 at 20:14, François Ozog wrote: > > > On Mon, 31 Aug 2020 at 19:07, Ard Biesheuvel wrote: > >> >> >> On Mon, 31 Aug 2020 at 19:30, François Ozog >> wrote: >> >>> >>> >>> On Mon, 31 Aug 2020 at 17:16, Ard B

Re: Storage of public key certificates for capsule authentication

On Mon, 31 Aug 2020 at 19:30, François Ozog wrote: > > > On Mon, 31 Aug 2020 at 17:16, Ard Biesheuvel wrote: > >> On Fri, 28 Aug 2020 at 19:03, Sughosh Ganu >> wrote: >> > >> > hello Heinrich, >> > >> > On Fri, 28 Aug 2020 at 20:24,

Re: Storage of public key certificates for capsule authentication

On Mon, 31 Aug 2020 at 19:00, François Ozog wrote: > > On Fri, 28 Aug 2020 at 18:03, Sughosh Ganu wrote: > > > hello Heinrich, > > > > On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt > > wrote: > > > >> On 28.08.20 14:19, Grant Likely wrote: > >> > > >> > > >> > On 28/08/2020 12:57, Sughosh

Re: Storage of public key certificates for capsule authentication

On Fri, 28 Aug 2020 at 19:03, Sughosh Ganu wrote: > > hello Heinrich, > > On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt > wrote: > > > On 28.08.20 14:19, Grant Likely wrote: > > > > > > > > > On 28/08/2020 12:57, Sughosh Ganu wrote: > > >> hi, > > >> I am currently working on adding support

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

On 5/13/20 2:48 PM, Grant Likely wrote: On 12/05/2020 18:54, Ard Biesheuvel wrote: On 5/12/20 7:23 PM, Grant Likely wrote: On 12/05/2020 18:16, Ard Biesheuvel wrote: On Tue, 12 May 2020 at 19:05, Grant Likely wrote: On 07/05/2020 20:15, Daniel Thompson wrote: On Thu, May 07, 2020

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

On 5/12/20 7:23 PM, Grant Likely wrote: On 12/05/2020 18:16, Ard Biesheuvel wrote: On Tue, 12 May 2020 at 19:05, Grant Likely wrote: On 07/05/2020 20:15, Daniel Thompson wrote: On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote: On Thu, 7 May 2020 at 16:50, Daniel Thompson

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

t;> On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote: > >>>> On 06.05.20 17:14, Ard Biesheuvel wrote: > >>>>> On 5/6/20 5:01 PM, Grant Likely wrote: > >>>>>> On 06/05/2020 15:56, Ard Biesheuvel wrote: > >>

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

On Wed, 6 May 2020 at 20:00, Grant Likely wrote: > > > > On 06/05/2020 17:57, Ard Biesheuvel wrote: > > On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt wrote: > >> > >> On 06.05.20 17:14, Ard Biesheuvel wrote: > >>> On 5/6/20 5:01 PM, Grant Likely

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

On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt wrote: > > On 06.05.20 17:14, Ard Biesheuvel wrote: > > On 5/6/20 5:01 PM, Grant Likely wrote: ... > >> Right, so the kernel stub is completely out and language is needed for > >> when the DTB becomes 'sedimented'.

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

On 5/6/20 5:01 PM, Grant Likely wrote: On 06/05/2020 15:56, Ard Biesheuvel wrote: On 5/6/20 4:54 PM, Grant Likely wrote: On 06/05/2020 15:52, Ard Biesheuvel wrote: On 5/6/20 4:38 PM, Grant Likely wrote: Only if the door is wide open. If there is a /real need/ for a limited set of changes

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

On 5/6/20 4:54 PM, Grant Likely wrote: On 06/05/2020 15:52, Ard Biesheuvel wrote: On 5/6/20 4:38 PM, Grant Likely wrote: Only if the door is wide open. If there is a /real need/ for a limited set of changes to the dtb, then those specific cases can be spelled out as things firmware

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

On 5/6/20 4:38 PM, Grant Likely wrote: On 06/05/2020 15:21, Ard Biesheuvel wrote: On Wed, 6 May 2020 at 15:56, Grant Likely wrote: On 05/05/2020 16:57, Ard Biesheuvel wrote: On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt wrote: ... As long as device-trees loaded by an EFI

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

On Wed, 6 May 2020 at 15:56, Grant Likely wrote: > > > > On 05/05/2020 16:57, Ard Biesheuvel wrote: > > On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt wrote: > >> > > ... > >> > >> As long as device-trees loaded by an EFI application l

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

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

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

ver implemented the old method, and support for the new method will be part of the v5.7 release. No other OSes implement it at all today afaik. > Cc: Andrei Warkentin > Cc: Francois Ozog > Cc: Ard Biesheuvel > Signed-off-by: Grant Likely > --- > source/chapter2-uefi.rst | 7 --- &

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

On 5/4/20 8:34 PM, Andrei Warkentin wrote: Hi Grant, Please also factor in requirements for how memory containing DT must be described in the memory map (Ard mentioned using EfiACPIReclaimMemory). Maybe something like: * Devicetree loaded at boot time must be contained in memory of type

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

On Tue, 5 May 2020 at 10:38, François Ozog wrote: > > On Tue, 5 May 2020 at 09:16, Ard Biesheuvel wrote: > > > On 5/4/20 8:34 PM, Andrei Warkentin wrote: > > > Hi Grant, > > > > > > Please also factor in requirements for how memory containing DT must

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

On Mon, 4 May 2020 at 19:43, Grant Likely wrote: > > Reference UEFI v2.8 throughout. v2.8 is the first version that defines > the RuntimeServicesSupported variable. > > Fixes: #40 > Signed-off-by: Grant Likely This should refer to UEFI 2.8 errata A directly, which is the release that replaces

Re: [RFC] Systemd-boot and EBBR

On Sat, 4 Apr 2020 at 12:50, Heinrich Schuchardt wrote: > > On 4/4/20 11:57 AM, François Ozog wrote: > > Hi, > > > > I instrumented boot on my Ubuntu 18.04 server right after systemd startup > > and caught an access to: > >

Re: [RFC]: Kernel lockdown & secureboot

On Wed, 19 Jun 2019 at 18:25, Jon Masters wrote: > > On 6/19/19 10:56 AM, Francois Ozog wrote: > > > I was tasked to come back to Linaro TSC with an answer on Linaro and > > kernel lockdown for UEFI SecureBoot, hence the call for feed back. > > > > So I did some research... The kernel lockdown

Re: Securing the boot flow in U-Boot

On Wed, 5 Jun 2019 at 21:28, Tom Rini wrote: > > On Wed, Jun 05, 2019 at 08:30:12PM +0200, Ard Biesheuvel wrote: > > On Wed, 5 Jun 2019 at 19:30, Tom Rini wrote: > > > > > > On Wed, Jun 05, 2019 at 06:14:08PM +0100, Mark Brown wrote: > > > > On

Re: Securing the boot flow in U-Boot

On Wed, 5 Jun 2019 at 19:30, Tom Rini wrote: > > On Wed, Jun 05, 2019 at 06:14:08PM +0100, Mark Brown wrote: > > On Wed, Jun 05, 2019 at 02:16:11PM +0200, Ard Biesheuvel wrote: > > > > > The idea of EBBR is to move away from a vertically integrated model, > > &

Re: Securing the boot flow in U-Boot

On Wed, 5 Jun 2019 at 14:59, Tom Rini wrote: > > On Wed, Jun 05, 2019 at 09:17:04AM +0100, Graeme Gregory wrote: > > On Wed, 5 Jun 2019 at 07:36, Ard Biesheuvel > > wrote: > > > > > On Wed, 5 Jun 2019 at 00:41, Tom Rini wrote: > > > > > > >

Re: Securing the boot flow in U-Boot

On Wed, 5 Jun 2019 at 13:14, Mark Brown wrote: > > On Wed, Jun 05, 2019 at 11:18:44AM +0100, Steve McIntyre wrote: > > > Nod. We're *way* past the time where this should have stopped. How on > > earth do we get to common DT useful for all bootloaders, OSes (etc.) > > if people still consider the

Re: Securing the boot flow in U-Boot

On Wed, 5 Jun 2019 at 00:41, Tom Rini wrote: > ... > It depends on what you mean by "OS provided". The DTS files come from > the Linux Kernel sources, full stop. That is the mistake we should try to fix. We have DT bindings, which define the contract between the OS on one side, and the

Re: Securing the boot flow in U-Boot

On Wed, 5 Jun 2019 at 00:34, Tom Rini wrote: > > On Tue, Jun 04, 2019 at 06:14:16PM -0400, Francois Ozog wrote: > > Le mar. 4 juin 2019 à 17:31, Tom Rini a écrit : > > ... > > I think it may be good to validate but not provide. There is no Linux > > provided ACPI table right ? So I get the point

Re: Securing the boot flow in U-Boot

On Tue, 4 Jun 2019 at 18:38, Francois Ozog wrote: > > > On Tue, 4 Jun 2019 at 10:57, Ard Biesheuvel > wrote: > >> >> Yes, that makes sense. But the problem is that UEFI secure boot does not >> support this model. An image is considered valid if it authenticates

Re: Securing the boot flow in U-Boot

On Tue, 4 Jun 2019 at 16:52, Francois Ozog wrote: > > > On Tue, 4 Jun 2019 at 10:37, Ard Biesheuvel > wrote: > >> On Tue, 4 Jun 2019 at 16:29, Heinrich Schuchardt >> wrote: >> > >> > >> > >> > On 6/4/19 4:20 PM, Ard Biesheuvel

Re: Securing the boot flow in U-Boot

On Tue, 4 Jun 2019 at 16:29, Heinrich Schuchardt wrote: > > > > On 6/4/19 4:20 PM, Ard Biesheuvel wrote: > > On Tue, 4 Jun 2019 at 16:17, Heinrich Schuchardt wrote: > >> > >> > >> > >> On 6/4/19 3:55 PM, Francois Ozog wrote: > >

Re: Securing the boot flow in U-Boot

On Tue, 4 Jun 2019 at 16:17, Heinrich Schuchardt wrote: > > > > On 6/4/19 3:55 PM, Francois Ozog wrote: > > On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel > > wrote: > > > >> > >> > >> On Tue, 4 Jun 2019 at 15:44, Francois Ozog > >&g

Re: Securing the boot flow in U-Boot

On Tue, 4 Jun 2019 at 15:55, Francois Ozog wrote: > > > On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel > wrote: > >> >> >> On Tue, 4 Jun 2019 at 15:44, Francois Ozog >> wrote: >> >>> Hi Ard, >>> >>> On Fri, 31 May 2019 at

Re: Securing the boot flow in U-Boot

On Tue, 4 Jun 2019 at 15:44, Francois Ozog wrote: > Hi Ard, > > On Fri, 31 May 2019 at 13:35, Ard Biesheuvel > wrote: > >> On Fri, 31 May 2019 at 19:25, Ilias Apalodimas >> wrote: >> > >> > Hi Grant, >> > > I see two ways to handle this

Re: Securing the boot flow in U-Boot

On Fri, 31 May 2019 at 19:25, Ilias Apalodimas wrote: > > Hi Grant, > > I see two ways to handle this that fits with the Secure Boot > > authentication path: > > > > Option 1: Leave it to the OS loader > > We could simply say that if the OS wants to replace the DTB, then it > > should take care

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

On Wed, 15 May 2019 at 12:24, Hsin-Yi Wang wrote: > > On Tue, May 14, 2019 at 11:42 PM Mike Rapoport wrote: > > > I'm not sure if early console is available at the time kaslr_early_init() > > is called, but if yes, running with memblock=debug may shed some light. > > > > > I didn't trace the

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

On 27 September 2018 at 13:46, Daniel Thompson wrote: > On Thu, Sep 27, 2018 at 10:53:51AM +, Udit Kumar wrote: >> > -Original Message- >> > From: Grant Likely >> > Sent: Wednesday, September 26, 2018 6:01 PM >> > To: Udit Kumar ; boot-architecture@lists.linaro.org; >> >

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

On Mon, 24 Sep 2018 at 15:54, Grant Likely wrote: > > Fill out the requirements for AArch32 systems. Not much needs to be > specified here other than the different privilege modes defined by > ARMv7 and below. > > Resolves: #15 > Signed-off-by: Grant Likely > --- > source/chapter1-about.rst

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

On 12 July 2018 at 15:12, Mark Brown wrote: > On Thu, Jul 12, 2018 at 01:50:45PM +0100, Daniel Thompson wrote: > >> The OS will discover the variable is non-modifiable when it tried to >> set it. Won't the current proposal mislead standards compliant use of >> GetVariable()? For example does it

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

On 18 May 2018 at 13:49, Grant Likely <grant.lik...@arm.com> wrote: > On 18/05/2018 12:40, Ard Biesheuvel wrote: >> >> On 18 May 2018 at 13:37, Grant Likely <grant.lik...@arm.com> wrote: >>> >>> On 18/05/2018 12:13, Andre Przywara wrote: >>>>

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

On 30 April 2018 at 15:57, Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> wrote: > Hi Ard, > >> -Original Message- >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> Sent: Sunday, April 29, 2018 12:21 AM >> To: Chang, Abne

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

On 28 April 2018 at 15:46, Chang, Abner (HPS SW/FW Technologist) wrote: > I am behind this topic and not familiar with embedded system with U-boot. > Some dumb questions below. > Why there is no persistent storage on platform? I thought at least EEPROM is > on platform.