boot-architecture

boot-architecture@lists.linaro.org

7 participants
651 discussions

[PATCH] trivial: Fix typo in chater 3 title

by Grant Likely

Fixes: #42 Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/chapter3-secureworld.rst | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst index 4e9fa61..9c51bca 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -****************************** -Priviledged or Secure Firmware -****************************** +***************************** +Privileged or Secure Firmware +***************************** AArch32 Multiprocessor Startup Protocol ======================================= -- 2.20.1

5 years, 4 months

DTE call meeting notes

by François Ozog

Hi, Thank you for your participation in yesterday's call. Here are meeting notes that you can update <https://docs.google.com/document/d/13TwImAK9bta5_qY2PAFplO6pypd0hpNQNkpkI_W…>as you see fit (I think the permissions associated with this new link are correct). Survey was answered by 12 participants while there were 27 people on the call. I would be more comfortable to select a time with more responses. Cordially, François-Frédéric -- François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years, 4 months

DTE discussion agenda

by François Ozog

Hi, Here is the agenda for today's call <http://meet.google.com/oua-wrbf-ppi>: - DTE activities for the next cycle and overall organization - Regular meeting setup (survey <https://www.surveymonkey.com/r/F72TLPF>) - System Device Tree status and roadmap (JIRA?) this topic depends on presence of SDT stakeholders - Device Tree specification: its role in the future and short term - Device Tree lifecycle (what happens to a DT from TFA to OS): a presentation and a discussion Cheers FF

5 years, 4 months

DTE weekly

by François Ozog

Hi, I am taking over Steve to drive Device Tree Evolution project except the System Device Tree which will continue to evolve under the leadership of Nathalie and Stefano. To discuss: - lifecycle (how TFA, OP-TEE, U-Boot and Operating Systems deal with DT and pass information between them) - overlays - unified repo - summary of System DT activities I'd like to set up a weekly call starting next week. Please state the best timeslot in this poll: https://www.doodle.com/poll/k57zhwa4q9caivgy (the poll proposes the timeslot to be repeated). By next week, Joakim, Ilias and myself will have prepared some content to launch/continue debate. Cordially, François-Frédéric -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years, 4 months

Invitation: DTE discussion @ Mon 4 May 2020 18:00 - 19:00 (CEST) (boot-architecture@lists.linaro.org)

by François Ozog

You have been invited to the following event. Title: DTE discussion This is a one off meeting unless we find a sustainable timeslot for India participants. When: Mon 4 May 2020 18:00 – 19:00 Central European Time - Paris Joining info: Join with Google Meet https://meet.google.com/oua-wrbf-ppi Join by phone +33 1 87 40 48 87 (PIN: 588964477) More phone numbers: https://tel.meet/oua-wrbf-ppi?pin=4737911870439&hs=0 Calendar: boot-architecture(a)lists.linaro.org Who: * François Ozog- organiser * boot-architecture(a)lists.linaro.org * team-ledge * dte-all Event details: https://www.google.com/calendar/event?action=VIEW&eid=NzRkanQyMXZtOWwzc2xic… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account boot-architecture(a)lists.linaro.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 4 months

Re: DTE-8 DeviceTree lifecycle: the basics

by François Ozog

+boot architecture Le sam. 25 avr. 2020 à 19:26, François Ozog <francois.ozog(a)linaro.org> a écrit : > Hi > > I would like to start the discussion on DTE-8 as LEDGE is going to need > results soon. I'd like to keep it high level, general principles, not too > precise on implementation details. Let's take overlays and other > complications out of the discussion until we share a vision for the basics. > > When we have concluded this discussion cycle we will need to address: > - DTE-8 DeviceTree lifecycle: BL32 (BL32 may mask some devices until > given credentials...) > - DTE-8 DeviceTree lifecycle: overlays > - DTE-8 DeviceTree lifecycle: tooling > - DTE-8 DeviceTree lifecycle: chain of trust > > Is the following correct? > Is it complete on the target reduced scope? > Is the discussion series/roadmap complete, is the order right ? > > Cordially, > > François-Frédéric > > > I - Definitions > > Let's consider there are four trees used by the following entities: > - TFA which spans BL1, BL2, BL31 has a tree <TFA> which originates from > tfa.dtb > - BL32 (let's assume OP-TEE) has a tree <BL32> which originates from > bl32.dtb > - BL33 (let's assume U-Boot) has a tree <BL33> which originates from > bl33.dtb > - THING, the "thing" that is booted by BL33, has a tree <THING> which > originates from thing.dtb and manipulations from BL33. > > The THING can be a Linux kernel, a bsd kernel, grub, shim<arch>.efi, > efibootguard.efi, Xen, Hafnium or many other possibilities. > BL33 is assumed to be U-Boot but it can be EDK2, Linux Kernel, Hafnium, > Xen or other thing. > > A tree is not dtb. A tree is the result of loading a DTB with or without > manipulations. > > II - Build time assumptions > > It is assumed that TFA, BL32 and BL33 are board specific while THINGS is > board agnostic. > > As a result of this architectural decision: > - tfa.dtb, bl32.dtb and bl33.dtb can be built by the build process of the > respective entity TFA, BL32, BL33. > - thing.dtb is purely describing hardware and has no "chosen" nodes for > instance, it may contain architectural/platform/board specific > "reserved-memory". In other words, nothing that can tie it to a particular > "thing". > > All DTBs shall be derived from a single source repository. > > The bindings of a single piece of hardware, may differ depending on the > entity that needs it (there are many ways to implement that aspect, let's > not talk about implementation yet). > For instance, a display panel for BL33 can be represented as a single > small node while the same display panel can be controlled out of several > large nodes by a downstream Operating System. > > III - Lifecycle > > Out of all possible transitions, let's consider BL31->BL33 and > BL33->THING. Transitions are opportunities to pass DT information from one > entity to the other that complements the static *.dtb . For instance, > passing PSCI interface information, memory reservations, PCI IO ranges... > > III.1 BL31->BL33 > > III.1.1 nature of manipulations > typically, PSCI interface may be injected as well some memory > reservations. > > III.1.2 manipulation operational considerations > There are three possibilities for passing this information: > - BL31 manipulates the BL33 tree to add/change nodes > - BL33 asks BL31 to add/change nodes > - BL31 passes an interim tree that BL33 will merge into his. > > Current wisdom is BL31 manipulates the BL33 tree. > > III.2 BL33->THING > > III.2.1 nature of manipulations > * operational > - board information (part numbers, serial numbers...) > - memory layout (beyond the typical 4G) > - IO specifics (PCIe...) > - reserved areas for runtime services (UEFI for instance) > - os.dtb > * THING dependent elements > - chosen for "command line" or other aspects > > III.2.2 manipulation operational considerations > In the case of UEFI interface, os.dtb passed as DT artifact or a UEFI > table shall be referring to the same tree (a single tree in memory, two > access methods). > > BL33 will operate all necessary manipulations on os.dtb before passing it > to the THING. The THING (grub, efiapp, kernel) can further operate > manipulations, it is outside scope of the discussion. > > > > -- > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > T: +33.67221.6485 > francois.ozog(a)linaro.org | Skype: ffozog > > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years, 4 months

[RFC] Systemd-boot and EBBR

by François Ozog

Hi, I instrumented boot on my Ubuntu 18.04 server right after systemd startup and caught an access to: /sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f This led to: https://systemd.io/DISCOVERABLE_PARTITIONS/ And then: https://systemd.io/BOOT_LOADER_INTERFACE/ https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ My server is configured with Grub to boot (grub and kernel on a HD, root FS of NVME as grub do not have nvme driver for my card) but the udev is still checking those systemd-boot variables. >From a boot loader perspective, we have the following EFI applications: - Grub2 - EFIBootGuard (used by CIP) - Systemd-boot (used by ?) Regardless of the loader, I assume we need to ensure whatever option is selected by solution builders, they can implement it with our U-Boot reference implementation of UEFI. The Systemd boot-bless seems of high interest for rolling back UEFI update capsules of firmware... I'd be happy to get some feed back on : - the systemd-boot technology - whether we need to implement the above specs in our UEFI implementation - whether this has an influence on EBBR Cheers FF PS: other references https://manpages.debian.org/testing/systemd/systemd-boot.7.en.html https://manpages.debian.org/testing/systemd/systemd-bless-boot.service.8.en… http://man7.org/linux/man-pages/man1/bootctl.1.html -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years, 5 months

Re: RFC: EBBR specification update

by Heinrich Schuchardt

On 3/11/20 3:20 PM, Francois Ozog wrote: > > > On Wed, 11 Mar 2020 at 13:42, Francois Ozog <francois.ozog(a)linaro.org > <mailto:francois.ozog@linaro.org>> wrote: > > > > On Wed, 11 Mar 2020 at 12:45, Daniel Thompson > <daniel.thompson(a)linaro.org <mailto:daniel.thompson@linaro.org>> wrote: > > On Wed, Mar 11, 2020 at 11:20:17AM +0100, Francois Ozog wrote: > > On Wed, 11 Mar 2020 at 07:48, Heinrich Schuchardt > <xypron.glpk(a)gmx.de <mailto:xypron.glpk@gmx.de>> wrote: > > > On 3/11/20 12:04 AM, Heinrich Schuchardt wrote: > > > > On 3/10/20 7:37 PM, Francois Ozog wrote: > > > >> Le mar. 10 mars 2020 à 18:37, Daniel Thompson > > > >> <daniel.thompson(a)linaro.org > <mailto:daniel.thompson@linaro.org>> a écrit : > > > >>> On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog > wrote: > > > >>>> This is driven by the BL2 which is platform specific > and I am not sure > > > >>>> we can have any influence. > > > >>>> The flashimage.bin in a number of system consists of a > (blob) FIP that > > > >>>> has BL2, SCP stuff, BL31, BL32, BL33. > > > >>>> Ilias upstream U-Boot patches to change from "ADR" to > "ADRL" because > > > >>>> the code grew too much. > > > >>> > > > >>> I'm not quite sure I understand the concern here. > > > >>> > > > >>> Are you still working on systems where the boot ROM > mandates using MBR > > > >>> partitioning and attempting to put secure boot on it? > If so perhaps we > > > >>> could simply discontinue MBR support for systems with > secure boot! > > > >>> > > > >> > > > >> Well..... we want Products on the market to benefit from > EBBR compliance > > > >> rather than two years from now. So MBR is inevitable. > And is not that a > > > >> pain ;-) Of course its not as clean as we would like but > “sales first”! > > > > > > > > A typical problem is that a SoC has an entry address > within the first 17 > > > > KiB, e.g. the Allwinner CPUs want a firmware entry point > at 0x2000. If I > > > > correctly understand the UEFI standard, one might use > PartitionEntryLBA > > > > to place the GPT Partition Entry Array behind the > firmware in this case. > > > > > > > > > > In the expert mode of gdisk there is command 'j' for moving > the GPT > > > Partition Entry Array to an arbitrary sector. This will > protect the area > > > between the GPT header and the GPT Partition Entry Array > from being used > > > for a partition. The same can be done with parameter -j of > sgdisk. > > > > > > Furthermore gdisk supports creating a hybrid MBR. This > allow to have > > > GUID partition table and a MBR partion table at the same > time where the > > > MBR partition table mirrors up to three GPT partitions and > the fourth > > > MBR partition is used to protect the GUID partition table. > > > > > > So requiring GPT and having boards only supporting booting > from an MBR > > > partition (like the Raspberry) seems not to be exclusive. > > > > > > > That sounds like a great solution! > > The last time we discussed this there was *very* strong opposition > during meetings to hybrid partitioning and IIRC language was > added to > the spec to prohibit it. > > Hybrid partitioning is a problem because it imposes to difficult > to meet > constraints on partitioning tools provided by the operating system. > > In other words if we permit hybrid partitioning in order that > boot code > can find the firmware then the operating system would inherit a > duty to > not to screw up the firmware loading when it modifies the partition > tables. It is hard to express how the OS should go about that. > > Hence the current approach where we accept that MBR partitioning > offers an inferior feature set to GPT. > > > We have the following cases: > > - FW compatible with GPT (I mean firmware can be searched based on > GUID partition) > Ok > > - FW that uses offsets and can be positioned at LBA >= 33 > Ok > Need to define a protective partition > > - FW that uses offsets and can be positioned such that space between > LBA-2 and LBA-33 is used. > Ok in theory as the header states where the partition entries > location is specified in a GPT_HEADER "Starting LBA of array of > partition entries". > Linux kernel properly loads the partition entries if we push them > after 16MB. > > read_lba <https://elixir.bootlin.com/linux/latest/ident/read_lba>(state, le64_to_cpu > <https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu>(gpt->partition_entry_lba) > > But I bet 2 is hardcoded in many tools... > > If I had done my homework properly, I would have seen that > U-Boot CONFIG_EFI_PARTITION_ENTRIES_OFF is just configuring that... CONFIG_EFI_PARTITION_ENTRIES_OFF is only relevant if you use U-Boot to create a GUID partition table. When reading a GPT U-Boot correctly considers the current value of PartitionEntryLBA. Best regards Heinrich > So there is some experience in playing with that.... I'd be happy to > read ;-) > > - FW that supposes LBA-1 (macchiatobin the firmware blob that > contain TF-A must be here) > > In theory OK as Linux will detect bad signature and use the > alternate GPT > > good_pgpt = is_gpt_valid > <https://elixir.bootlin.com/linux/latest/ident/is_gpt_valid>(state, GPT_PRIMARY_PARTITION_TABLE_LBA > <https://elixir.bootlin.com/linux/latest/ident/GPT_PRIMARY_PARTITION_TABLE_L…>, > &pgpt, &pptes); > if (good_pgpt) > good_agpt = is_gpt_valid > <https://elixir.bootlin.com/linux/latest/ident/is_gpt_valid>(state, > le64_to_cpu > <https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu>(pgpt->alternate_lba), > &agpt, &aptes); > if (!good_agpt && force_gpt <https://elixir.bootlin.com/linux/latest/ident/force_gpt>) > good_agpt = is_gpt_valid > <https://elixir.bootlin.com/linux/latest/ident/is_gpt_valid>(state, lastlba, &agpt, &aptes); > > We loose the protective nature of GPT but it sounds like it will be > working. > > That said, we could enhance the EFI specification so that: > - we have a firmware protective partition > - the start LBA of the "GPT protective partition (0xEE)" is used to > define the GPT header placement instead of 1. > image.png > > Daniel. > > > > -- > > François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ > T: +33.67221.6485 > francois.ozog(a)linaro.org <mailto:francois.ozog@linaro.org> > | Skype: ffozog > > > > > -- > > François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ > T: +33.67221.6485 > francois.ozog(a)linaro.org <mailto:francois.ozog@linaro.org> | Skype: ffozog > >

5 years, 6 months

Re: RFC: EBBR specification update

by Francois Ozog

Le mar. 10 mars 2020 à 18:46, Mark Brown <broonie(a)kernel.org> a écrit : > On Tue, Mar 10, 2020 at 05:37:29PM +0000, Daniel Thompson wrote: > > On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote: > > > > Thanks Leif for the links. I tend to like the ETSI one because it is > > > somewhat complete on necessary english grammar stuff. > > > But I am flexible, important we state explicitly the reference > > > document and we use the language constructs. > > > Does ETSI offer us "features" that are missing from RFC 2119. > > > Personally I would favour RFC 2119 simply because it is so much better > > known than the ETSI drafting rules. > > > If you cite RFC 2119 and I don't have to go and read anything... and > > even if I did it is super concise and quick to read. > > > Cite ETSI drafting rules, clause 3 and I have to put in a lot more > > effort. > > The RFC 2119 usage of "MUST" is also a more standard English usage (in > that people are more likely to be familiar with it) than the ETSI SHALL > so there's a bit of a comprehensibility win. RFC2119 sold on my side ;-) > > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years, 6 months

FYI: Intel Vulnerability Serious But Unlikely, Experts Say

by Francois Ozog

Well, if you think IIot and Edge, you have physical access and the system is thus vulnerable.... https://www.sdxcentral.com/articles/news/intel-vulnerability-serious-but-un… Cheers FF PS: Intel CSME is an auxiliary micro-controller much like the SCP but with the capability to access the whole DRAM and having some TrustZone style role. -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years, 6 months

← Newer
1
...
28
29
30
31
32
33
34
...
66
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture