Dear all,
in the DTE meetings we have been discussing how we should add signatures
to device-trees.
Due to the way how libfdt adds properties the sanest place to add
metadata is before the memory reservation block. I have tested this with
the U-Boot->GRUB->Linux boot sequence.
See my slides at
https://github.com/xypron/dte/blob/master/DTE%20-%20Adding%20Metadata.pdf
and the test program I used
https://github.com/xypron/dte/blob/master/src/add_metadata_area.c
In the next DTE meetings we could discuss drafting a specification
change for this.
Best regards
Heinrich
All,
Sorry for the late notice but I am canceling the meeting for tomorrow,
Monday May 3. Something came up for me that I must attend to. Also,
Monday is a holiday in the UK. Grant will not be attending and pehaps
others would not as well.
Frank has been working to prepare for the discussion of the next DTB
format so we will start that discussion next time.
Thanks and sorry again,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi all,
Next EBBR meeting is ON for Monday, 26 April 2021 at 16:00 GMT. Dial in
details are below.
As discussed at last meeting, the EBBR biweekly series will be dedicated
to tech topics around boot standardization until such time as another
EBBR release needs to be considered.
This Monday, Jose Marinho will be presenting the proposed firmware
update protocol
https://lists.linaro.org/pipermail/boot-architecture/2021-April/001799.html
Email me if you'd like to propose a tech topic for an upcoming EBBR meeting.
g.
---
Grant Likely is inviting you to a scheduled Zoom meeting.
Topic: EBBR Biweekly
Time: 18 Jan 2021, 16:00-17:00 GMT
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511
Passcode: 490324
One tap mobile
+14086380968,,92081365511#,,,,*490324# US (San Jose)
+16465189805,,92081365511#,,,,*490324# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose)
+1 646 518 9805 US (New York)
+1 346 248 7799 US (Houston)
Meeting ID: 920 8136 5511
Passcode: 490324
Find your local number: https://armltd.zoom.us/u/aelJgr9ZAW
Good afternoon,
Linaro and Arm have been standardizing the FW update mechanism for A-class devices.
The intention behind the standardization is to enable generic implementations of the UEFI UpdateCapsule where:
1) the FW store resides in Secure World controlled flash;
2) there is FW bank duplication (A/B model).
Arm published a specification, at Alpha quality, that defines the FW update model and a set of tools catering for 1) and 2) : https://developer.arm.com/-/media/Files/pdf/FWU-PSA-A_DEN0118_1.0ALP3.pdf
Arm welcomes feedback on the specification.
Please direct feedback to either myself or Grant Likely
The FW update work will be discussed at the EBBR biweekly call this Monday (26th April).
Regards,
Jose
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
We have the DTE call today.
If Frank is ready to talk about DTB format evolution we will do that.
If not we need agenda items.
4PM UK, 11AM US Eastern
Zoom Meeting ID: 961 7042 8801
Passcode: 8250
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Interesting topic.
---------- Forwarded message ---------
From: Zelalem Aweke via TF-A <tf-a(a)lists.trustedfirmware.org>
Date: Fri, 16 Apr 2021 at 17:14
Subject: [TF-A] [RFC] TF-A threat model
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Hi All,
We are releasing the first TF-A threat model document. This release
provides the baseline for future updates to be applied as required by
developments to the TF-A code base. Please review the document provide
comments here:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9627.
Thanks,
Zelalem
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
Hi,
next week agenda is:
- Industrial Internet Consortium patterns update
- Civil Infrastructure Project liaison update
- Open System Firmware
<https://www.opencompute.org/projects/open-system-firmware> presentation
and discussion
On this last topic, I'm glad to welcome Ron Minnich who will present Open
System Firmware initiatives from Open Compute Project. (Ron has a long
history in firmware with creation of CoreBoot and more recently LinuxBoot).
SystemReady standards define technical requirements to ensure decoupling
between firmware and operating systems.
I see OSF efforts complementing the technical standards with firmware
business lifecycle to guarantee openness and freedom of use. A checklist
<https://www.opencompute.org/wiki/Open_System_Firmware/Checklist> helps
qualify systems per those openness and freedom of use criteria.
I'd like us to be able to have an informed discussion on the checklist
(meaning need to read before the call ;-) to see how much it may apply
to Trusted
Substrate <http://trusted-substrate.org>, and wether it would make sense
(if technically feasible) to setup a liaison between our two groups.
Cordially,
FF
PS: I will be sending additional invites for new attendees
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
Hi
even though I am not an "ecology activist", sustainability is a topic dear
to me. And it can translate into firmware world... So I am targeting this
message to the audience of the two firmware communities I know and hope it
is okay to do so.
March 2021 was a big date for Open Source Firmware
<https://www.opencompute.org/projects/open-system-firmware>: that was the
deadline to get
"
Owners must be able to change firmware and share it -- including any binary
components -- with other owners. Starting in March, 2021, OCP badging for
servers will require that systems support OSF.
"
That's a big step towards sustainability in the OCP world.
More generally, we should have the capacity to characterize firmware
sustainability for post official firmware End Of Life.
What about the following :
level 0: system cannot evolve or be updated.
level 1: the system can be updated to a bootable minimal functionality with
open community effort.It may lack some features. For instance, you can
still look at your TV but lose Netflix 4K because the owners (in OCP sense)
cannot get a signed Netflix TA (either updated or not).
level 2: the TAs and other binaries can be made available (signed) to the
ones maintaining open source firmware projects (TF-A, OP-TEE, U-Boot...).
For instance, owners (in the OCP sense) can get the updated Netflix TA
binary (updated or not) and sign it for inclusion.
level 3: all firmware components are open source and can thus be community
maintained.
I think :
Level 2 is the right balance between business value and "ecological" goal
of sustainability.
Level 3 is not mandatory and not the ultimate goal.
Is this a good way to characterize sustainability?
How to make at least level 2 happen ?
Cheers
FF
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
