EBBR Biweekly cancelled today

[Grant Likely]

I don't have anything for the agenda, so there is no meeting today

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

Re: Any topics for EBBR today?

[Grant Likely]

I haven’t heard anything. Cancelled for this week

g.

—-
Grant Likely
CTO, Linaro Ltd.

> On 11 Apr 2022, at 09:39, Grant Likely  wrote:
> 
> I don’t have any agenda items. If I don’t hear anything in the next few 
> hours then I will cancel the biweekly.
> 
> g.
> 
> —-
> Grant Likely
> CTO, Linaro Ltd.
> ___
> boot-architecture mailing list -- boot-architecture@lists.linaro.org
> To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
___
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

Any topics for EBBR today?

[Grant Likely]

I don’t have any agenda items. If I don’t hear anything in the next few hours 
then I will cancel the biweekly.

g.

—-
Grant Likely
CTO, Linaro Ltd.
___
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

SystemReady IR Architect job posting

[Grant Likely]

Hi all,

Normally this isn't the right place for job postings, but in this case it is 
directly relevant to EBBR and Arm's SystemReady program. Arm is looking to 
backfill my position with someone who can be responsible for the SystemReady IR 
program long term direction. If an of you are interested, or can think of 
someone who would be a good candidate, then please pass this link on to them.

Thanks,
g.

https://experienced-arm.icims.com/jobs/5461/director---technical-lead/job?mode=view
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

EBBR biweekly on today

[Grant Likely]

Hi everyone,

It has been many weeks since the last EBBR biweekly, so even though I don’t 
have much of an agenda, I will hold the call today in a little under an hour. 
If we don’t have enough to fill an hour then it can just be a short call.

Dial in details are below

Agenda:
- EBBR maintainership
- Restricting console on secure boot
- other business

—-


Join Zoom Meeting

Date: 14 Mar 2022

Time: 15:00 GMT

https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511 Password: 490324

One tap mobile+14086380968,,92081365511#,,#,490324# US (San 
Jose) +16465189805,,92081365511#,,#,490324# US (New York)



—-
Grant Likely
Senior Technical Director, Arm
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

EBBR Biweekly cancelled this week

[Grant Likely]

Hi all,

I’m cancelling this weeks EBBR biweekly as I wasn’t able to send out a reminder 
and agenda last week. Next meeting is 14th March 2022.

As always, email me if you have a topic for the agenda.

g.

—-
Grant Likely
Senior Technical Director, Arm
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

Reminder: EBBR Biweekly 31 Jan 2022

[Grant Likely]

Hi everyone,

Just a reminder that the EBBR biweekly is on today at 15:00 GMT. I've 
got the following agenda items:


- Disable U-Boot console for secure boot (Ilias)
- SystemReady IR 2.0 draft requirements
- Any other business

Here are the conference details:

Join Zoom Meeting 
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09


Meeting ID: 920 8136 5511 Password: 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)

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

EBBR Biweekly is ON today - 17th January

[Grant Likely]

Hi all,

Just a quick note that the EBBR meeting scheduled for today is indeed
on. Ilias and Jose will be presenting the work done on A/B updates which
should be interesting to the EBBR audience.

Here's the agenda and dial in details:

Agenda:
 -  A/B Update Presentation (Ilias & Jose)
 -  Requirement to disable or remove command line when secure (Ilias)

Zoom details:

17th Jan 2022, 15:00 GMT

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511 Password: 490324

One tap mobile +14086380968,,92081365511#,,#,490324# US (San Jose)
+16465189805,,92081365511#,,#,490324# US (New York)
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

Re: EBBR Biweekly - 6 Dec 2021

[Grant Likely]

On 06/12/2021 15:31, Simon Glass wrote:

Hi Grant,

Sorry I was wondering if this was happening/agenda, and just saw this.
Next time.


Sorry for the late notification. I'll try to get the reminder out the
week before the next meeting.

Notes can be found here:
https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2021.12.06



I do hope that fwup can play a role in firmware update. We plan to try
this out with Chrome OS AP update (and VBE).


Absolutely. There has been some work already done with fwupd and LVFS to
make firmware update seamless.




Re disabling the command line, U-Boot has a 'bootsecure' thing in the
devicetree which allows disabling the command line, either in the
build or from a prior stage. If this is generally useful we could add
it to the generic /options node perhaps.

Regards,
Simon

On Mon, 6 Dec 2021 at 07:57, Grant Likely  wrote:


I didn't specify the time. The meeting is at 15:00 GMT, 07:00 PST


From: boot-architecture  on behalf of 
Grant Likely 
Sent: 06 December 2021 14:48
To: boot-architecture@lists.linaro.org
Subject: EBBR Biweekly - 6 Dec 2021

Just a reminder, the EBBR biweekly is on today (about 15 minutes from
now). I try to send these reminders out the week before, but it fell off
my radar last week. Here is what I have on the agenda for today:

Agenda
* Requirements on A/B update (Ilias)
* Can the OS be responsible for firmware update? (Ilias) - e.g., via
fwupd or similar to stage UpdateCapsule()
* Requirement to disable or remove command line when secure (Ilias)

---
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: EBBR Biweekly - 6 Dec 2021

[Grant Likely]

I didn't specify the time. The meeting is at 15:00 GMT, 07:00 PST


From: boot-architecture  on behalf 
of Grant Likely 
Sent: 06 December 2021 14:48
To: boot-architecture@lists.linaro.org
Subject: EBBR Biweekly - 6 Dec 2021

Just a reminder, the EBBR biweekly is on today (about 15 minutes from
now). I try to send these reminders out the week before, but it fell off
my radar last week. Here is what I have on the agenda for today:

Agenda
* Requirements on A/B update (Ilias)
* Can the OS be responsible for firmware update? (Ilias) - e.g., via
fwupd or similar to stage UpdateCapsule()
* Requirement to disable or remove command line when secure (Ilias)

---
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

EBBR Biweekly - 6 Dec 2021

[Grant Likely]

Just a reminder, the EBBR biweekly is on today (about 15 minutes from
now). I try to send these reminders out the week before, but it fell off
my radar last week. Here is what I have on the agenda for today:

Agenda
* Requirements on A/B update (Ilias)
* Can the OS be responsible for firmware update? (Ilias) - e.g., via
fwupd or similar to stage UpdateCapsule()
* Requirement to disable or remove command line when secure (Ilias)

---
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reminder EBBR biweekly today at 15:00 GMT

[Grant Likely]

Hi everyone,

This is just a reminder that the next EBBR biweekly is today at 15:00
GMT. Zoom details are below, and here is today's agenda:

Agenda:
- UEFI EBBR Conformance profile (Jose)
  https://bugzilla.tianocore.org/show_bug.cgi?id=3591
- Requirements for measured boot (Ilias)
- Any other business

I'm also keeping track of agenda items on the EBBR wiki which you can
find here:

https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511 Password: 490324
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Native PE/COFF support for aarch64

[Grant Likely]

Ah, I just saw the email on the other thread about this. Looks like the
DSG team here at Arm is picking up the work.

g.

On 10/09/2021 17:38, Grant Likely wrote:

Hi Francois,

Can you elaborate please? Who is actually picking up this work?

g.

On 10/09/2021 17:12, François Ozog wrote:

Hi,

this mail just to inform you that there is a plan to support native
building of PE/COFF for aarch64 and in particular to support SBAT for
shim.efi.

It is seen possible to deliver this by the end of October (this is
just an
early estimate).

Cordially

FF



IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Native PE/COFF support for aarch64

[Grant Likely]

Hi Francois,

Can you elaborate please? Who is actually picking up this work?

g.

On 10/09/2021 17:12, François Ozog wrote:

Hi,

this mail just to inform you that there is a plan to support native
building of PE/COFF for aarch64 and in particular to support SBAT for
shim.efi.

It is seen possible to deliver this by the end of October (this is just an
early estimate).

Cordially

FF



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

EBBR Cancelled for 16th Aug 2021

[Grant Likely]

Hi all,

Sorry for the last minute notice, but I need to cancel the EBBR meeting
due to a conflict that I cannot move.

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [EBBR PATCH] Relax Update requirements by dropping ESRT

[Grant Likely]

On 26/07/2021 16:44, Heinrich Schuchardt wrote:



On 26.07.21 16:12, Grant Likely wrote:

The ESRT support in U-Boot is immature and not ready for mainline.
Temporarily remove the ESRT requirement so that platforms can
meaningfully
conform to EBBR. When ESRT functionality has matured this requirement
will
can be brought back in.

Signed-off-by: Grant Likely 


Hello Grant,

could you, please, share which issues have to be solved.



The high level issue is testing with fwupd has only started recently.
For the specific problems, Ilias has been working through them and most
of them may be solved at this point. However, that doesn't do anything
for the folks that are committed to any of the existing release (2021.07
or earlier).

With regard to the SystemReady-IR program, I've received feedback from
vendors that even recent releases will not be able to meet EBBR
compliance without backporting ESRT patches from mainline. v2021.04 and
v2021.01 are both being used in stabilized BSPs from vendors.

I'm comfortable dropping ESRT /for now/ because the integration work
with fwupd and other agents hasn't been done. Even if a platform based
on current released U-Boot provided an ESRT, it is unlikely that it will
work out of the box with fwupd anyway, so the ESRT requirement isn't yet
providing any value.

I suggest that ESRT gets brought back in for the next major release of
EBBR (in approx 1 year) once integration is tested and we have suitable
test cases.

g.





---

Hi all,

As described above, I'm proposing ESRT gets dropped for v2.0.x series of
EBBR, with the plan to add it back in ebbr-next. Once there are U-Boot
releases that have a solid ESRT implementation that works for fwupd,
mender.io and possibly Windows Update then I would like to bring it back
in.  Here's the pull request for the change in github:

https://github.com/ARM-software/ebbr/pull/86

Thoughts?

g.

  source/chapter2-uefi.rst | 13 +
  1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 092fd1d..4c4cacb 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -467,9 +467,7 @@ EBBR platforms are required to implement either an
in-band or an out-of-band fir
  If firmware update is performed in-band (firmware on the application
processor updates itself),
  then the firmware shall implement the `UpdateCapsule()` runtime
service and accept updates in the
  "Firmware Management Protocol Data Capsule Structure" format as
described in [UEFI]_ § 23.3,
-"Delivering Capsules Containing Updates to Firmware Management
Protocol.  [#FMPNote]_
-Firmware is also required to provide an EFI System Resource Table
(ESRT). [UEFI]_ § 23.4
-Every firmware image that can be updated in-band must be described in
the ESRT.
+"Delivering Capsules Containing Updates to Firmware Management
Protocol."

  If firmware update is performed out-of-band (e.g., by an independent
Baseboard
  Management Controller (BMC), or firmware is provided by a hypervisor),
@@ -477,7 +475,6 @@ then the platform is not required to implement the
`UpdateCapsule()` runtime ser

  `UpdateCapsule()` is only required before `ExitBootServices()` is
called.

-
  .. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar
problem
 regarding secure storage.
 OP-TEE's chosen solution is to rely on an OS supplicant agent to
perform
@@ -488,11 +485,3 @@ then the platform is not required to implement
the `UpdateCapsule()` runtime ser
 during runtime services.


https://optee.readthedocs.io/en/latest/architecture/secure_storage.html
-
-.. [#FMPNote] The `UpdateCapsule()` runtime service is expected to be
suitable
-   for use by generic firmware update services like fwupd and Windows
Update.
-   Both fwupd and Windows Update read the ESRT table to determine
what firmware
-   can be updated, and use an EFI helper application to call
`UpdateCapsule()`
-   before `ExitBootServices()` is called.
-
-   https://fwupd.org/
--
2.20.1

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the contents to any other person, use it for any purpose, or store or
copy the information in any medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.

[EBBR PATCH] Relax Update requirements by dropping ESRT

[Grant Likely]

The ESRT support in U-Boot is immature and not ready for mainline.
Temporarily remove the ESRT requirement so that platforms can meaningfully
conform to EBBR. When ESRT functionality has matured this requirement will
can be brought back in.

Signed-off-by: Grant Likely 
---

Hi all,

As described above, I'm proposing ESRT gets dropped for v2.0.x series of
EBBR, with the plan to add it back in ebbr-next. Once there are U-Boot
releases that have a solid ESRT implementation that works for fwupd,
mender.io and possibly Windows Update then I would like to bring it back
in.  Here's the pull request for the change in github:

https://github.com/ARM-software/ebbr/pull/86

Thoughts?

g.

 source/chapter2-uefi.rst | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 092fd1d..4c4cacb 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -467,9 +467,7 @@ EBBR platforms are required to implement either an in-band 
or an out-of-band fir
 If firmware update is performed in-band (firmware on the application processor 
updates itself),
 then the firmware shall implement the `UpdateCapsule()` runtime service and 
accept updates in the
 "Firmware Management Protocol Data Capsule Structure" format as described in 
[UEFI]_ § 23.3,
-"Delivering Capsules Containing Updates to Firmware Management Protocol.  
[#FMPNote]_
-Firmware is also required to provide an EFI System Resource Table (ESRT). 
[UEFI]_ § 23.4
-Every firmware image that can be updated in-band must be described in the ESRT.
+"Delivering Capsules Containing Updates to Firmware Management Protocol."

 If firmware update is performed out-of-band (e.g., by an independent Baseboard
 Management Controller (BMC), or firmware is provided by a hypervisor),
@@ -477,7 +475,6 @@ then the platform is not required to implement the 
`UpdateCapsule()` runtime ser

 `UpdateCapsule()` is only required before `ExitBootServices()` is called.

-
 .. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem
regarding secure storage.
OP-TEE's chosen solution is to rely on an OS supplicant agent to perform
@@ -488,11 +485,3 @@ then the platform is not required to implement the 
`UpdateCapsule()` runtime ser
during runtime services.

https://optee.readthedocs.io/en/latest/architecture/secure_storage.html
-
-.. [#FMPNote] The `UpdateCapsule()` runtime service is expected to be suitable
-   for use by generic firmware update services like fwupd and Windows Update.
-   Both fwupd and Windows Update read the ESRT table to determine what firmware
-   can be updated, and use an EFI helper application to call `UpdateCapsule()`
-   before `ExitBootServices()` is called.
-
-   https://fwupd.org/
--
2.20.1

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

No EBBR Biweekly for 5th or 19th July

[Grant Likely]

I'm out on annual leave. There will be no EBBR biweekly meetings for July.

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH v4] Add RISC-V support content to the EBBR specification

[Grant Likely]

On 23/06/2021 07:34, Atish Patra wrote:

On Tue, Jun 22, 2021 at 7:54 AM Grant Likely  wrote:
Regarding "UEFI Boot at S mode" section [1], it just tries to
emphasize that UEFI boot at S-mode is the most common scenario for
current/near future platforms as
there are not many platforms with hypervisor extension available right now.
We can reword something like this as talking about the draft extension
is not necessary.

"Most systems are expected to boot UEFI at S mode in absence of
hypervisor extension."


Here's what I've merged after some editorial work. If this isn't right, 
follow up patches can fix it up.


https://github.com/ARM-software/ebbr/commit/a3e9b4bac76c054b505d3c2a42b7f10e8886e961

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

Re: [PATCH v4] Add RISC-V support content to the EBBR specification

[Grant Likely]

On 22/06/2021 15:05, Matthias Brugger wrote:



On 22/06/2021 15:18, Grant Likely wrote:

On 22/06/2021 11:50, Daniel Thompson wrote:

On Tue, Jun 22, 2021 at 12:35:17PM +0200, Matthias Brugger wrote:



On 21/06/2021 22:55, Grant Likely wrote:



On 21/06/2021 21:53, Grant Likely wrote:
[...]


I've pushed my edited copy out to a temporary branch. You can see it here:

https://github.com/ARM-software/ebbr/commit/9d4632a3911fd460cb1adf6a5b1a2b13650b5ab4




Correction, here:

https://github.com/ARM-software/ebbr/commit/714f6fd6747f61c0557fdce7d5bed7b59b603e44




Beware that this still has the wording of:
"Any platform with hypervisor extension enabled most likely to boot UEFI at
HS mode"

I agree that we sould not speculate in EBBR. If we don't know for 100% sure, we
should wait until the spec is released. Otherwise confusion will be big.


I think this could be poor drafting of EBBR language rather than an
unclear H extension spec.

For Arm platforms we recommend platforms with virtualization support
boot the kernel in EL1 but we do not require it since some systems
reserved EL1 for additional system firmware (and in one, somewhat
notorious case, to deploy Si bug workarounds). I think we would use
something similar for RISC-V


I assume you mean EL2 in the above paragraph, not EL1.

In the Arm case the language does specify EL2 or EL1 based on whether
virtualization is supported or not:

```
On AArch64 UEFI shall execute as 64-bit code at either EL1 or EL2,
depending on whether or not virtualization is available at OS load time.
```

The following paragraphs make it clear that if virtualization is available, then
UEFI shall run at EL2. "Most likely" isnt very good spec langauge and should be
removed from the AArch64 text.


I agree entirely EBBR has no business describing what mode if thinks the
processor will be in when UEFI starts but that is because it is not relevant
rather than because it is speculation. We are in the business of
recommending (or requiring) a particular processor mode when we hand
over from firmware to the OS. That's what the language here should do.


Okay, I think this section needs rewriting. Since RISC-V modes don't match
AArch64 exception levels, I wouldn't try to duplicate the section structure
here. It also isn't necessary to describe the RISC-V priviledge mode. Assume the
reader knows what the modes are. Something along the lines of:

```
RISC-V Privilege Levels
---

UEFI images may be executed in M mode, S mode, HS mode, or VS mode depending on
what architecture features are available to the application. Which mode shall be
used is detailed in the following table:

.. list-table:: RISC-V execution mode
    :header-rows: 1

    * - Mode
  - Description
    * - M mode
  - blah blah blah
    * - S mode
  - blah blah blah
    * - HS mode
  - blah blah blah
    * - VS mode
  - blah blah blah

```

Personally, I'm fine if the text references hypervisor mode as a requirement in
some scenarios, but I don't want any language about the draft state of that
specification. However, if there are still objections from OS distribution


Wait, but that is part of your last commit [1]. Did I missed something. I
thought we are discussing about this commit.


I pushed that out to a temporary branch. It hasn't been committed to 
mainline.





people (e.g., Matthias) then I'll drop the hypervisor bits until it comes out of
draft.



I think Atish made it clear that the spec won't change the modes, so I think we
can add that. I just would like to reword the sentence. What about:

Any platform with hypervisor extension enabled and that boots UEFI at HS mode,
allows for the installation of a hypervisor or a virtualization aware Operating
System.


I'm happy with that.

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

Re: [PATCH v4] Add RISC-V support content to the EBBR specification

[Grant Likely]

On 21/06/2021 21:53, Grant Likely wrote:
[...]


I've pushed my edited copy out to a temporary branch. You can see it here:

https://github.com/ARM-software/ebbr/commit/9d4632a3911fd460cb1adf6a5b1a2b13650b5ab4 


Correction, here:

https://github.com/ARM-software/ebbr/commit/714f6fd6747f61c0557fdce7d5bed7b59b603e44

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

Re: [PATCH v4] Add RISC-V support content to the EBBR specification

[Grant Likely]

On 21/06/2021 18:35, Atish Patra wrote:

On Mon, Jun 21, 2021 at 10:19 AM Grant Likely  wrote:




On 10/05/2021 18:37, Atish Patra wrote:

[...]

+
+UEFI Boot at S mode
+^^
+
+Most systems are expected to boot UEFI at S mode as the hypervisor extension 
[RVHYPSPEC]_ is
+still in draft state.


I just noticed this. If the hypervisor spec is still in draft, then why
is it being referenced by EBBR? Shouldn't that spec be made final first,
or at least commonly deployed?


+
+UEFI Boot at HS mode
+
+
+Any platform with hypervisor extension enabled most likely to boot UEFI at HS 
mode,
+to allow for the installation of a hypervisor or a virtualization aware 
Operating System.


This sounds like it should be more tightly written. How about:

On platforms with the hypervisor extension enabled UEFI code should be
executed in HS mode to allow installation of a hypervisor or a
virtualization aware operating system.

Still with the hypervisor extension in draft I wonder if it would be
better to leave these bits out for now.


diff --git a/source/index.rst b/source/index.rst
index 48318757f717..acd214d25323 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -1,5 +1,6 @@
   .. EBBR Source Document
  Copyright Arm Limited, 2017-2019
+   Copyright Western Digital Corporation or its affiliates, 2021



I don't think this is valid for a copyright message. In fact, the Arm
line above it is also wrong. It should be specific to the copyright
owner without the "or its affiliates". Is it okay by you if Idrop that
last bit.



That's the copyright line we got from Western Digital lawyer because
Western Digital has many subsidiaries (as a result of acquisitions)
In fact, our group was part of HGST until recently. We have the same
copyright in other open source projects (Kernel, OpenSBI, U-Boot)


Good enough for me. I'm leaving it as is.

I've pushed my edited copy out to a temporary branch. You can see it here:

https://github.com/ARM-software/ebbr/commit/9d4632a3911fd460cb1adf6a5b1a2b13650b5ab4

g.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH v4] Add RISC-V support content to the EBBR specification

[Grant Likely]

On 10/05/2021 18:37, Atish Patra wrote:

This patch adds all the required content to make RISC-V EBBR compatible.
The additional content is not a lot given that we just need to update the
architecture specific sections for RISC-V. Rest of the document is ISA agnostic
anyways.

Signed-off-by: Atish Patra 


Hi Atish,

I'm picking up this patch. There are some editorial changes that I'm
making (line breaks, glossary organization, etc), but I don't need you
to respin the patch. However, I have some comments questions before I
push the result out.


--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -158,6 +158,8 @@ easily meet the stricter BBR requirements.
  By definition, all BBR compliant systems are also EBBR compliant, but the
  converse is not true.

+This specification is also referenced by RISC-V platform specification 
[RVPLTSPEC]_.
+


s/also //

I've dropped text that references RISC-V in comparison to ARM. The
RISC-V wording is able to stand on it's own without reference. :-)


  Conventions Used in this Document
  =

@@ -181,14 +183,12 @@ This document uses the following terms and abbreviations.

  .. glossary::


[...]

+   SiP
+  Silicon Partner. In this document, the silicon manufacturer.


I've rearranged the glossary to put the generic terms at the top, and
the architecture specifics below that. Also minor editorial so that all
the terms are handled as glossary. (.. glossary:: is needed in each section)


diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 53c962ab5c25..18a9b5404cba 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -209,7 +209,7 @@ Resident UEFI firmware might target a specific privilege 
level.
  In contrast, UEFI Loaded Images, such as third-party drivers and boot
  applications, must not contain any built-in assumptions that they are to be
  loaded at a given privilege level during boot time since they can, for 
example,
-legitimately be loaded into either EL1 or EL2 on AArch64.
+legitimately be loaded into either EL1 or EL2 on AArch64 and HS/VS/S mode on 
RISC-V.

  AArch64 Exception Levels
  
@@ -232,6 +232,45 @@ UEFI-compliant Operating System.
  In this instance, the UEFI boot-time environment can be provided, as a
  virtualized service, by the hypervisor and not as part of the host firmware.

+RISC-V Privilege Levels
+---
+
+Unlike AARCH64, RISC-V doesn't define dedicated privilege levels for hypervisor


s/Unlike AARCH64, //


+enabled platforms. The supervisor mode becomes HS mode where a hypervisor or a 
hosting-capable
+operating system runs while the guest OS runs in virtual S mode (VS mode) as 
shown in below figures.
+Resident UEFI firmware can be executed in M mode or S/HS mode during POST. 
However,
+the UEFI images must be loaded in HS or VS mode if virtualization is available 
at OS load time.


editorial: I've reflowed most paragraphs to use semantic breaks (e.g.,
one sentence per line). It reduces the reflow changebars on future edits
to the text.


+
+.. image:: images/riscv-sbi-intro1.png
+  :align: center
+
+Figure1. RISC-V System without H-extension
+
+.. image:: images/riscv-sbi-intro2.png
+  :align: center
+
+Figure2. RISC-V System with H-extension


I've dropped the images; I don't think they're necessary for spec
language, but this can be debated.

In the mean time it doesn't have to hold up the rest of the changes.


+
+UEFI Boot at S mode
+^^
+
+Most systems are expected to boot UEFI at S mode as the hypervisor extension 
[RVHYPSPEC]_ is
+still in draft state.
+
+UEFI Boot at HS mode
+
+
+Any platform with hypervisor extension enabled most likely to boot UEFI at HS 
mode,
+to allow for the installation of a hypervisor or a virtualization aware 
Operating System.
+
+UEFI Boot at VS mode
+^^
+
+Booting of UEFI at VS mode is employed within a hypervisor hosted Guest 
Operating System environment,
+to allow the subsequent booting of a UEFI-compliant Operating System.
+In this instance, the UEFI boot-time environment can be provided, as a
+virtualized service, by the hypervisor and not as part of the host firmware.
+
  UEFI Boot Services
  ==

diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst
index 9c51bca24f33..d6bfbd322837 100644
--- a/source/chapter3-secureworld.rst
+++ b/source/chapter3-secureworld.rst
@@ -27,3 +27,15 @@ Platforms without EL3 must implement one of:
  However, the spin table protocol is strongly discouraged.
  Future versions of this specification will only allow PSCI, and PSCI should
  be implemented in all new designs.
+
+RISC-V Multiprocessor Startup Protocol
+==
+The resident firmware in M mode or hypervisor running in HS mode must implement
+and conform to at least SBI [RVSBISPEC]_ v0.2 with HART
+State Management(HSM) extension for both RV32 and 

EBBR Biweekly for 2021-Jun-21 -- cancelled

[Grant Likely]

Hi all,

I don't have an agenda for today and I didn't send out a reminder on
Friday, so I'm cancelling for today.

There are outstanding patches adding RISC-V support that still need to
be reviewed and/or merged. Hopefully I'll be able to process those this
week. I'll post any status updates to this mailing list

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

EBBR biweekly CANCELLED for 7th Jun

[Grant Likely]

I have a conflict with an internal meeting today and need to cancel.
Next EBBR biweekly with be 21st Jun.

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: RPI4 booting with SystemReady-IR flow

[Grant Likely]

On 24/05/2021 18:42, François Ozog wrote:

Hi,

I verified that RPI4 can boot Ubuntu and LEDGE RP with UEFI + U-Boot.
Two flows have been checked: direct (kernel+initrd in BootXXX variable
leveraging LOAD_FILE2 mechanism) and through grub.

Note: Grub (current head) behaves properly but does not display anything on
serial console because lack of U-Boot (2021.07-rc2) support for:

   GRUB_EFI_SERIAL_IO_GUID \

   { 0xbb25cf6f, 0xf1d4, 0x11d2, \

 { 0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0xfd } \

   }


/* details: grub-core/term/efi/serial.c, grub_efiserial_init() ->
grub_efi_locate_handle
(GRUB_EFI_BY_PROTOCOL, _io_guid,...) returns NULL */


This doesn't look right to me. U-Boot provides the SimpleTextProtocol
which Grub can use to display the menu over either UART or framebuffer.
The SERIAL_IO protocol is not required. If you aren't getting output on
the serial console then it is more likely a U-Boot configuration problem
rather than missing functionality.

g.




So I think we need to add this protocol and some others to make the UEFI
text environment fully supported for grub.


Cheers


FF


PS: It would be nice to have an efidebug command to actually trace all boot
services calls to "get_protocol" and either trace all requests or just
failed requests.



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Fwd: [SystemArchAC] SystemReady IR ACS Beta available for Certification

[Grant Likely]

Hi all,

For everyone interested in SystemReady IR certification, Arm has now 
made public the Architecture Compliance Suite (ACS) for SystemReady IR. 
Binaries and source can be found on Github at the link below:


g.

https://github.com/ARM-software/arm-systemready/tree/main/IR


 Forwarded Message 
Subject:[SystemArchAC] SystemReady IR ACS Beta available for 
Certification
Date:   Tue, 25 May 2021 06:16:47 +
From:   SystemArchAC 
Reply-To:   dong@arm.com
To: systemarc...@arm.causewaynow.com 



Hi All,

We have populated the new �SystemReady ACS github repo at 
https://github.com/ARM-software/arm-systemready 
.


Specifically, the beta release of the SystemReady IR ACS is now used for 
the SystemReady IR v1.0 certification. See 
https://github.com/ARM-software/arm-systemready/tree/main/IR 
.


We are continuing the restructuring of the ACS. In the meantime, the 
SystemReady SR v2.0 and ES v1.0 certifications are still using 
Enterprise ACS 3.0 at https://github.com/ARM-software/arm-enterprise-acs 
.


cidimage001.png@01D559D5.83B2FFF0



Dong Wei�| Standards Architect and Fellow

dong@arm.com 

MS Teams: +1 (669)284-0488

Cell: +1 (916) 622-9101

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

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

EBBR Biweekly for 24 May 2021

[Grant Likely]

Hi everyone,

Here is the agenda for Monday's EBBR meeting. This week Ilias will
present his proposed solution to to solve StMM RPMB writes at runtime so
that SetVariable can be generically enabled.

Ilias, do you have any details that you can provide ahead of the meeting?

Dial in details are below

g.

Agenda:
- StMM RPMB writes at runtime
- ESRT requirement review
- other business

---

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Topic: EBBR Biweekly
Time: 10 May 2021, 16:00-17:00 GMT
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/abf0Umg7EM

Join by SIP
92081365...@zoomcrc.com

Join by H.323
162.255.37.11 (US West)
162.255.36.11 (US East)
115.114.131.7 (India Mumbai)
115.114.115.7 (India Hyderabad)
213.19.144.110 (Amsterdam Netherlands)
213.244.140.110 (Germany)
103.122.166.55 (Australia Sydney)
103.122.167.55 (Australia Melbourne)
209.9.211.110 (Hong Kong SAR)
149.137.40.110 (Singapore)
64.211.144.160 (Brazil)
69.174.57.160 (Canada Toronto)
65.39.152.160 (Canada Vancouver)
207.226.132.110 (Japan Tokyo)
149.137.24.110 (Japan Osaka)
Meeting ID: 920 8136 5511
Passcode: 490324




IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: EBBR Testing topic for today?

[Grant Likely]

On 21/05/2021 03:28, AKASHI Takahiro wrote:

On Fri, May 21, 2021 at 09:00:11AM +0900, Masami Hiramatsu wrote:

Hi,

2021年5月20日(木) 23:55 Grant Likely :


Thanks Masami,

Comments below...

On 20/05/2021 11:09, Masami Hiramatsu wrote:

Hi Grant,

I have a comment on the U-Boot configuration:
https://github.com/ARM-software/ebbr/wiki/U-Boot-Configuration-Guide


Another comment:
Please don't use "efidebug capsule update" command.
The only way that the current implementation of capsule update
with a capsule file supports (or CONFIG_EFI_CAPSULE_ON_DISK)
is "to reboot the system".

-Takahiro Akashi


On that note, have you done any testing with the Tianocoree 
CapsuleApp.efi? We've been experimenting with it, but haven't got it 
successfully working yet.


g.

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

Re: DeviceTree Evolution call for Monday May 17

[Grant Likely]

Apologies, I have a conflict with an internal meeting and will not be 
able to attend today. I'll catch up on the notes after the fact and I'll 
look through the elinux page.


g.

On 17/05/2021 03:55, Bill Mills wrote:

All,

Frank Rowand has put together a page:
https://elinux.org/New_FDT_format

On the call tomorrow we will begin discussion on this topic.

I suspect the above will take the full hour.  However...

Heinrich has sent out a proposal to embedded the signature data directly 
into the main DT node list.  This is an alternative to adding a new 
section for meta data as was discussed a couple of months ago.


Discussion of the alternatives for signatures is on the Todo list.

Zoom meeting:
Time: 3PM UTC / 4PM UK / 11 AM US East
Meeting ID: 961 7042 8801
Passcode: 8250

Thanks,
Bill



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

Re: EBBR Testing topic for today?

[Grant Likely]

Hi Masami,

Here are the instructions that I've been working on:

https://github.com/ARM-software/ebbr/wiki/EBBR-Testing-Guide
https://github.com/ARM-software/ebbr/wiki/U-Boot-Configuration-Guide

I hope that helps

g.

On 12/05/2021 02:02, Masami Hiramatsu wrote:

Hello Grant and Vincent,

I'm interested in passing SCT on my board with the latest U-Boot.
Would you know which CONFIG options are required for the SCT?
I guess some CONFIG_EFI* options are related, but some of them may not
be needed.
Is there any good documentation about configuring U-Boot?

Thank you,

2021年5月10日(月) 22:36 Grant Likely :


For the EBBR meeting today:

Attached is the test result report from running a recent version of
U-Boot on an iMX8 platform and parsed with the SCT_Parser tool.

g.


 Forwarded Message 
Subject:Re: EBBR Testing topic for today?
Date:   Mon, 10 May 2021 14:22:56 +0100
From:   Vincent Stehle 
To: Grant Likely 



Hi Grant,

Here are some more SCT results: a run from this morning on Compulab,
with latest firmware from Paul (+ 3 patches) and latest sct parser config.

INFO main: 0 dropped(s), 0 failure(s), 66 ignored(s), 10753 pass(s), 60
waived(s), 0 warning(s)

(The attached summary excludes the pass.)

Best regards,
Vincent.




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






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

Fwd: EBBR Testing topic for today?

[Grant Likely]

For the EBBR meeting today:

Attached is the test result report from running a recent version of 
U-Boot on an iMX8 platform and parsed with the SCT_Parser tool.


g.


 Forwarded Message 
Subject:Re: EBBR Testing topic for today?
Date:   Mon, 10 May 2021 14:22:56 +0100
From:   Vincent Stehle 
To: Grant Likely 



Hi Grant,

Here are some more SCT results: a run from this morning on Compulab, 
with latest firmware from Paul (+ 3 patches) and latest sct parser config.


INFO main: 0 dropped(s), 0 failure(s), 66 ignored(s), 10753 pass(s), 60 
waived(s), 0 warning(s)


(The attached summary excludes the pass.)

Best regards,
Vincent.




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

EBBR biweekly for 10 May 2021

[Grant Likely]

Hi everyone,

Here is the agenda for today's EBBR meeting. I've tentatively got on the
schedule a discussion of UEFI compliance testing status, but I hadn't
confirmed the topic with Vincent and Heinrich ahead of time, so we might
not be ready to discuss that and it will be a short meeting today. The
other topics I have are an update from Ilias on LoadFile and feedback on
Jose's A/B update protocol presentation from last week.

Dial in details are below

g.

Agenda:
- News and updates
- Feedback on firmware update protocol
- UEFI SCT Failure scrub

---

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Topic: EBBR Biweekly
Time: 10 May 2021, 16:00-17:00 GMT
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/abf0Umg7EM

Join by SIP
92081365...@zoomcrc.com

Join by H.323
162.255.37.11 (US West)
162.255.36.11 (US East)
115.114.131.7 (India Mumbai)
115.114.115.7 (India Hyderabad)
213.19.144.110 (Amsterdam Netherlands)
213.244.140.110 (Germany)
103.122.166.55 (Australia Sydney)
103.122.167.55 (Australia Melbourne)
209.9.211.110 (Hong Kong SAR)
149.137.40.110 (Singapore)
64.211.144.160 (Brazil)
69.174.57.160 (Canada Toronto)
65.39.152.160 (Canada Vancouver)
207.226.132.110 (Japan Tokyo)
149.137.24.110 (Japan Osaka)
Meeting ID: 920 8136 5511
Passcode: 490324




IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

EBBR v2.0.0 released

[Grant Likely]

Hi all,

I've just tagged v2.0.0 of EBBR. Please go have a read and please report 
any issues either here or on github:


https://github.com/ARM-software/ebbr/releases/tag/v2.0.0
https://github.com/ARM-software/ebbr/issues

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

Reminder: EBBR Biweekly for 26 April 2021

[Grant Likely]

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

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

Re: FW update on A-class Arm devices

[Grant Likely]

On 23/04/2021 13:41, Heinrich Schuchardt wrote:

On 23.04.21 13:51, Jose Marinho wrote:

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 
<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 (26^th April).

Regards,

Jose


Thank you for sharing this document.

Looking at the license this is a generic API definition that is not
bound to TF-A but might also be implemented on non-TF-A and non-ARM
platforms. - Do I get this right?

 From the view of non-secure firmware like U-Boot or EDK II having a
cross-platform specification is preferable.


Correct. The Arm non-confidential document is not restricted to
Arm-based designs.

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

EBBR Biweekly cancelled for today

[Grant Likely]

I'm cancelling today's EBBR biweekly as I don't have an agenda for
today. From discussion at the last EBBR meeting, with EBBR v2 about to
be released and not a lot of new content to discuss, future EBBR
meetings will be more of a tech forum format.

Please email me if there is a tech topic you want to discuss in the
biweekly EBBR forum and I'll add it to the schedule which will start in
2 weeks time.

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Grant Likely]

On 29/03/2021 08:42, Simon Glass wrote:
> Hi Raghu,
>
> On Sat, 27 Mar 2021 at 03:59,  wrote:
>
>> Julius, Simon,
>>
>>
>>
>> It appears there are opinions you carry around UUID being complicated,
>> bloated, code being an eyesore, parsing these lists early with
MMU/Caches
>> disabled, calculating checksums etc. While there is certainly a LOT of
>> truth to those statements, these concerns need to be put into
context and
>> may not necessarily apply to all platforms running TF-A. Standardization
>> and interoperability may be valued more on some platforms and some
of the
>> bloat and performance issues may be worth those tradeoffs. Some of these
>> concerns may not even apply on powerful CPU’s and SoC’s with lots of
>> memory. Also a quick grep for “uuid” in the TF-A repository shows that
>> there is significant use of UUID’s for FIP, some SMC’s, secure
partitions
>> etc so use of UUID is not something new to TF-A.
>>
>
> Fair enough. I hope, though, that if we can agree on a simple
> implementation like bloblist, then it becomes the standard and we can
move
> away from the problems you mention with UUIDs.

Ummm... I don't follow. How are UUIDs either complex or bloated? A UUIDs
is simply a 128 bit number that is matched using a fixed length compare.

What I like about the UUID scheme is it has collision avoidance built
in, and it is adopted across multiple projects.

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Change review for EBBR v2.0-pre1

[Grant Likely]

On 12/03/2021 17:16, Heinrich Schuchardt wrote:

On 12.03.21 17:53, Grant Likely wrote:

On 11/03/2021 20:06, Heinrich Schuchardt wrote:

[...]

+Firmware Update
+---
+
+Being able to update firmware to address security issues is a key
feature of secure platforms.
+EBBR platforms are required to implement either an in-band or an
out-of-band firmware update mechanism.
+
+If firmware update is performed in-band (firmware on the application
processor updates itself),
+then the firmware shall implement EFI_UPDATE_CAPSULE and accept updates


%s/EFI_UPDATE_CAPSULE/the UpdateCapsule() runtime service/


Is this the right way around to change this? Why doesn't it make sense
to reference EFI_UPDATE_CAPSULE? The question is I suppose part of a
larger question on how to refer to EFI elements throughout the document.


Throughout the UEFI spec services are referenced by there function name
and not by their type.

We should opt for the way of least surprise, i.e. use the function names.

Best regards >
Heinrich


Okay, makes sense. I hadn't gone back to see what was done in the UEFI 
spec before replying. :-) I'll make the change.


g.

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

Re: Change review for EBBR v2.0-pre1

[Grant Likely]

On 11/03/2021 20:06, Heinrich Schuchardt wrote:

On 3/11/21 5:53 PM, Grant Likely wrote:

[...]

+.. list-table:: Notable Deviations from UEFI § 2.6.2
+   :widths: 50 50
+   :header-rows: 1
+
+   * - Element
+ - Description of deviation
+   * - `LoadImage()`
+ - The LoadImage() boot service is not required to install an
+   EFI_HII_PACKAGE_LIST_PROTOCOL for an image containing a custom
PE/COFF
+   resource with the type 'HII'. - HII resource images are not
needed to run
+   the UEFI shell or the SCT.
+   * - `ConnectController()`
+ - The ConnectController()` boot service is not required to support
the
+   EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL,
+   EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL, and
+   EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL. - These override
protocols are
+   only useful if drivers are loaded as EFI binaries by the 
firmware.

+   * - `EFI_HII_CONFIG_ACCESS_PROTOCOL`
+ - UEFI requires this for console devices, but it is rarely
necessary in practice.
+   Therefore this protocol is not required.
+   * - `EFI_HII_CONFIG_ROUTING_PROTOCOL`
+ - UEFI requires this for console devices, but it is rarely
necessary in practice.
+   Therefore this protocol is not required.
+   * - Graphical console


Hello Grant,

thanks for sharing this pre-release.

Should we mention the protocols that might not be provided:

EFI_GRAPHICS_OUTPUT_PROTOCOL
EFI_EDID_DISCOVERED_PROTOCOL
EFI_EDID_ACTIVE_PROTOCOL


I don't think it is strictly necessary, but if you want to propose a 
patch to add those protocols to the text then I'd be happy to add it.



+.. list-table:: Required UEFI Variables
+   :widths: 25 75
+   :header-rows: 1
+
+   * - Variable Name
+ - Description
+   * - `Boot`
+ - A boot load option.  is a numerical hex value
+   * - `BootCurrent`
+ - The boot option that was selected for the current boot
+   * - `BootNext`
+ - The boot option that will be used for the next boot only
+   * - `BootOrder`
+ - An ordered list of boot options.
+   Firmware will attempt each Boot entry in this order


Firmware will try BootNext and each Boot in the order given by
BootOrder to find the first bootable image.


Fixed, will push out later.




+   * - `OsIndications`
+ - Method for OS to request features from firmware
+   * - `OsIndicationsSupported`
+ - Variable for firmware to indicate which features can be enabled

  Block device partitioning
  -
@@ -53,7 +224,7 @@ a hypervisor or a virtualization aware Operating 
System.

  UEFI Boot at EL1
  

-Booting of UEFI at EL1 is most likely within a hypervisor hosted Guest
+Booting of UEFI at EL1 is most likely employed within a hypervisor
hosted Guest
  Operating System environment, to allow the subsequent booting of a
  UEFI-compliant Operating System.
  In this instance, the UEFI boot-time environment can be provided, as a
@@ -77,7 +248,7 @@ The default RAM allocated attribute must be
EFI_MEMORY_WB.
  Configuration Tables
  

-A UEFI system that complies with this specification may provide the
additional
+A UEFI system that complies with this specification may provide 
additional

  tables via the EFI Configuration Table.

  Compliant systems are required to provide one, but not both, of the
following
@@ -151,26 +322,55 @@ EFI_UNSUPPORTED.
  are required to be implemented during boot services and runtime 
services.


  .. _uefi_runtime_service_requirements:
-.. table:: EFI_RUNTIME_SERVICES Implementation Requirements
-
-   == = 
-   EFI_RUNTIME_SERVICES function  Boot Services Runtime Services
-   == = 
-   EFI_GET_TIME   Optional  Optional
-   EFI_SET_TIME   Optional  Optional
-   EFI_GET_WAKEUP_TIME    Optional  Optional
-   EFI_SET_WAKEUP_TIME    Optional  Optional
-   EFI_SET_VIRTUAL_ADDRESS_MAP    N/A   Required
-   EFI_CONVERT_POINTER    N/A   Required
-   EFI_GET_VARIABLE   Required  Optional
-   EFI_GET_NEXT_VARIABLE_NAME Required  Optional
-   EFI_SET_VARIABLE   Required  Optional
-   EFI_GET_NEXT_HIGH_MONO_COUNT   N/A   Optional
-   EFI_RESET_SYSTEM   Required  Optional
-   EFI_UPDATE_CAPSULE Optional  Optional
-   EFI_QUERY_CAPSULE_CAPABILITIES Optional  Optional
-   EFI_QUERY_VARIABLE_INFO    Optional  Optional > -   
== = 

+.. list-table:: `EFI_RUNTIME_SERVICES` Implementation Requirements
+   :widths: 40 30 30
+   :header-rows: 1
+
+   * - `EFI_RUNTIME_SERVICES` function > + - Before 
ExitBootServices()

+ - After ExitBootServices()
+   * - `EFI_GET_TIME`


We should use the service names (not the type names) throughout this
document:

G

Change review for EBBR v2.0-pre1

[Grant Likely]

Hi all,

I'm about ready to tag the first pre-release of EBBR v2.0. Here is the 
full changelog as compared to v1.0.1. Once I tag this release I'll be 
casting the net wider for comments before the document gets released.
There are lots of little changes to the document, and a few notable big 
ones. Big things to look for are:


- Reduced required elements in UEFI requirements
- Firmware shared storage refinements
- Capsule Update is now required

Please let me know if you have any comments. Better yet, open an issue 
in github so that it doesn't get forgotten. We'll also be discussing the 
release at the EBBR biweekly on Monday 15th March.


https://github.com/ARM-software/ebbr/issues

Here's the full list of changes:

96dbb03 Reference BBR instead of SBBR (not yet merged)
2a6ca89 Fedora needs two more packages
2e3e873 CONTRIBUTING: let wording follow branching
cf29c4c README.rst: Python 2 is long time gone
396abac Fix build warnings:
e5d32ca trivial: remove duplicate SCSI pass through support
98e24fe Merge pull request #73 from glikely/for-next
eb34dbf Require EFI_UPDATE_CAPSULE
139e6c2 Refine RTC requirements
48e1e56 UEFI section 2.6 exceptions for boot services
72f3e2d Override UEFI section 2.6 requirements
58a2a27 Change required services table titles to be more accurate
d4ff44e Minor suggestions to hopefully improve the text
0555e38 Reformat revision history table to render better
5d836bc Refine firmware shared storage requirements.
a89cf43 Add reference to RFC 2119 in conventions
8db9eed Fix ResetSystem() text to describe failure condition
eda36e4 Merge pull request #48 from jbech-linaro/optee-url
c4ef5c7 Update link to OP-TEE secure storage

And here is the full diff:

 CONTRIBUTING.rst   |   2 +-
 README.rst |  15 ++--
 source/chapter1-about.rst  |  30 ---
 source/chapter2-uefi.rst   | 292 
---

 source/chapter4-firmware-media.rst |  72 
 source/conf.py |   2 +-
 source/index.rst   |  57 ++---
 source/references.rst  |  12 ++-
 8 files changed, 378 insertions(+), 104 deletions(-)

diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
index 7021f0f..be979e0 100644
--- a/CONTRIBUTING.rst
+++ b/CONTRIBUTING.rst
@@ -1,7 +1,7 @@
 Contributing
 

-Master copy of this project is hosted on GitHub:
+Main copy of this project is hosted on GitHub:
 https://github.com/ARM-software/ebbr

 Anyone may contribute to the EBBR project.
diff --git a/README.rst b/README.rst
index 7480dcb..acf6742 100644
--- a/README.rst
+++ b/README.rst
@@ -41,31 +41,28 @@ On Debian and Ubuntu
 
 ::

-  # apt-get install python-sphinx texlive texlive-latex-extra 
libalgorithm-diff-perl \
+  # apt-get install python3-sphinx texlive texlive-latex-extra 
libalgorithm-diff-perl \
 texlive-humanities texlive-generic-recommended 
texlive-generic-extra \

 latexmk

 If the version of python-sphinx installed is too old, then an additional
 new version can be installed with the Python package installer::

-  $ apt-get install python-pip
-  $ pip install --user --upgrade Sphinx
+  $ apt-get install python3-pip
+  $ pip3 install --user --upgrade Sphinx
   $ export SPHINXBUILD=~/.local/bin/sphinx-build

-Export SPHINXBUILD (see above) if Sphinx was installed with pip --user, 
then follow Make commands below
+Export SPHINXBUILD (see above) if Sphinx was installed with pip3 
--user, then follow Make commands below.


 On Fedora
 ^

 ::

-  # dnf install python2-sphinx texlive texlive-capt-of 
texlive-draftwatermark \
+  # dnf install python3-sphinx texlive texlive-capt-of 
texlive-draftwatermark \

 texlive-fncychap texlive-framed texlive-needspace \
 texlive-tabulary texlive-titlesec texlive-upquote \
-texlive-wrapfig
-
-It is also possible to use python3-sphinx; this requires
-SPHINXBUILD=sphinx-build-3 to be passed on the Make command line.
+texlive-wrapfig texinfo latexmk

 On Mac OS X
 ^^^
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index 3744d8a..6f69f53 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -50,8 +50,8 @@ Vendors have heavy investments in both projects and 
are not interested in large

 scale changes to their firmware architecture.
 The challenge for EBBR is to define a set of boot standards that 
reduce the
 amount of custom engineering required, make it possible for OS 
distributions to
-support embedded platforms, while still preserving the firmware stack 
product

-vendors are comfortable with.
+support embedded platforms, while still preserving the firmware stack that
+product vendors are comfortable with.
 Or in simpler terms, EBBR is designed to solve the embedded boot mess by
 adding a defined standard (UEFI) to the existing firmware 

[EBBR PATCH] Reference BBR instead of SBBR

[Grant Likely]

SBBR has been superseded by Arm BBR. Update the about section to
reference BBR instead. However, none of the specification language
changes because EBBR has a relaxed set of UEFI requirements compared to
BBR.

Fixes: #62

Signed-off-by: Grant Likely 
---
 source/chapter1-about.rst | 19 ---
 source/references.rst |  6 +++---
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index 68a1abc..6f69f53 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -146,17 +146,14 @@ including services that are required for virtualization.
 It does not define a standardized abstract virtual machine view for a Guest
 Operating System.
 
-This specification is similar to the Arm Server Base Boot Requirements
-specification [SBBR]_ in that it defines the firmware interface presented to an
-operating system.
-SBBR is targeted at the server ecosystem and places strict requirements on the
-platform to ensure cross vendor interoperability.
-EBBR on the other hand allows more flexibility to support embedded designs
-which do not fit within the SBBR model.
-For example, a platform that isn't SBBR compliant because the SoC is only
-supported using Devicetree could be EBBR compliant, but not SBBR compliant.
-
-By definition, all SBBR compliant systems are also EBBR compliant, but the
+This specification is referenced by the Arm Base Boot Requirements
+Specification [ArmBBR]_ § 4.3.
+The UEFI requirements found in this document are similar but not identical to
+the requirements found in BBR.
+EBBR provides greater flexibility for support embedded designs which cannot
+easily meet the stricter BBR requirements.
+
+By definition, all BBR compliant systems are also EBBR compliant, but the
 converse is not true.
 
 Conventions Used in this Document
diff --git a/source/references.rst b/source/references.rst
index d91dc08..fb7dc81 100644
--- a/source/references.rst
+++ b/source/references.rst
@@ -22,9 +22,9 @@

<https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Interface.pdf>`_
30 January 2015, `Arm Limited <http://arm.com>`_
 
-.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0)
-   
<https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirements.pdf>`_
-   8 March 2016, `Arm Limited <http://arm.com>`_
+.. [ArmBBR] `Arm Base Boot Requirements specification Issue F (v1.0)
+   <https://developer.arm.com/documentation/den0044/f>`_
+   6 Oct 2020, `Arm Limited <http://arm.com>`_
 
 .. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 Errata A

<https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_,
-- 
2.20.1

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

SystemReady IR at Embedded World (Was: *cancelled* EBBR Biweekly for 1 March 2021)

[Grant Likely]

If you're interested in joining the Embedded World roundtable on 
SystemReady IR, it is scheduled for 1st March at 15:50 - 16:50pm (GMT) / 
16:50 - 17:50pm (CET). You'll need to register ahead of time to get 
access to the link. Space is limited, so please register early.


Here's the link:

https://www.talque.com/app#/app/ngx/org/QFL9g0IZL8T3UUZBmZAK/session/3zGH0J51E8UB7UfAtAR5

Hope to see you on Monday.
g.

On 18/02/2021 19:29, Grant Likely wrote:

Hi all,

I'll be doing a presentation and round table about SystemReady IR at 
Embedded World on 1 March, but unfortunately it overlaps entirely our 
EBBR biweekly so I'm going to cancel that day.


If you're interested in attending the round table, please email me 
privately. The session apparently limited to a small number of people 
(which seems odd for a virtual conference), so I'm sending out invites. 
The session is scheduled for 15:50-16:50 GMT on 1 March 2021.


Cheers,
g.

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

Re: EFI_LOAD_FILE2 for initrd standardization

[Grant Likely]

On 18/02/2021 11:15, Heinrich Schuchardt wrote:

On 18.02.21 10:04, Ilias Apalodimas wrote:

Hi,

An arch agnostic way was recently added on the kernel, as an alternative method
to load an initrd [1].  The kernel call to the firmware ends up calling the
protocol with a Device Path End Structure, so the firmware must know which
initrd to load on the buffer the kernel provides.

The protocol is currently implemented by U-boot and EDK2, which both
define a way of specifying the initrd to load.  We could use this protocol,
in order to provide vertical distros a way of loading (kernel, initrd) pairs
without GRUB.  In that case we need a common way for firmware implementations
to define and manage the initrd.  User space applications that control the boot
flow (e.g efibootmgr), should also be able to change the variable accordingly.

Looking at the EFI spec and specifically § 3.1.3 Load Options, we can use the
FilePathList[] of the EFI_LOAD_OPTION, which is described as:

"A packed array of UEFI device paths. The first element of the array is a
device path that describes the device and location of the Image for this
load option. The FilePathList[0] is specific to the device type. Other device
paths may optionally exist in the FilePathList, but their usage is OSV specific.
Each element in the array is variable length, and ends at the device path end
structure. Because the size of Description is arbitrary, this data structure
is not guaranteed to be aligned on a natural boundary. This data structure may
have to be copied to an aligned natural boundary before it is used."

So FilePatrhList[1-n] are available for OS usage.  There are 3 ways we could
implement that. All 3 ways would allow us to specify multiple initrds (and we
could extend the same logic to DTBs, but that's a different discussion).
They all re-use the same idea,  prepend a VenMedia DP, which has a GUID. We can
then use that GUID to identify the filetype and behavior of the device paths.

1. Prepend a VenMedia Device Path in every initrd Device Path. In that case
FilePathList[] would look like this:

Loaded Image device path - end node - VenMedia - Initrd DP - end node
- VenMedia - Initrd DP - end node - repeat

2. Prepend a VenMedia Device Path once. In that case FilePathList[] would look
like this:

Loaded Image device path - end node - VenMedia - Initrd DP - end
instance - (repeat) - Initrd DP - end node - other DPs

In this case we could use the VenMedia Vendor Defined Data to indicate
the number
of device paths that follow, although it's redundant, since each instance would
terminate on the Device Path End Structure.

3. Use Vendor Defined Data of the VenMedia device path and copy the initrd
device path(s) in there. In that case the Vendor Defined Data will it self
be in a device path format with all the initrds we want.

Loaded Image device path - end node - VenMedia - end node - other DPs


When passing the device path of the boot option to the EDK2
implementation of
EFI_DEVICE_PATH_TO_TEXT_PROTOCOL.ConvertDevicePathToText(), it will
print out all array elements as comma separated list like

HD(1,GPT,..,0x2000,0x20)/File(\EFI\debian\shimaa64.efi),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd1),/VenMedia(0001----)/HD(2,GPT,..,0x2000,0x20)/File(\initrd2)
 >
The device path end nodes of sub-type 0x01 are rendered as commas.

With 1 and 2 this would show a readable output like above.
With 3 you will just see a hex-string.

This excludes 3 for me.

If 2 does not add the number of initrds, it cannot be determined if a
following array element starting with a VenMedia() node is an initrd or
has a completely different meaning.

With 1 you can individually determine for each element its meaning by
looking at the first node.


Attempting to paraphrase; does this mean the VenMedia component would be
used to identify the file type? i.e., use one GUID for initrd, and
another for DTB? Or is that worked out another way?

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

*cancelled* EBBR Biweekly for 1 March 2021

[Grant Likely]

Hi all,

I'll be doing a presentation and round table about SystemReady IR at
Embedded World on 1 March, but unfortunately it overlaps entirely our
EBBR biweekly so I'm going to cancel that day.

If you're interested in attending the round table, please email me
privately. The session apparently limited to a small number of people
(which seems odd for a virtual conference), so I'm sending out invites.
The session is scheduled for 15:50-16:50 GMT on 1 March 2021.

Cheers,
g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [EBBR PATCH 3/3] Require EFI_UPDATE_CAPSULE

[Grant Likely]

On 12/02/2021 21:50, Heinrich Schuchardt wrote:

On 2/12/21 7:59 PM, Grant Likely wrote:

EFI_UPDATE_CAPSULE is the industry standard method for applying firmware
updates. Make it a requirement in EBBR so that fwupd, Windows Update,
and any other generic firmware update service can support EBBR platforms.

This is made required because the ability to update firmware is a
critical part of building secure platforms.

Fixes: #69
Signed-off-by: Grant Likely 
---
  source/chapter2-uefi.rst | 29 -
  1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 3d48c99..4e8a24d 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -352,7 +352,7 @@ are required to be implemented during boot 
services and runtime services.

   - Required
   - Optional
 * - `EFI_UPDATE_CAPSULE`


As you have secure firmware in mind, shouldn't we explicitly require
signature verification of capsules?


Yes, but not yet. All the security requirements need to come in at the 
same time so that it makes sense, and it may be that we adopt BBSR as 
the security standard instead of adding it into EBBR.


g.



Best regards

Heinrich


- - Optional
+ - Required for in-band update
   - Optional
 * - `EFI_QUERY_CAPSULE_CAPABILITIES`
   - Optional
@@ -435,6 +435,25 @@ Even when SetVariable() is not supported during 
runtime services, firmware
  should cache variable names and values in EfiRuntimeServicesData 
memory so

  that GetVariable() and GetNextVeriableName() can behave as specified.

+Firmware Update
+---
+
+Being able to update firmware to address security issues is a key 
feature of secure platforms.
+EBBR platforms are required to implement either an in-band or an 
out-of-band firmware update mechanism.

+
+If firmware update is performed in-band (firmware on the application 
processor updates itself),
+then the firmware shall implement EFI_UPDATE_CAPSULE and accept 
updates in the
+"Firmware Management Protocol Data Capsule Structure" format as 
described in [UEFI]_ § 23.3,
+"Delivering Capsules Containing Updates to Firmware Management 
Protocol.  [#FMPNote]_
+Firmware is also required to provide an EFI System Resource Table 
(ESRT). [UEFI]_ § 23.4
+Every firmware image that is updated in-band must be described in the 
ESRT.

+
+If firmware update is performed out-of-band (e.g., by an independent 
Board Management Controller,
+or firmware is provided by a hypervisor), then the platform is not 
required to implement EFI_UPDATE_CAPSULE.

+
+EFI_UPDATE_CAPSULE is only required before ExitBootServices() is called.
+
+
  .. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar 
problem

 regarding secure storage.
 OP-TEE's chosen solution is to rely on an OS supplicant agent to 
perform
@@ -445,3 +464,11 @@ that GetVariable() and GetNextVeriableName() can 
behave as specified.

 during runtime services.

 
https://optee.readthedocs.io/en/latest/architecture/secure_storage.html

+
+.. [#FMPNote] The `EFI_UPDATE_CAPSULE` implementation is expected to 
be suitable
+   for use by generic firmware update services like fwupd and Windows 
Update.
+   Both fwupd and Windows Update read the ESRT table to determine 
what firmware
+   can be updated, and use an EFI helper application to call 
`EFI_UPDATE_CAPSULE`

+   before ExitBootServices() is called.
+
+   https://fwupd.org/




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

Re: [EBBR PATCH 1/3] Override UEFI section 2.6 requirements

[Grant Likely]

On 12/02/2021 20:55, Heinrich Schuchardt wrote:

On 2/12/21 7:59 PM, Grant Likely wrote:

EBBR only requires a subset of UEFI. Provide a replacement for the UEFI
section that lists base requirements.

Fixes: #60
Fixes: #61
Fixes: #64
---
  source/chapter2-uefi.rst | 164 ++-
  1 file changed, 162 insertions(+), 2 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 9906fd9..f47a98d 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -14,8 +14,168 @@ This document uses version 2.8 Errata A of the 
UEFI specification [UEFI]_.

  UEFI Compliance
  ===

-EBBR compliant platforms shall conform to the requirements in [UEFI]_ 
§ 2.6,

-except where explicit exemptions are provided by this document.
+EBBR compliant platform shall conform to a subset of the [UEFI]_ spec 
as listed

+in this section.
+Normally, UEFI compliance would require full compliance with all 
items listed

+in UEFI § 2.6.
+However, the EBBR target market has a reduced set of requirements,
+and so some UEFI features are omitted as unnecessary.
+
+Required Elements
+-
+
+This section replaces the list of required elements in [UEFI]_ § 2.6.1.
+All of the following UEFI elements are required for EBBR compliance.
+
+.. list-table:: UEFI Required Elements
+   :widths: 50 50
+   :header-rows: 1
+
+   * - Element
+ - Requirement
+   * - `EFI_SYSTEM_TABLE`
+ - The system table is required to provide required to access 
UEFI Boot Services,
+   UEFI Runtime Services, consoles, and other firmware, vendor 
and platform

+   information.
+   * - `EFI_BOOT_SERVICES`
+ - All functions defined as boot services must exist.
+   Methods for unsupported or unimplemented behaviour must return
+   an appropriate error code.


We had consensus in the discussion that the ConnectController() service
is not required to support:

* EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL.
* EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL
* EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL

Do you want to add that in "Notable Deviations"?


+   * - `EFI_RUNTIME_SERVICES`
+ - All functions defined as runtime services must exist.
+   Methods for unsupported or unimplemented behaviour must return
+   an appropriate error code.


If any runtime service is not implemented, the EFI_RT_PROPERTIES_TABLE
must be provided and indicate this.


Changed. Thanks.

g.



The rest looks good to me.

Best regards

Heinrich


+   * - `EFI_LOADED_IMAGE_PROTOCOL`
+ - Must be installed for each loaded image
+   * - `EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL`
+ - Must be installed for each loaded image
+   * - `EFI_DEVICE_PATH_PROTOCOL`
+ - An `EFI_DEVICE_PATH_PROTOCOL` must be installed onto all device
+   handles provided by the firmware.
+   * - `EFI_DEVICE_PATH_UTILITIES_PROTOCOL`
+ - Interface for creating and manipulating UEFI device paths
+
+.. list-table:: Notable omissions from UEFI § 2.6.1
+   :header-rows: 1
+
+   * - Element
+ - Note
+   * - `EFI_DECOMPRESS_PROTOCOL`
+ - Native EFI decompression is rarely used and therefore not 
required.

+
+Required Platform Specific Elements
+---
+
+This section replaces the list of required elements in [UEFI]_ § 2.6.2.
+All of the following UEFI elements are required for EBBR compliance.
+
+.. list-table:: UEFI Platform-Specific Required Elements
+   :widths: 50 50
+   :header-rows: 1
+
+   * - Element
+ - Description
+   * - Console devices
+ - The platform must have at least one console device
+   * - `EFI_SIMPLE_TEXT_INPUT_PROTOCOL`
+ - Needed for console input
+   * - `EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL`
+ - Needed for console input
+   * - `EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL`
+ - Needed for console output
+   * - `EFI_DEVICE_PATH_TO_TEXT_PROTOCOL`
+ - Needed for console output
+   * - `EFI_HII_STRING_PROTOCOL`
+ - Required by EFI shell and for compliance testing
+   * - `EFI_HII_DATABASE_PROTOCOL`
+ - Required by EFI shell and for compliance testing
+   * - `EFI_UNICODE_COLLATION2_PROTOCOL`
+ - Required by EFI shell and for compliance testing
+   * - `EFI_BLOCK_IO_PROTOCOL`
+ - Required for block device access
+   * - `EFI_SIMPLE_FILE_SYSTEM_PROTOCOL`
+ - Required if booting from block device is supported
+   * - `EFI_RNG_PROTOCOL`
+ - Required if the platform has a hardware entropy source
+   * - `EFI_SIMPLE_NETWORK_PROTOCOL`
+ - Required if the platform has a network device.
+   * - HTTP Boot (UEFI § 24.7)
+ - Required if the platform supports network booting
+
+The following table is a list of notable deviations from UEFI § 2.6.2.
+Many of these deviations are because the EBBR use cases do not require
+interface specific UEFI protocols, and so they have been made optional.
+
+.. list-table:: Notable Deviations from UEFI § 2.6.2
+   :widths: 50 50
+   :header-rows: 1
+
+   * - Element
+ - D

Re: [EBBR PATCH 2/3] Refine RTC requirements

[Grant Likely]

On 15/02/2021 16:38, Heinrich Schuchardt wrote:

On 12.02.21 19:59, Grant Likely wrote:

If the platform has an RTC, then EFI_GET_TIME and EFI_SET_TIME are required
before ExitBootServices(). Clarify this in the spec.

Also specify that EFI_{GET,SET}_WAKEUP_TIME are required before
ExitBootService() if the RTC can wakeup the platform.

Signed-off-by: Grant Likely 


This patch cannot be applied to upstream:

Applying: Refine RTC requirements
error: patch failed: source/chapter2-uefi.rst:319
error: source/chapter2-uefi.rst: patch does not apply


Sorry, there was a trivial formatting patch that I haven't pushed out 
yet. I'll push it out shortly.


g.



Please, rebase.

Best regards

Heinrich


---
  source/chapter2-uefi.rst | 15 +--
  1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index f47a98d..3d48c99 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -319,16 +319,16 @@ are required to be implemented during boot services and 
runtime services.
   - Before ExitBootServices()
   - After ExitBootServices()
 * - `EFI_GET_TIME`
- - Optional
+ - Required if RTC present
   - Optional
 * - `EFI_SET_TIME`
- - Optional
+ - Required if RTC present
   - Optional
 * - `EFI_GET_WAKEUP_TIME`
- - Optional
+ - Required if wakeup supported
   - Optional
 * - `EFI_SET_WAKEUP_TIME`
- - Optional
+ - Required if wakeup supported
   - Optional
 * - `EFI_SET_VIRTUAL_ADDRESS_MAP`
   - N/A
@@ -387,8 +387,11 @@ it may not be possible to access the RTC from runtime 
services.
  e.g., The RTC may be on a shared I2C bus which runtime services cannot access
  because it will conflict with the OS.

-If firmware does not support access to the RTC, then GetTime() and
-SetTime() shall return EFI_UNSUPPORTED,
+If an RTC is present, then GetTime() and SetTime() must be supported
+before ExitBootServices() is called.
+
+However, if firmware does not support access to the RTC after
+ExitBootServices(), then GetTime() and SetTime() shall return EFI_UNSUPPORTED
  and the OS must use a device driver to control the RTC.

  UEFI Reset and Shutdown




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

Re: EBBR Biweekly for Monday 01 Feb 2021

[Grant Likely]

Notes from last week

https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2021.02.01

On 29/01/2021 19:32, Grant Likely wrote:

Hi all,

Next EBBR biweekly is on Monday at 16:00 GMT. Dial-in details are below.

Below is the agenda I have so far. I've carried over the items that we
did not have time to discuss last week.

Agenda:
- Initrd passing
- Revised UEFI requirements (patch on mailing list)
- UpdateCapsule()
- other business

Please email if you want to add anything to the agenda

Cheers,
g.



Topic: EBBR Biweekly
Time: 1 Feb 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
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

EBBR Biweekly for Monday 15 Feb 2021

[Grant Likely]

Hi all,

Next EBBR biweekly is on Monday at 16:00 GMT. Dial-in details are below.
I understand that the 15th is a federal holiday for those of you in the
US, so no worries if you're unable to join. As always I'll post the
notes afterwards.

Below is the agenda I have so far. I've carried over the items that we
did not have time to discuss last week.

Agenda:
- Pending pull request
- Issue review
- other business

Please email if you want to add anything to the agenda

Cheers,
g.



Topic: EBBR Biweekly
Time: 1 Feb 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
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

[EBBR PATCH 1/3] Override UEFI section 2.6 requirements

[Grant Likely]

EBBR only requires a subset of UEFI. Provide a replacement for the UEFI
section that lists base requirements.

Fixes: #60
Fixes: #61
Fixes: #64
---
 source/chapter2-uefi.rst | 164 ++-
 1 file changed, 162 insertions(+), 2 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 9906fd9..f47a98d 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -14,8 +14,168 @@ This document uses version 2.8 Errata A of the UEFI 
specification [UEFI]_.
 UEFI Compliance
 ===
 
-EBBR compliant platforms shall conform to the requirements in [UEFI]_ § 2.6,
-except where explicit exemptions are provided by this document.
+EBBR compliant platform shall conform to a subset of the [UEFI]_ spec as listed
+in this section.
+Normally, UEFI compliance would require full compliance with all items listed
+in UEFI § 2.6.
+However, the EBBR target market has a reduced set of requirements,
+and so some UEFI features are omitted as unnecessary.
+
+Required Elements
+-
+
+This section replaces the list of required elements in [UEFI]_ § 2.6.1.
+All of the following UEFI elements are required for EBBR compliance.
+
+.. list-table:: UEFI Required Elements
+   :widths: 50 50
+   :header-rows: 1
+
+   * - Element
+ - Requirement
+   * - `EFI_SYSTEM_TABLE`
+ - The system table is required to provide required to access UEFI Boot 
Services,
+   UEFI Runtime Services, consoles, and other firmware, vendor and platform
+   information.
+   * - `EFI_BOOT_SERVICES`
+ - All functions defined as boot services must exist.
+   Methods for unsupported or unimplemented behaviour must return
+   an appropriate error code.
+   * - `EFI_RUNTIME_SERVICES`
+ - All functions defined as runtime services must exist.
+   Methods for unsupported or unimplemented behaviour must return
+   an appropriate error code.
+   * - `EFI_LOADED_IMAGE_PROTOCOL`
+ - Must be installed for each loaded image
+   * - `EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL`
+ - Must be installed for each loaded image
+   * - `EFI_DEVICE_PATH_PROTOCOL`
+ - An `EFI_DEVICE_PATH_PROTOCOL` must be installed onto all device
+   handles provided by the firmware.
+   * - `EFI_DEVICE_PATH_UTILITIES_PROTOCOL`
+ - Interface for creating and manipulating UEFI device paths
+
+.. list-table:: Notable omissions from UEFI § 2.6.1
+   :header-rows: 1
+
+   * - Element
+ - Note
+   * - `EFI_DECOMPRESS_PROTOCOL`
+ - Native EFI decompression is rarely used and therefore not required.
+
+Required Platform Specific Elements
+---
+
+This section replaces the list of required elements in [UEFI]_ § 2.6.2.
+All of the following UEFI elements are required for EBBR compliance.
+
+.. list-table:: UEFI Platform-Specific Required Elements
+   :widths: 50 50
+   :header-rows: 1
+
+   * - Element
+ - Description
+   * - Console devices
+ - The platform must have at least one console device
+   * - `EFI_SIMPLE_TEXT_INPUT_PROTOCOL`
+ - Needed for console input
+   * - `EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL`
+ - Needed for console input
+   * - `EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL`
+ - Needed for console output
+   * - `EFI_DEVICE_PATH_TO_TEXT_PROTOCOL`
+ - Needed for console output
+   * - `EFI_HII_STRING_PROTOCOL`
+ - Required by EFI shell and for compliance testing
+   * - `EFI_HII_DATABASE_PROTOCOL`
+ - Required by EFI shell and for compliance testing
+   * - `EFI_UNICODE_COLLATION2_PROTOCOL`
+ - Required by EFI shell and for compliance testing
+   * - `EFI_BLOCK_IO_PROTOCOL`
+ - Required for block device access
+   * - `EFI_SIMPLE_FILE_SYSTEM_PROTOCOL`
+ - Required if booting from block device is supported
+   * - `EFI_RNG_PROTOCOL`
+ - Required if the platform has a hardware entropy source
+   * - `EFI_SIMPLE_NETWORK_PROTOCOL`
+ - Required if the platform has a network device.
+   * - HTTP Boot (UEFI § 24.7)
+ - Required if the platform supports network booting
+
+The following table is a list of notable deviations from UEFI § 2.6.2.
+Many of these deviations are because the EBBR use cases do not require
+interface specific UEFI protocols, and so they have been made optional.
+
+.. list-table:: Notable Deviations from UEFI § 2.6.2
+   :widths: 50 50
+   :header-rows: 1
+
+   * - Element
+ - Description of deviation
+   * - `EFI_HII_CONFIG_ACCESS_PROTOCOL`
+ - UEFI requires this for console devices, but it is rarely necessary in 
practice.
+   Therefore this protocol is not required.
+   * - `EFI_HII_CONFIG_ROUTING_PROTOCOL`
+ - UEFI requires this for console devices, but it is rarely necessary in 
practice.
+   Therefore this protocol is not required.
+   * - Graphical console
+ - Platforms with a graphical device are not required to expose it as a 
graphical console.
+   * - `EFI_DISK_IO_PROTOCOL`
+ - Rarely used interface that isn't required for 

[EBBR PATCH 3/3] Require EFI_UPDATE_CAPSULE

[Grant Likely]

EFI_UPDATE_CAPSULE is the industry standard method for applying firmware
updates. Make it a requirement in EBBR so that fwupd, Windows Update,
and any other generic firmware update service can support EBBR platforms.

This is made required because the ability to update firmware is a
critical part of building secure platforms.

Fixes: #69
Signed-off-by: Grant Likely 
---
 source/chapter2-uefi.rst | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 3d48c99..4e8a24d 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -352,7 +352,7 @@ are required to be implemented during boot services and 
runtime services.
  - Required
  - Optional
* - `EFI_UPDATE_CAPSULE`
- - Optional
+ - Required for in-band update
  - Optional
* - `EFI_QUERY_CAPSULE_CAPABILITIES`
  - Optional
@@ -435,6 +435,25 @@ Even when SetVariable() is not supported during runtime 
services, firmware
 should cache variable names and values in EfiRuntimeServicesData memory so
 that GetVariable() and GetNextVeriableName() can behave as specified.
 
+Firmware Update
+---
+
+Being able to update firmware to address security issues is a key feature of 
secure platforms.
+EBBR platforms are required to implement either an in-band or an out-of-band 
firmware update mechanism.
+
+If firmware update is performed in-band (firmware on the application processor 
updates itself),
+then the firmware shall implement EFI_UPDATE_CAPSULE and accept updates in the
+"Firmware Management Protocol Data Capsule Structure" format as described in 
[UEFI]_ § 23.3,
+"Delivering Capsules Containing Updates to Firmware Management Protocol.  
[#FMPNote]_
+Firmware is also required to provide an EFI System Resource Table (ESRT). 
[UEFI]_ § 23.4
+Every firmware image that is updated in-band must be described in the ESRT.
+
+If firmware update is performed out-of-band (e.g., by an independent Board 
Management Controller,
+or firmware is provided by a hypervisor), then the platform is not required to 
implement EFI_UPDATE_CAPSULE.
+
+EFI_UPDATE_CAPSULE is only required before ExitBootServices() is called.
+
+
 .. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem
regarding secure storage.
OP-TEE's chosen solution is to rely on an OS supplicant agent to perform
@@ -445,3 +464,11 @@ that GetVariable() and GetNextVeriableName() can behave as 
specified.
during runtime services.
 
https://optee.readthedocs.io/en/latest/architecture/secure_storage.html
+
+.. [#FMPNote] The `EFI_UPDATE_CAPSULE` implementation is expected to be 
suitable
+   for use by generic firmware update services like fwupd and Windows Update.
+   Both fwupd and Windows Update read the ESRT table to determine what firmware
+   can be updated, and use an EFI helper application to call 
`EFI_UPDATE_CAPSULE`
+   before ExitBootServices() is called.
+
+   https://fwupd.org/
-- 
2.20.1

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

[EBBR PATCH 2/3] Refine RTC requirements

[Grant Likely]

If the platform has an RTC, then EFI_GET_TIME and EFI_SET_TIME are required
before ExitBootServices(). Clarify this in the spec.

Also specify that EFI_{GET,SET}_WAKEUP_TIME are required before
ExitBootService() if the RTC can wakeup the platform.

Signed-off-by: Grant Likely 
---
 source/chapter2-uefi.rst | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index f47a98d..3d48c99 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -319,16 +319,16 @@ are required to be implemented during boot services and 
runtime services.
  - Before ExitBootServices()
  - After ExitBootServices()
* - `EFI_GET_TIME`
- - Optional
+ - Required if RTC present
  - Optional
* - `EFI_SET_TIME`
- - Optional
+ - Required if RTC present
  - Optional
* - `EFI_GET_WAKEUP_TIME`
- - Optional
+ - Required if wakeup supported
  - Optional
* - `EFI_SET_WAKEUP_TIME`
- - Optional
+ - Required if wakeup supported
  - Optional
* - `EFI_SET_VIRTUAL_ADDRESS_MAP`
  - N/A
@@ -387,8 +387,11 @@ it may not be possible to access the RTC from runtime 
services.
 e.g., The RTC may be on a shared I2C bus which runtime services cannot access
 because it will conflict with the OS.
 
-If firmware does not support access to the RTC, then GetTime() and
-SetTime() shall return EFI_UNSUPPORTED,
+If an RTC is present, then GetTime() and SetTime() must be supported
+before ExitBootServices() is called.
+
+However, if firmware does not support access to the RTC after
+ExitBootServices(), then GetTime() and SetTime() shall return EFI_UNSUPPORTED
 and the OS must use a device driver to control the RTC.
 
 UEFI Reset and Shutdown
-- 
2.20.1

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

[EBBR PATCH 0/3] Updates for v2.0

[Grant Likely]

Hi all,

Here are the updates I've prepared for v2.0 of EBBR which I'd like to
tag for review sometime in the next few weeks. Please take a look and
yell if you have any concerns.

g.

[EBBR PATCH 1/3] Override UEFI section 2.6 requirements
[EBBR PATCH 2/3] Refine RTC requirements
[EBBR PATCH 3/3] Require EFI_UPDATE_CAPSULE

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

Re: [PATCH] Override UEFI section 2.6 requirements: UEFI System Partition GUID

[Grant Likely]

On 02/02/2021 15:37, Heinrich Schuchardt wrote:

On 02.02.21 11:45, Grant Likely wrote:

Thanks Heinrich,

Changes made and new patch to be posted soon.

g.


In the protocols section we should add that the UEFI System Partition
GUID has to be installed on the handle for the ESP. There is no protocol
for it. EDK II simply sets the protocol interface to NULL.


Is this already covered in the UEFI spec?

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

Re: [PATCH] Override UEFI section 2.6 requirements

[Grant Likely]

On 03/02/2021 15:17, Ilias Apalodimas wrote:

On Wed, Feb 03, 2021 at 03:53:09PM +0100, Fran�ois Ozog wrote:


Sure, but we're not talking about U-Boot, we're talking about EBBR the
standard and U-Boot has a number of means of implementing HTTPS Boot,
but by hobbling the standard with deployment technologies of the last
century I think is a mistake.

I have my opinions on whether implementing HTTP boot in U-Boot
directly or leaning on iPXE as the implementation but that is
irrelevant to what I think is right for EBBR as the standard. I think
we should be specifying HTTPS boot as a part of the spec, and having a
separate discussion of how that is supported in U-Boot.


I agree here. EBBR should specify interfaces/specs without requiring
iPXE, or any specific standard. HTTPS boot is clearly the right
direction, but I'm wrestling with when/how it should be added.

After our chat today, I'll propose that HTTPS boot be required by EBBR
if network boot is supported. U-Boot on it's own won't meet that
requirement, so for the time being U-Boot platforms won't be able to
claim EBBR compliant network boot.

Ilias and I discussed an approach where the HTTPs stack is in an EFI app

such as a standalone one or systemd-boot (this is a candidate because it
already has nice boot blessing capabilities that work in conjunction with
Linux systemd). iPXE has an implementation of the stack based on EFI
network protocol (raw packets), so the work shouldn't be that big.



I think what Grant proposes still stands (and for the record I agree with
Peter).

Having iPXE (while veryfying it before launching) is an alternative we can
implement relatively fast.
This raises a question here though. U-Boot won't be EBBR compliant, since it
would need an external application for the HTTP boot.  What about boards that
offer the firmware as a 'bundle' though? If they got a firmware + EFI app that
will be able to do HTTP boot they would be able to get a SystemReady-IR
certification?


Shouldn't be a problem. The platform is still EBBR compliant as long as 
it doesn't claim to support network boot because network booting is 
optional.


Also, if HTTPS boot is implemented using an external EFI binary that is 
packaged with U-Boot, then it still meets the network boot requirement. 
EBBR doesn't care how the feature is implemented.


g.



Thanks
/Ilias

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




--
Fran�ois-Fr�d�ric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

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

Re: [PATCH] Override UEFI section 2.6 requirements

[Grant Likely]

On 02/02/2021 16:46, Peter Robinson wrote:

* - EFI_PXE_BASE_CODE_PROTOCOL
 - Booting via the Preboot Execution Environment (PXE) is insecure.
   Loading via PXE is typically executed before launching the first
   UEFI application.


I don't think PXE should be a requirement, as Heinrich mentions it's
insecure. We should be requiring a secure protocol for a new spec, not
an old one that's being EOLed. I believe vendors are moving to remove
it in favour of HTTPS boot which also has the advantage it's more
flexible, and it much better places for IoT/Edge deployments which use
CDNs and the life extensively and it will generally work with
firewalls etc. If we're going to require something for network
installs, if the device has a capable network interface, it should be
HTTPS Boot.

Peter


Unfortunately we've got a functionality gap. U-Boot doesn't yet support
TCP, HTTP, or TLS. All that functionality needs to be written or ported
from somewhere.

I would really like to require a secure network boot mechanism, but I
think it needs to be left out until U-Boot can do TCP and TLS.


You can use iPXE as U-Boot payload which offers HTTPS and iSCSI. Isn't
that enough?


iPXE is an implementation not the standard. I think EBBR the standard
should require HTTPS boot, now if U-Boot chooses to implement that
part of the standard using an iPXE UEFI binary to implement HTTPS boot
that's an optoin.


TLS is quite complicated. GNU TLS has > 430,000 lines of code (without
comments). Looking at the number of CVEs in OpenSSL and GnuTLS I do not
believe that the U-Boot community will be able to produce and maintain a
secure implementation.


Sure, but we're not talking about U-Boot, we're talking about EBBR the
standard and U-Boot has a number of means of implementing HTTPS Boot,
but by hobbling the standard with deployment technologies of the last
century I think is a mistake.

I have my opinions on whether implementing HTTP boot in U-Boot
directly or leaning on iPXE as the implementation but that is
irrelevant to what I think is right for EBBR as the standard. I think
we should be specifying HTTPS boot as a part of the spec, and having a
separate discussion of how that is supported in U-Boot.


I agree here. EBBR should specify interfaces/specs without requiring 
iPXE, or any specific standard. HTTPS boot is clearly the right 
direction, but I'm wrestling with when/how it should be added.


After our chat today, I'll propose that HTTPS boot be required by EBBR 
if network boot is supported. U-Boot on it's own won't meet that 
requirement, so for the time being U-Boot platforms won't be able to 
claim EBBR compliant network boot.


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

EBBR Biweekly for Monday 01 Feb 2021

[Grant Likely]

Hi all,

Next EBBR biweekly is on Monday at 16:00 GMT. Dial-in details are below.

Below is the agenda I have so far. I've carried over the items that we
did not have time to discuss last week.

Agenda:
- Initrd passing
- Revised UEFI requirements (patch on mailing list)
- UpdateCapsule()
- other business

Please email if you want to add anything to the agenda

Cheers,
g.



Topic: EBBR Biweekly
Time: 1 Feb 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
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

[PATCH] Override UEFI section 2.6 requirements

[Grant Likely]

EBBR only requires a subset of UEFI. Provide a replacement for the UEFI
section that lists base requirements.

Fixes: #60
Fixes: #61
Fixes: #64
---

This is my first complete draft itemizing the specific UEFI requirements
for EBBR. Please review and comment.

Cheers,
g.

 source/chapter2-uefi.rst | 155 ++-
 1 file changed, 152 insertions(+), 3 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index aab1c2c..5864a17 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -14,8 +14,157 @@ This document uses version 2.8 Errata A of the UEFI 
specification [UEFI]_.
 UEFI Compliance
 ===
 
-EBBR compliant platforms shall conform to the requirements in [UEFI]_ § 2.6,
-except where explicit exemptions are provided by this document.
+EBBR compliant platform shall conform to a subset of the [UEFI]_ spec as listed
+in this section.
+Normally, UEFI compliance would require full compliance with all items listed
+in section 2.6 of the UEFI spec.
+However, the EBBR target market has a reduced set of requirements,
+and so some UEFI features are omitted as unnecessary.
+
+Required Elements
+-
+
+This section replaces the list of required elements in [UEFI]_ § 2.6.1.
+All of the following UEFI elements are required for EBBR compliance.
+
+.. list-table:: UEFI Required Elements
+   :widths: 50 50
+   :header-rows: 1
+
+   * - Element
+ - Requirement
+   * - `EFI_SYSTEM_TABLE`
+ - The system table is required to provide required to access UEFI Boot 
Services,
+   UEFI Runtime Services, consoles, and other firmware, vendor and platform
+   information.
+   * - `EFI_BOOT_SERVICES`
+ - All functions defined as boot services must exist.
+   Methods for unsupported or unimplemented behavour must return an 
appropriate error code.
+   * - `EFI_RUNTIME_SERVICES`
+ - All functions defined as runtime services must exist.
+   Methods for unsupported or unimplemented behavour must return an 
appropriate error code.
+   * - `EFI_LOADED_IMAGE_PROTOCOL`
+ - Must be installed for each loaded image
+   * - `EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL`
+ - Must be installed for each loaded image
+   * - `EFI_DEVICE_PATH_PROTOCOL`
+ - Interface to provide location of a device
+   * - `EFI_DEVICE_PATH_UTILITIES_PROTOCOL`
+ - Interface for creating and manipulating UEFI device paths
+
+.. list-table:: Notible Omissions from UEFI section 2.6.1
+   :header-rows: 1
+
+   * - Element
+ - Note
+   * - EFI_DECOMPRESS_PROTOCOL
+ - Native EFI Decompression is rarely used and therefore not required.
+
+Required Platform Specific Elements
+---
+
+This section replaces the list of required elements in [UEFI]_ § 2.6.2.
+All of the following UEFI elements are required for EBBR compliance.
+
+.. list-table:: UEFI Platform-Specific Required Elements
+   :widths: 50 50
+   :header-rows: 1
+
+   * - Element
+ - Description
+   * - Console devices
+ - The platform must have at least one console device
+   * - `EFI_SIMPLE_TEXT_INPUT_PROTOCOL`
+ - Needed for console input
+   * - `EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL`
+ - Needed for console input
+   * - `EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL`
+ - Needed for console output
+   * - `EFI_DEVICE_PATH_TO_TEXT_PROTOCOL`
+ - Needed for console output
+   * - `EFI_HII_STRING_PROTOCOL`
+ - Required by EFI shell and for compliance testing
+   * - `EFI_HII_DATABASE_PROTOCOL`
+ - Required by EFI shell and for compliance testing
+   * - `EFI_UNICODE_COLLATION2_PROTOCOL`
+ - Required by EFI shell and for compliance testing
+   * - `EFI_BLOCK_IO_PROTOCOL`
+ - Required for block device access
+   * - `EFI_SIMPLE_FILE_SYSTEM_PROTOCOL`
+ - Required if booting from block device is supported
+   * - `EFI_RNG_PROTOCOL`
+ - Required if platform has a hardware entropy source
+   * - Network booting
+ - If the platform supports network booting via TFTP,
+   then `EFI_SIMPLE_NETWORK_PROTOCOL` and
+   `EFI_PXE_BASE_CODE_PROTOCOL` must be implemented.
+
+The following table is a list of notable deviations from UEFI section 2.6.2.
+Many of these deviations are because the EBBR use cases do not require
+interface specific UEFI protocols, and so they have been made optional.
+
+.. list-table:: Notible Deviations from UEFI section 2.6.2
+   :widths: 50 50
+   :header-rows: 1
+
+   * - Element
+ - Description of deviation
+   * - `EFI_HII_CONFIG_ACCESS_PROTOCOL`
+ - UEFI requires this for console devices, but it is rarely necessary in 
practice.
+   Therefore this protocol is not requried.
+   * - `EFI_HII_CONFIG_ROUTING_PROTOCOL`
+ - UEFI requires this for console devices, but it is rarely necessary in 
practice.
+   Therefore this protocol is not requried.
+   * - Graphical console
+ - Platforms with a graphical device are not required to expose it as a 
graphical console.
+   * - 

Re: EBBR Biweekly for 18 Jan 2021

[Grant Likely]

On 17/01/2021 15:01, François Ozog wrote:

Hi Grant

I’d like EBBR to specify  a solution to identify the default serial 
console out of existing optional indications.


Hi Francois,

This is a good topic. EBBR starts from the assumption that whether ACPI 
or DT is used for the system description, the data will follow the 
requirements of the technology. For ACPI I don't think we need to add 
any language, but it would be worthwhile to require stdout-path is 
specified in the DT. Do you want to propose some language?


On DT systems , we shall state that /chosen/stdout-path must point to a 
valid path.


On ACPI, we may get the info form \_SB_.COM0 @ DSDT or specify we will 
get the info from SPCR table. >
Regardless of the method , this is required to just boot and do not have 
to care about clumsy command lines with early_console or console parameters.


Agree. Mucking with the commandline should not be required.



I like this topic be added to the agenda ?


yes. Can you also add an issue to track this topic please?

g.

Le sam. 16 janv. 2021 à 13:59, Grant Likely <mailto:grant.lik...@arm.com>> a écrit :


Hi all,

Next EBBR meeting is ON for Monday, 18 Jan 2021 at 16:00 GMT. I think
there is quite a backlog of items to discuss. Here's what I've got for
the agenda so far:

* Update on specific required protocols
    * https://github.com/ARM-software/ebbr/issues/60
<https://github.com/ARM-software/ebbr/issues/60>
    * https://github.com/ARM-software/ebbr/issues/61
<https://github.com/ARM-software/ebbr/issues/61>
    * https://github.com/ARM-software/ebbr/issues/64
<https://github.com/ARM-software/ebbr/issues/64>
* Firmware update requirements
    * https://github.com/ARM-software/ebbr/issues/69
<https://github.com/ARM-software/ebbr/issues/69>
* DT fixup protocol proposal
    * https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL
<https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL>
    * https://github.com/ARM-software/ebbr/issues/68
<https://github.com/ARM-software/ebbr/issues/68>
* Other business

If you would like to discuss anything else, please reply to this email.

    Dial in details are here:

---

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
<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
<https://armltd.zoom.us/u/aelJgr9ZAW>


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

--

François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/
T: +33.67221.6485
francois.o...@linaro.org <mailto:francois.o...@linaro.org> | Skype: ffozog



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

Re: EBBR Biweekly for 18 Jan 2021

[Grant Likely]

Hi all,

Samer reminded me that today is a holiday in the US, so not everyone 
will be able to join. I'm going to hold the call regardless because I 
think there is enough to discuss, and I'll make sure good notes are taken.


g.

On 16/01/2021 12:58, Grant Likely wrote:

Hi all,

Next EBBR meeting is ON for Monday, 18 Jan 2021 at 16:00 GMT. I think 
there is quite a backlog of items to discuss. Here's what I've got for 
the agenda so far:


* Update on specific required protocols
   * https://github.com/ARM-software/ebbr/issues/60
   * https://github.com/ARM-software/ebbr/issues/61
   * https://github.com/ARM-software/ebbr/issues/64
* Firmware update requirements
   * https://github.com/ARM-software/ebbr/issues/69
* DT fixup protocol proposal
   * https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL
   * https://github.com/ARM-software/ebbr/issues/68
* Other business

If you would like to discuss anything else, please reply to this email.

Dial in details are here:

---

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


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

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

EBBR Biweekly for 18 Jan 2021

[Grant Likely]

Hi all,

Next EBBR meeting is ON for Monday, 18 Jan 2021 at 16:00 GMT. I think 
there is quite a backlog of items to discuss. Here's what I've got for 
the agenda so far:


* Update on specific required protocols
  * https://github.com/ARM-software/ebbr/issues/60
  * https://github.com/ARM-software/ebbr/issues/61
  * https://github.com/ARM-software/ebbr/issues/64
* Firmware update requirements
  * https://github.com/ARM-software/ebbr/issues/69
* DT fixup protocol proposal
  * https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL
  * https://github.com/ARM-software/ebbr/issues/68
* Other business

If you would like to discuss anything else, please reply to this email.

Dial in details are here:

---

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


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

[EBBR PATCH] Require EFI_UPDATE_CAPSULE

[Grant Likely]

EFI_UPDATE_CAPSULE is the industry standard method for applying firmware
updates. Make it a requirement in EBBR so that fwupd, Windows Update,
and any other generic firmware update service can support EBBR platforms.

This is made required because the ability to update firmware is a
critical part of building secure platforms.

Fixes: #69
Signed-off-by: Grant Likely 
---
 source/chapter2-uefi.rst | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 7b5eb24..b1182a8 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -167,7 +167,10 @@ are required to be implemented during boot services and 
runtime services.
EFI_SET_VARIABLE   Required  Optional
EFI_GET_NEXT_HIGH_MONO_COUNT   N/A   Optional
EFI_RESET_SYSTEM   Required  Optional
-   EFI_UPDATE_CAPSULE Optional  Optional
+   EFI_UPDATE_CAPSULE Required  Optional
+  for in-band
+  firmware
+  update
EFI_QUERY_CAPSULE_CAPABILITIES Optional  Optional
EFI_QUERY_VARIABLE_INFOOptional  Optional
== = 
@@ -243,6 +246,25 @@ Even when SetVariable() is not supported during runtime 
services, firmware
 should cache variable names and values in EfiRuntimeServicesData memory so
 that GetVariable() and GetNextVeriableName() can behave as specified.

+Firmware Update
+---
+
+Being able to update firmware to address security issues is a key feature of 
secure platforms.
+EBBR platforms are required to implement either an in-band or an out-of-band 
firmware update mechanism.
+
+If firmware update is performed in-band (firmware on the application processor 
updates itself),
+then the firmware shall implement EFI_UPDATE_CAPSULE and accept updates in the
+"Firmware Management Protocol Data Capsule Structure" format as described in 
[UEFI]_ § 23.3,
+"Delivering Capsules Containing Updates to Firmware Management Protocol.  
[#FMPNote]_
+Firmware is also required to provide an EFI System Resource Table (ESRT). 
[UEFI]_ § 23.4
+Every firmware image that is updated in-band must be described in the ESRT.
+
+If firmware update is performed out-of-band (e.g., by an independent Board 
Management Controller,
+or firmware is provided by a hypervisor), then the platform is not required to 
implement EFI_UPDATE_CAPSULE.
+
+EFI_UPDATE_CAPSULE is only required before ExitBootServices() is called.
+
+
 .. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem
regarding secure storage.
OP-TEE's chosen solution is to rely on an OS supplicant agent to perform
@@ -253,3 +275,11 @@ that GetVariable() and GetNextVeriableName() can behave as 
specified.
during runtime services.

https://optee.readthedocs.io/en/latest/architecture/secure_storage.html
+
+.. [#FMPNote] The `EFI_UPDATE_CAPSULE` implementation is expected to be 
suitable
+   for use by generic firmware update services like fwupd and Windows Update.
+   Both fwupd and Windows Update read the ESRT table to determine what firmware
+   can be updated, and use an EFI helper application to call 
`EFI_UPDATE_CAPSULE`
+   before ExitBootServices() is called.
+
+   https://fwupd.org/
--
2.20.1

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: EBBR Biweekly (Postponed to 14th Dec)

[Grant Likely]

Ilias has offered to host the meeting today. I'm hoping to join part way 
through if I can.


g.

On 13/12/2020 19:06, Grant Likely wrote:

Hi everyone.

I have to do this, but I have another unexpected conflict for the EBBR biweekly 
on the 14th.

Rather than cancelling outright, does anyone else want to chair the meeting? 
The major planned orientatio item on the agenda was to talk about EBBR testing, 
with Heinrich sharing what he is currently doing.

If I don't hear anything by about 1pm GMT tomorrow then I'll just cancel. Our 
next meeting will be in January as I believe most of us will already be on 
Christmas holiday on the 21st

g.

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

EBBR Biweekly (Postponed to 14th Dec)

[Grant Likely]

I have a conflict this week and need to cancel. I propose pushing out to next 
week (Dec 14th), and cancelling the meeting on the 21st when many people will 
be on holiday anyway. Let me know if you want anything added to the meeting 
agenda before next week.

Draft agenda:

  *   Action item review
  *   EBBR Testing Efforts (SCT, FWTS, etc)
  *   UEFI Exception text changes
  *   Next release schedule
  *   Other business


Time: This is a recurring meeting Meet anytime

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: EBBR Biweekly today

[Grant Likely]

Notes page from Monday (unedited; will get to that later)

thttps://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2020.11.25

g.

On 23/11/2020 12:34, Grant Likely wrote:

Hi all,

Here is the draft agenda for the EBBR biweekly today. As always, let me
know if there is anything you want to add. Notes will be taken in
Etherpad[1].

Draft agenda:
- Issue & PR review
- Draft EBBR text for tailoring UEFI section 2.6 base requirements[2]
- Roundtable
- Any other business

[1] https://etherpad.opendev.org/p/EBBR
[2] https://github.com/ARM-software/ebbr/wiki/Required-EFI-protocols

---

Monday 23 November
16:00 GMT

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

EBBR Biweekly today

[Grant Likely]

Hi all,

Here is the draft agenda for the EBBR biweekly today. As always, let me
know if there is anything you want to add. Notes will be taken in
Etherpad[1].

Draft agenda:
- Issue & PR review
- Draft EBBR text for tailoring UEFI section 2.6 base requirements[2]
- Roundtable
- Any other business

[1] https://etherpad.opendev.org/p/EBBR
[2] https://github.com/ARM-software/ebbr/wiki/Required-EFI-protocols

---

Monday 23 November
16:00 GMT

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

EBBR Biweekly for 16 Nov 2020

[Grant Likely]

[Note to self: I really should start sending out this email on Friday
instead of Monday afternoon]

Reminder; next EBBR meeting is today at 16:00 GMT. Dial in details are
below.

Let me know if there is anything you want added to the agenda

Agenda:
- Action item review
- UEFI Exceptions Chapter
- Any other business

---

Time: Every second Monday starting 31 Aug at 16:00BST, 08:00PST

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH v2 2/2] Add RISC-V support content to the EBBR specification

[Grant Likely]

We didn't meet this week due to a conflict with another meeting. There 
hasn't been any discussion aside from this thread.


g.

On 08/11/2020 23:40, Atish Patra wrote:

On Thu, Oct 22, 2020 at 4:19 PM Atish Patra  wrote:


On Wed, Oct 21, 2020 at 3:21 AM Grant Likely  wrote:


Hi Atish,

Thanks for this. Comments below.

On 16/10/2020 02:10, Atish Patra wrote:

This patch adds all minimum mandatory requirements to make RISC-V compatible
with EBBR.

Signed-off-by: Atish Patra 
---
   source/chapter1-about.rst   | 42 +++--
   source/chapter2-uefi.rst| 10 +++-
   source/chapter3-secureworld.rst | 14 +++
   source/references.rst   |  4 
   4 files changed, 67 insertions(+), 3 deletions(-)

diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index 3db3f3280448..6927c87a125f 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -152,9 +152,10 @@ operating system.
   SBBR is targeted at the server ecosystem and places strict requirements on 
the
   platform to ensure cross vendor interoperability.
   EBBR on the other hand allows more flexibility to support embedded designs
-which do not fit within the SBBR model.
-For example, a platform that isn't SBBR compliant because the SoC is only
+which do not fit within the SBBR model. For example, a platform that isn't 
SBBR compliant because the SoC is only


This hunk is a no-op change to the content and should be dropped from
the patch, but it's a good opportunity to bring up a writing(coding)
style comment. :-D  As much as possible the EBBR source files should use
"semantic linefeeds" with one sentence per line because when changes are
made it eliminate diff hunks due to paragraph reflow. Here's how Brian
Kernighan described it:

 Hints for Preparing Documents

 Most documents go through several versions (always more than you
 expected) before they are finally finished.
 Accordingly, you should do whatever possible to make the job of
 changing them easy.

 First, when you do the purely mechanical operations of typing,
 type so subsequent editing will be easy.
 Start each sentence on a new line.
 Make lines short, and break lines at natural places,
 such as after commas and semicolons, rather than randomly.
 Since most people change documents by rewriting phrases and adding,
 deleting and rearranging sentences,
 these precautions simplify any editing you have to do later.

 Brian W. Kernighan, 1974

Source : http://rhodesmill.org/brandon/2012/one-sentence-per-line/



Got it. I will update it.


I'll propose a patch adding this guidance to the EBBR repo.



   supported using Devicetree could be EBBR compliant, but not SBBR compliant.
+EBBR also supports multiple architectures such as AArch64 & RISC-V. However, 
RISC-V
+is not compatible with SBBR. Thus, a EBBR compliant RISC-V platform would not 
be SBBR compliant.


This section is primarily commentary about the purpose of EBBR and how
it compares with other specifications. Rather than defining where EBBR
isn't aligned with SBBR, I'd rather rework the paragraph to state that
EBBR is aligned with SBBR on AArch64 platforms. How about this for new text?

---
This specification was inspired by the Server Base Boot Requirements
specification [SBBR]_ used by the Arm AArch64 architecture.
SBBR is targeted at the server ecosystem,

and places strict requirements on the firmware interfaces presented to
OSes
to ensure cross vendor interoperability.

Similarly, EBBR provides requirements on firmware interfaces
using many of the same technologies,
but provides more flexibility to support embedded designs

which do not align with server platform requirements.



EBBR strives to remain aligned with SBBR by requiring the same
interfaces where
possible, and ensuring EBBR requirements are not mutually exclusive to SBBR.
For example, SBBR requires an ACPI system description,

but EBBR allows either ACPI or a Devicetree.
If ACPI support was added to an EBBR platform,
it would still retain EBBR compliance.
By definition, this means that all Arm SBBR compliant systems

are also EBBR compliant, but the converse is not true.
---

I won't be committing this as-is because I still need to do a bit more
rework to transition from SBBR to BBR as part of Arm SystemReady. There
is a bunch of AArch64 text that will get pulled out of EBBR because
things like exception level handling are detailed properly in the BBR now.



But there can be a RISC-V specific privilege section in EBBR. Correct ?



Apologies if these things were discussed in the EBBR meeting. I am
unable to attend it because of RISC-V platform specification
meetings.

Any comments  on this ?


Details here:

https://developer.arm.com/architectures/system-architectures/arm-systemready
https://developer.arm.com/documentation/den0044/latest



I see the BBR also specifies the subset of UEFI boot time services &

EBBR Biweekly: Postponed to next week

[Grant Likely]

Hi folks,

Very sorry, but I'm going to postpone this week's EBBR meeting to next
week. Arm has an internal quarterly meeting that conflicts. I'm going to
reschedule to the same slot next week.

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

EBBR Biweekly for 26 Oct 2020

[Grant Likely]

Reminder: Next EBBR Biweekly meeting is today at 16:00 UTC. Please note, 
UK daylight savings time ended yesterday, so this will be an hour later 
for everyone in the US or otherwise still on DST.


Please reply if you want to add an item to the agenda.

Notes will be collected on Etherpad. Please help take notes if you can. 
Here is the link:


https://etherpad.opendev.org/p/EBBR

Time: Every second Monday starting 31 Aug at 16:00BST, 08:00PST

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH 1/2] Add Western Digital copyright

[Grant Likely]

On 13/10/2020 19:39, Atish Patra wrote:

Signed-off-by: Atish Patra 


No need for this to be a separate patch. Squash into patch 2 please 
where the additional copyright text is actually added.



---
  source/index.rst | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/source/index.rst b/source/index.rst
index bf2dadf3be47..6758994c5bbf 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -1,5 +1,6 @@
  .. EBBR Source Document
 Copyright Arm Limited, 2017-2019
+   Copyright Western Digital Corporation or its affiliates, 2020


These copyright statements should be specific. Just "Western Digital 
Corporation" please. Affiliates can provide their own copyright lines if 
they care.


The "and Contributors" bit from the Arm line is historical from when the 
document was forked from SBBR. I'll look to clean that up.


g.


 SPDX-License-Identifier: CC-BY-SA-4.0
  
  

@@ -8,6 +9,8 @@ Embedded Base Boot Requirements (EBBR) Specification
  
  Copyright © 2017-2019 Arm Limited and Contributors.
  
+Copyright © Western Digital Corporation or its affiliates, 2020.

+
  This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
  International License. To view a copy of this license, visit
  http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to


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

Re: [PATCH v2 2/2] Add RISC-V support content to the EBBR specification

[Grant Likely]

Hi Atish,

Thanks for this. Comments below.

On 16/10/2020 02:10, Atish Patra wrote:

This patch adds all minimum mandatory requirements to make RISC-V compatible
with EBBR.

Signed-off-by: Atish Patra 
---
  source/chapter1-about.rst   | 42 +++--
  source/chapter2-uefi.rst| 10 +++-
  source/chapter3-secureworld.rst | 14 +++
  source/references.rst   |  4 
  4 files changed, 67 insertions(+), 3 deletions(-)

diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index 3db3f3280448..6927c87a125f 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -152,9 +152,10 @@ operating system.
  SBBR is targeted at the server ecosystem and places strict requirements on the
  platform to ensure cross vendor interoperability.
  EBBR on the other hand allows more flexibility to support embedded designs
-which do not fit within the SBBR model.
-For example, a platform that isn't SBBR compliant because the SoC is only
+which do not fit within the SBBR model. For example, a platform that isn't 
SBBR compliant because the SoC is only


This hunk is a no-op change to the content and should be dropped from
the patch, but it's a good opportunity to bring up a writing(coding)
style comment. :-D  As much as possible the EBBR source files should use
"semantic linefeeds" with one sentence per line because when changes are
made it eliminate diff hunks due to paragraph reflow. Here's how Brian
Kernighan described it:

   Hints for Preparing Documents

   Most documents go through several versions (always more than you
   expected) before they are finally finished.
   Accordingly, you should do whatever possible to make the job of
   changing them easy.

   First, when you do the purely mechanical operations of typing,
   type so subsequent editing will be easy.
   Start each sentence on a new line.
   Make lines short, and break lines at natural places,
   such as after commas and semicolons, rather than randomly.
   Since most people change documents by rewriting phrases and adding,
   deleting and rearranging sentences,
   these precautions simplify any editing you have to do later.

   Brian W. Kernighan, 1974

Source : http://rhodesmill.org/brandon/2012/one-sentence-per-line/

I'll propose a patch adding this guidance to the EBBR repo.



  supported using Devicetree could be EBBR compliant, but not SBBR compliant.
+EBBR also supports multiple architectures such as AArch64 & RISC-V. However, 
RISC-V
+is not compatible with SBBR. Thus, a EBBR compliant RISC-V platform would not 
be SBBR compliant.


This section is primarily commentary about the purpose of EBBR and how
it compares with other specifications. Rather than defining where EBBR
isn't aligned with SBBR, I'd rather rework the paragraph to state that
EBBR is aligned with SBBR on AArch64 platforms. How about this for new text?

---
This specification was inspired by the Server Base Boot Requirements
specification [SBBR]_ used by the Arm AArch64 architecture.
SBBR is targeted at the server ecosystem,

and places strict requirements on the firmware interfaces presented to
OSes
to ensure cross vendor interoperability.

Similarly, EBBR provides requirements on firmware interfaces
using many of the same technologies,
but provides more flexibility to support embedded designs

which do not align with server platform requirements.



EBBR strives to remain aligned with SBBR by requiring the same
interfaces where
possible, and ensuring EBBR requirements are not mutually exclusive to SBBR.
For example, SBBR requires an ACPI system description,

but EBBR allows either ACPI or a Devicetree.
If ACPI support was added to an EBBR platform,
it would still retain EBBR compliance.
By definition, this means that all Arm SBBR compliant systems

are also EBBR compliant, but the converse is not true.
---

I won't be committing this as-is because I still need to do a bit more
rework to transition from SBBR to BBR as part of Arm SystemReady. There
is a bunch of AArch64 text that will get pulled out of EBBR because
things like exception level handling are detailed properly in the BBR now.

Details here:

https://developer.arm.com/architectures/system-architectures/arm-systemready
https://developer.arm.com/documentation/den0044/latest



  By definition, all SBBR compliant systems are also EBBR compliant, but the
  converse is not true.
@@ -228,6 +229,43 @@ This document uses the following terms and abbreviations.
Original Equipment Manufacturer. In this document, the final device
manufacturer.

+   RISC-V
+  An open standard Instruction Set Architecture (ISA) based on Reduced 
Instruction
+  Set Architecture (RISC).
+
+   HART
+  Hardware thread in RISC-V. This is the hardware execution context that 
contains
+  all the state mandated by the ISA.
+
+   M Mode
+  Machine mode is the most secure and privileged mode in RISC-V.


Nit: "M Mode" here, but in the spec text 

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Grant Likely]

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.


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

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Grant Likely]

On 06/10/2020 13:41, Ilias Apalodimas wrote:

Hi Grant,

[...]


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.


I agree with that, but that is not my concern.

My concern is that the FIT image format will only be supported by U-Boot.
Other UEFI implementations do not implement it.

On the other hand, adding a UEFI Stub to the FIT image format makes it a
generic solution that can be used by any UEFI implementation. This would be
separate from the linux kernel's UEFI stub, and should only deal with
choosing the appropriate kernel/initrd/dtb from the FIT and then calling
into the kernel's stub to actually boot the kernel.


If we are considering a cross-firmware solution for this why base it on FIT?
Wouldn't a single EFI application (that's aware of the signatures and how
to verify them) do the job? Just to inherit the work on signatures already done
in FIT?


Hahaha! I wasn't going to bring that up because I didn't want to cause 
extra trouble. :-) But yes, you're right. If we have a UEFI stub on the 
container, then it doesn't matter what the container format is. cpio, 
tar.gz, zip, FAT image, etc. Any of those would work.



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.


Devicetree fixups indeed needs to be solved. I would propose registering a
new protocol for fixups. If the protocol is present, then stub can call it.
If not, then the DTB from the fit should be used unmodified.

g.


So if you do this in a single EFI app, you wont need an extra protocol for it
right?


True, you could embed the DT fixups into the EFI stub itself, but that 
would end up being completely separate logic from the fixup code already 
in U-Boot.


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

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Grant Likely]

On 06/10/2020 13:36, Heinrich Schuchardt wrote:

On 06.10.20 14:04, François Ozog wrote:

As always, Ard made a good point, and I feel compelled to top post and
restate stuff.

Here is the supporting deck:
https://docs.google.com/presentation/d/1JK00su6e7vt8lRfwSt2C9EuuzwcBHLyoLRRrdcYfVWY/edit?usp=sharing
  
We have two boot flows under consideration (not saying others are bad,

just to say they are on focus):
A.1 typical distro (slide 2):  -->  --> 
--> Linux; Linux is here defined as the tuple {vmlinuz}, vmlinuz is
verified through EFI mechanism by either efi firmware or shim,  ACPI
tables are verified by firmware, initrd is not verified
A.2 typical embedded (slide 3):  -> Linux ; Linux is here
defined as the tuple {vmlinuz, initrd, dtb} that is folded into a FIT
and are verified via signature, it avoid errors/attacks about mixing
vmlinuz/initrd/dtb.

We want EBBR "equivalent" flows (Equivalent meaning with the same level
of security and accepting the weaknesses).
B.1 typical distro (slide 4):  -->  --> 
--> Linux
B.2 typical embedded (slide 5):  -> Linux

For B.1 to be equivalent to A.1, we need the DT to be authenticated
(ACPI is embedded in the firmware in A.1).
For B2. to be equivalent to A.2, we  need the DT and initrd to be
authenticated

_
We can first validate this point: let's check whether we want to do this
(regardless of the implementation details, focusing on the intention).



On the implementation side, last call we discussed Trusting DT and we
ended up talking about trusting initrd too (probably because B.2 in the
back of our minds, without being explicit about this).

After giving some additional thoughts, it sounds like a good approach is
to "lead by example": let's implement what we think are the "archetype"
flows for Qemu and maintain it over time. We would make all changes we
think are good in all relevant projects (tfa, op-tee, u-boot,
devicetree, linux kernel, qemu...). Being an "archetype" flow does not
prevent systems to be EBBR compliant, we just have reference flows.

_
We can validate this second point: are we in agreement that leading by
an end-to-end example on a platform, rather by technology layers
(trusting DT PoC was in that spirit) ?



What are the implementation details of B.1 and B.2?

B.1
To trust DT the proposal is to make its use closer to ACPI: this is a
platform attribute that is verified by firmware and handed over to OS.
To achieve that:
- we create a platform repo in devicetree.org ,
add the Qemu-bsa DT (coming from current Linux kernel ), and maintain it
over time. We shall ensure forward/backward compatibility of relevant
Linux drivers.
- the resulting DTB is compiled and integrated by the platform vendor in
its TF-A FIP at NT_FW_CONFIG section.


When building OpenSBI you can specify a device-tree using environment
variable FW_PAYLOAD_FDT_PATH.


- at boot time, TF-A verifies DTB, pass it to U-Boot, U-Boot passes that
DTB to the shim as a config table and boot flow continues; the platform
DTB can be overridden by grub (without any verification, that can be
seen as a weaker than ACPI case); the Linux EFI-STUB uses EFI_LOAD_FILE2
protocol to get the initrd (unverified). Linux command line dtb= is disabled

B.2
To trust DT the proposal is to make its use closer to ACPI: this is a
platform attribute that is verified by firmware and handed over to OS.
To trust the initrd the proposal is to leverage the same concept as A.2:
create a tuple with {vmlinuz, initrd, dtb}
To achieve that:
- we create a platform repo in devicetree.org ,
add the Qemu-bsa DT (coming from current Linux kernel ), and maintain it
over time. We shall ensure forward/backward compatibility of relevant
Linux drivers.


QEMU provides its own device-tree to the firmware. Why would we need a
Linux device-tree for QEMU?

The Linux Foundation is unable to ensure that their device-trees are
usable. With a Linux DTB after v5.3 I cannot start my MacchiatoBin with
v5.4-v5.7.


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.


That doesn't solve the problem of DTB schema stability, but it at least 
decouples the problem so we're not stuck.


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

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Grant Likely]

On 06/10/2020 13:04, François Ozog wrote:
As always, Ard made a good point, and I feel compelled to top post and 
restate stuff.


Here is the supporting deck:
https://docs.google.com/presentation/d/1JK00su6e7vt8lRfwSt2C9EuuzwcBHLyoLRRrdcYfVWY/edit?usp=sharing

We have two boot flows under consideration (not saying others are bad, 
just to say they are on focus):
A.1 typical distro (slide 2):  -->  -->  
--> Linux; Linux is here defined as the tuple {vmlinuz}, vmlinuz is 
verified through EFI mechanism by either efi firmware or shim,  ACPI 
tables are verified by firmware, initrd is not verified
A.2 typical embedded (slide 3):  -> Linux ; Linux is here 
defined as the tuple {vmlinuz, initrd, dtb} that is folded into a FIT 
and are verified via signature, it avoid errors/attacks about mixing 
vmlinuz/initrd/dtb.


We want EBBR "equivalent" flows (Equivalent meaning with the same level 
of security and accepting the weaknesses).
B.1 typical distro (slide 4):  -->  -->  
--> Linux

B.2 typical embedded (slide 5):  -> Linux

For B.1 to be equivalent to A.1, we need the DT to be authenticated 
(ACPI is embedded in the firmware in A.1).


Current EBBR requires DT to be embedded in firmware by default. OS has 
option to replace it, but the firmware provided DT can be verified with 
the firmware image.


For B2. to be equivalent to A.2, we need the DT and initrd to be 
authenticated


I'm proposing an alternative to B2:
 -> FIT Shim (payload of kernel+initrd+dt) -> Linux

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

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Grant Likely]

On 06/10/2020 05: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.


I agree with that, but that is not my concern.

My concern is that the FIT image format will only be supported by 
U-Boot. Other UEFI implementations do not implement it.


On the other hand, adding a UEFI Stub to the FIT image format makes it a 
generic solution that can be used by any UEFI implementation. This would 
be separate from the linux kernel's UEFI stub, and should only deal with 
choosing the appropriate kernel/initrd/dtb from the FIT and then calling 
into the kernel's stub to actually boot the kernel.



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.


Devicetree fixups indeed needs to be solved. I would propose registering 
a new protocol for fixups. If the protocol is present, then stub can 
call it. If not, then the DTB from the fit should be used unmodified.


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

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

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

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

Re: Specifying the boot flow

[Grant Likely]

On 01/10/2020 21:29, Simon Glass wrote:

Hi Grant,

[who is 'nd'?]


As Ard says, magic bot that suppresses the disclaimer on outgoing Arm 
email. Others have figured out how to send email without it, but I've 
not got mine sorted yet.



On Wed, 30 Sep 2020 at 09:26, Grant Likely  wrote:

On 28/09/2020 17:51, Simon Glass wrote:

Case 1:
Firmware loads the kernel to a particular address, selects DT and
boots it. The kernel may require EFI boot services, or may not, but in
the general case the firmware provides them.

Case 2:
Firmware loads EFI app and provides EFI boot services to it. How the
system actually boots is under control of the app.

As far as bootefi is concerned, case 1 & case 2 are identical. The image
to be run is loaded into memory and bootefi executes the payload. In
case 1 the payload in Linux's built-in UEFI stub. In case 2 the payload
is grub.efi, shell.efi, shim.efi, etc.

bootefi differs from bootm in that instead of a bare vmlinuz image or a
FIT image, the loaded image is a PECOFF executable. U=Boot parses the
PECOFF headers, loads the sections into memory and jumps to the entry
point. It also leaves a pointer to an in-memory information table with
callbacks into firmware functions for accessing basic services (console,
block device, network, graphics, filesystem, etc).

If the image is Linux, then the stub will do a small amount of setup
before calling ExitBootServices(), which tells firmware to stop managing
hardware because the kernel is taking over. (In UEFI terms, this is call
an "OS loader" image)

If the image is a transient binary like Grub or the UEFI shell, it can
use firmware facilities to load additional files (e.g., initrd, kernel,
etc) before jumping into another PE/COFF binary. For example, Grub will
typically load the kernel into memory, which itself is a PE/COFF image,
and then jump to its entry point.


Yes. I think this is the source of the pain, since there is really no
limit on what these can do and there is no standard flow. Much of the
loading happens outside the control of the bootloader, which means
that verified boot and testing are harder.



If an image doesn't call ExitBootServices(), and instead exits, control
returns to firmware as one would expect.


I feel that a lot of the confusion about verified boot, DT selections,
boot menus, etc. is coming from the introduction of an EFI app which
has no specification (it can be grub, shim or something else, as I
understand it). Certainly this is very flexible and future-proof, but
it is also arbitrarily complex, unpredictable and hard to secure.


Of the items you've listed above, DT selection does indeed need work,
but the rest is quite well specified. The UEFI spec has very clear
specifications on how the boot image is selected via the BOOT
variables and the format of the binaries. Secure Boot is also
standardized so that when Secure Boot is turned on, firmware will only
execute images signed by a recognized key.

It is no more arbitrarily complex than booting an OS kernel. When
compared against bootm, both boot flows load an image into memory, and
both jump to the image starting point. In both cases the OS can do
whatever it wants after the firmware jumps into it, and in both cases if
security is enabled then the binaries must be signed.


I think you are missing my point. With bootm etc. it jumps straight
from U-Boot to linux. Of course linux may have an EFI shim, but there
is no grub or any other loader 'in the way'.


I fully understand your point, I just disagree with it. :-)

In both case U-Boot sets up an environment for "something-other" to run. 
In the case of a raw linux kernel image*, it sets up the environments as 
specified by Linux in

- Documentation/arm/booting.rst
- Documentation/arm64/booting.rst
- etc.

In the case of UEFI PE/COFF, if sets up the environment as described in 
the UEFI spec, section 2; particularly 2.3 which describes the calling 
convention.


These are not fundamentally different, other than the Linux environment 
is specific to Linux, but the UEFI one is standard across several OSes 
and tools.


To look at the simplest scenario, UEFI also defines a standard way to 
choose what to boot next. It uses the BOOT and BOOTORDER variables 
to store what to boot, and which one to try next. If BOOT points at 
the kernel, then U-Boot goes straight to Linux.


[...]

I am wondering if we can come up with a way to deterministically
specify how a system will boot and how to make it boot a different way
(i.e. with a different kernel, initrd, DT).

Heinrich mentioned EFI variables as a way of selecting
kernel/initrd/DT. Then the problem becomes just a case of being able
to change those variables from Linux userspace. Is that right?

We are talking about having a 'secure' part of EBBR, which allows for
secure boot. Should we have a 'defined boot' part of EBBR, that
defines how the kernel/DT/initrd are selected, based on EFI variables?

Unfortunately 

Re: Specifying the boot flow

[Grant Likely]

Hi Simon,

Heinrich provided some great answers on the technical details. I'll try 
not to retrace his answers, but there are a few conceptual model bits 
that I think are worth talking about...


On 28/09/2020 17:51, Simon Glass wrote:

Hi,

I thought perhaps it might be worth starting a thread on this, as
despite Grant and Heinrich kinding spending a bit of time talking
about this, I am still very much in the dark about how 'embedded' and
distro/other boot flows are going to come together with EBBR. Of
course this would be easier f2f.


I'll assume for both of the cases you describe below that the UEFI boot 
path (bootefi) is used instead of the traditional bootm.



Case 1:
Firmware loads the kernel to a particular address, selects DT and
boots it. The kernel may require EFI boot services, or may not, but in
the general case the firmware provides them.

Case 2:
Firmware loads EFI app and provides EFI boot services to it. How the
system actually boots is under control of the app.
As far as bootefi is concerned, case 1 & case 2 are identical. The image 
to be run is loaded into memory and bootefi executes the payload. In 
case 1 the payload in Linux's built-in UEFI stub. In case 2 the payload 
is grub.efi, shell.efi, shim.efi, etc.


bootefi differs from bootm in that instead of a bare vmlinuz image or a 
FIT image, the loaded image is a PECOFF executable. U=Boot parses the 
PECOFF headers, loads the sections into memory and jumps to the entry 
point. It also leaves a pointer to an in-memory information table with 
callbacks into firmware functions for accessing basic services (console, 
block device, network, graphics, filesystem, etc).


If the image is Linux, then the stub will do a small amount of setup 
before calling ExitBootServices(), which tells firmware to stop managing 
hardware because the kernel is taking over. (In UEFI terms, this is call 
an "OS loader" image)


If the image is a transient binary like Grub or the UEFI shell, it can 
use firmware facilities to load additional files (e.g., initrd, kernel, 
etc) before jumping into another PE/COFF binary. For example, Grub will 
typically load the kernel into memory, which itself is a PE/COFF image, 
and then jump to its entry point.


If an image doesn't call ExitBootServices(), and instead exits, control 
returns to firmware as one would expect.



I feel that a lot of the confusion about verified boot, DT selections,
boot menus, etc. is coming from the introduction of an EFI app which
has no specification (it can be grub, shim or something else, as I
understand it). Certainly this is very flexible and future-proof, but
it is also arbitrarily complex, unpredictable and hard to secure.


Of the items you've listed above, DT selection does indeed need work, 
but the rest is quite well specified. The UEFI spec has very clear 
specifications on how the boot image is selected via the BOOT 
variables and the format of the binaries. Secure Boot is also 
standardized so that when Secure Boot is turned on, firmware will only 
execute images signed by a recognized key.


It is no more arbitrarily complex than booting an OS kernel. When 
compared against bootm, both boot flows load an image into memory, and 
both jump to the image starting point. In both cases the OS can do 
whatever it wants after the firmware jumps into it, and in both cases if 
security is enabled then the binaries must be signed.


Where UEFI differs is that it continues to offer {console,net,block,fs} 
services for as long as the image chooses to use them so that early boot 
code doesn't need to carry its own implementations.



I am wondering if we can come up with a way to deterministically
specify how a system will boot and how to make it boot a different way
(i.e. with a different kernel, initrd, DT).

Heinrich mentioned EFI variables as a way of selecting
kernel/initrd/DT. Then the problem becomes just a case of being able
to change those variables from Linux userspace. Is that right?

We are talking about having a 'secure' part of EBBR, which allows for
secure boot. Should we have a 'defined boot' part of EBBR, that
defines how the kernel/DT/initrd are selected, based on EFI variables?

Unfortunately I just don't know enough about all the different boot
flows used by the different distros. It seems like crazy town. Does
anyone have some pointers so I can do some study?


A great way to get familiar with it is to play around with the UEFI code 
already in U-Boot with the UEFI Self Certification test suite. Building 
the SCT is straight forward, and there are some instructions for doing 
so here:


https://github.com/glikely/edk2-test-manifest

If you enable UEFI in U-Boot and copy the SCT to a USB drive, u-boot 
should be able to find and run the UEFI shell from the USB drive.


There is also good documentation on the U-Boot implementation:

https://github.com/u-boot/u-boot/blob/master/doc/uefi/uefi.rst

Cheers,
g.
___

Re: EBBR Biweekly for 28-Sep-2020

[Grant Likely]

Notes from this week:

https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2020.09.28

Kind of messy. I haven't gone and formatted anything or cleaned up the text.

g.

On 28/09/2020 15:04, Grant Likely wrote:
Going to try Etherpad for taking meeting notes this week: Will copy the 
results into the wiki after the meeting.


https://etherpad.opendev.org/p/EBBR

g.

On 28/09/2020 14:58, Grant Likely wrote:

Hi folks.

Reminder that the biweekly EBBR call is in about an hour. So far, this
is what I have for the agenda:

1. Issue & PR review
2. Changes to DT spec
3. Next release planning
4. Any other business

Talk to you in an hour.

g.



Time: Every second Monday starting 31 Aug at 16:00BST, 08:00PST

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended 
recipient, please notify the sender immediately and do not disclose 
the contents to any other person, use it for any purpose, or store or 
copy the information in any medium. Thank you.

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

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

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

Re: EBBR Biweekly for 28-Sep-2020

[Grant Likely]

Going to try Etherpad for taking meeting notes this week: Will copy the 
results into the wiki after the meeting.


https://etherpad.opendev.org/p/EBBR

g.

On 28/09/2020 14:58, Grant Likely wrote:

Hi folks.

Reminder that the biweekly EBBR call is in about an hour. So far, this
is what I have for the agenda:

1. Issue & PR review
2. Changes to DT spec
3. Next release planning
4. Any other business

Talk to you in an hour.

g.



Time: Every second Monday starting 31 Aug at 16:00BST, 08:00PST

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended 
recipient, please notify the sender immediately and do not disclose the 
contents to any other person, use it for any purpose, or store or copy 
the information in any medium. Thank you.

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

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

Re: EBBR Biweekly for 28-Sep-2020

[Grant Likely]

Hi folks.

Reminder that the biweekly EBBR call is in about an hour. So far, this
is what I have for the agenda:

1. Issue & PR review
2. Changes to DT spec
3. Next release planning
4. Any other business

Talk to you in an hour.

g.



Time: Every second Monday starting 31 Aug at 16:00BST, 08:00PST

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [dtspec PATCH] Import /reserved-memory specification text

[Grant Likely]

Fixed. Thanks Etienne

g.

On 16/09/2020 11:45, Etienne Carriere wrote:

Hello Grant,

Some minor typos.
Looks all good to me for the rest, by the way.



On Mon, 14 Sep 2020 at 21:59, Grant Likely  wrote:


Imported from linux kernel source:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt

Very minor editorial changes made while importing, with one exception.
Added clause that the 'no-map' and 'reusable' properties are mutually
exclusive.

Signed-off-by: Grant Likely 
Cc: Rob Herring 
Cc: Heinrich Schuchardt 
Cc: Ard Biesheuvel 
---
  source/chapter3-devicenodes.rst | 199 
  1 file changed, 199 insertions(+)

diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
index 3aa4650..1c1149a 100644
--- a/source/chapter3-devicenodes.rst
+++ b/source/chapter3-devicenodes.rst
@@ -200,6 +200,205 @@ memory ranges. The 2 GB I/O region is skipped. Note that 
the
  value of 2, which means that two 32-bit cells are required to define the
  address and length for the ``reg`` property of the memory node.

+``/reserved-memory`` Node
+-
+
+Reserved memory is specified as a node under the ``/reserved-memory`` node.
+The operating system shall exclude reserved memory from normal usage


Minor: looks like above and below lines are separated sentences.
"... normal usage. One can ...".



+one can create child nodes describing particular reserved (excluded from
+normal use) memory regions.
+Such memory regions are usually designed for the special usage by various
+device drivers.
+
+Parameters for each memory region can be encoded into the device tree
+with the following nodes:
+
+/reserved-memory parent node
+
+
+.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} |
+.. table:: /reserved-memory Parent Node Properties
+
+   === = = 
===
+   Property Name   Usage Value TypeDefinition
+   === = = 
===
+   ``#address-cells``  R  Specifies the number of 
 cells to
+   represent the address in the 
``reg`` property in
+   children of root.
+   ``#size-cells`` R  Specifies the number of 
 cells to
+   represent the size in the 
``reg`` property in
+   children of root.
+   ``ranges``  R   parent address to child address 
spaces (see
+   section 
:ref:`sect-standard-properties-ranges`,
+   ranges).
+   Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See 
Definition
+   
===
+
+``#address-cells`` and ``#size-cells`` should use the same values as for the 
root node,
+and ``ranges`` should be empty so that address translation logic works 
correctly.
+
+/reserved-memory/ child nodes
+~
+
+Each child of the reserved-memory node specifies one or more regions of
+reserved memory. Each child node may either use a ``reg`` property to
+specify a specific range of reserved memory, or a ``size`` property with
+optional constraints to request a dynamically allocated block of memory.
+
+Following the generic-names recommended practice, node names should
+reflect the purpose of the node (ie. "*framebuffer*" or "*dma-pool*").
+Unit address (``@``) should be appended to the name if the node
+is a static allocation.
+
+A reserved memory node requires either a ``reg`` property for static
+allocations, or a ``size`` property for dynamics allocations.
+Dynamic allocations may use ``alignment`` and ``alloc-ranges`` properties
+to constrain where the memory is allocated from.
+If both ``reg`` and ``size`` are present, then the region is treated as a
+static allocation with the ``reg`` property taking precedence and ``size``
+is ignored.
+
+.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} |
+.. table:: ``/reserved-memory/`` Child Node Properties
+
+   === = = 
===
+   Property Name   Usage Value TypeDefinition
+   === = = 
===
+   ``reg`` O   Consists of an 
arbitrary number of address and
+   size pairs that 
specify the physical address
+   

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

[Grant Likely]

On 15/09/2020 17:00, Heinrich Schuchardt wrote:

On 15.09.20 16:50, Grant Likely wrote:



On 15/09/2020 15:36, Heinrich Schuchardt wrote:

On 15.09.20 16:16, Ard Biesheuvel wrote:
[...]>>>> EfiRuntimeServicesData is not covered by the linear map, but 
will map

it in the EFI page tables for access by the firmware itself at
runtime, so it is not an option here.



The device-tree spec specifically says /mmemreserve/ serve to "define an
entry for the devicetree blob’s memory reservation table."


I think this is just poorly worded. It would be better written as:
     "Memory reservations create entries in the devicetree blob’s
     memory reservation table."


Shouldn't the description of /memreserve/ refer to chapter 5.3 Memory
Reservation Block? E.g.

"Memory reservations blocks (see chapter 5.3) are represented by lines
of the form

 /memreserve/  ;

where  and  are 64-bit C-style integers, e.g.

 /memreserve/ 0x1000 0x0004000;"


I like that language & layout. I've pulled it into the draft patch. Thanks!


Some requirements in chapter 5.3.1 sound similar to the description of
the no-map sub-nodes of /reserved-memory, e.g. speculative access is
prohibited:

"Any memory that is declared in a memory node and is accessed by the
boot program or caused to be accessed by the boot program after client
entry must be reserved. Examples of this type of access include (e.g.,
speculative memory reads through a non-guarded virtual page)."

So in line with our discussion concerning no-map EfiReservedMemoryType
seems the most appropriate.

UEFI runtime drivers will be relocated by SetVirtualMemoryMap(). So the
requirement in the above citation does not make much sense for memory
that is EfiRuntimeServicesCode or EfiRuntimeServicesData. So those
should not be modeled as /memreserve/. Just another issue with the DT spec.


Okay. I'm convinced. I'll specify EfiReservedMemoryType for memreserve.

g.

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

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

[Grant Likely]

On 15/09/2020 16:31, Leif Lindholm wrote:

On Tue, Sep 15, 2020 at 15:04:44 +0100, Grant Likely wrote:

On 15/09/2020 14:46, Leif Lindholm wrote:
EfiBootServicesData: Memory still gets mapped in the linear map, but
nothing protects it after ExitBootServices (would require leaving
/memreserve/ intact so the OS knows to protect them).

EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but
causes a change in behaviour. The memory will not appear in the linear
map. This will possibly cause problems with existing drivers

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

Other options?


I'll defer to Ard on the actual selection.

But while care should take not to actively *break* Linux (esp wrt
backwards compatibility), if we end up picking one over the other
based only (or mainly) on Linux internals, we need to very clearly
call that out in the spec.


That's certainly my intent. This is undefined behaviour right now, so
Linux behaviour is the de-facto starndard. I'd like to get that coded
into a spec.

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

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

[Grant Likely]

On 15/09/2020 15:36, Heinrich Schuchardt wrote:

On 15.09.20 16:16, Ard Biesheuvel wrote:

On Tue, 15 Sep 2020 at 17:05, Grant Likely  wrote:




On 15/09/2020 14:46, Leif Lindholm wrote:

On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:

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

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

  efi/arm64: Fix fdt-related memory reservation


Does that still make sense? I understand why it was done, but is it
right to ignore those reservations outright?


Yes. It is duplication of (sources of) information, forcing the
operating system to make runtime, or compile time, judgement calls of
which source(s) of information to respect.


Not quite that simple. We're not talking about a clean cut-over from
non-UEFI to UEFI platforms, but rather a phased transition where with a
given DT, both the non-UEFI and UEFI boot paths need to work. e.g.,
U-Boot platforms where most people are using 'bootm', but want to start
encouraging them to use the UEFI infrastructure.

Or in other words, the master source of information is the .dts file,
not the firmware itself.

The other issue is that the reserved memory region may not be about
firmware at all, but rather a memory layout that is wanted only by the
OS. Regardless of the approach we take here, those regions must be
respected.


As more U-Boot platforms
turn on UEFI there could be unexpected consequences if the memory
reservation block are silently ignored. I'm think that on the U-Boot
platforms it is more likely that /memreserve/ is in use.


That should also make it easy to intercept? Like putting a hook in the
DT update code that triggers build error/warning (or even update the
UEFI memory map) if someone is trying to memreserve with the UEFI
interface enabled.


It should not be an error to use /memreserve/. That creates a hard break
between UEFI and non-UEFI boot paths for /memreserve/. Updating the
memory map is fine, which leads to the question of what memory type
should be used?

EfiBootServicesData: Memory still gets mapped in the linear map, but
nothing protects it after ExitBootServices (would require leaving
/memreserve/ intact so the OS knows to protect them).

EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but
causes a change in behaviour. The memory will not appear in the linear
map. This will possibly cause problems with existing drivers



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


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



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



The device-tree spec specifically says /mmemreserve/ serve to "define an
entry for the devicetree blob’s memory reservation table."


I think this is just poorly worded. It would be better written as:
"Memory reservations create entries in the devicetree blob’s
memory reservation table."


If I look at Linux code I find things like:

/* First 4KB has trampoline code for secondary cores. */
/memreserve/ 0x 0x0001000;

/* firmware-provided startup stubs live here, where the secondary CPUs are
  * spinning.
  */
/memreserve/ 0x 0x1000;

/memreserve/ 0x1000 0x0004000;*/  /* DSP RAM */

CPUs with a 'spin-table' enable-method "should spin outside of the
kernel in a reserved area of memory (communicated to the kernel by a
/memreserve/ region in the device tree".

This usage is not what I would have understood under the description in
the devicetree spec. So the DT spec needs some clarification.

The problem with EfiRuntimeServicesData is that it can be moved anywhere
in the virtual address space via SetVirtualAddressMap(). But do we know
that the firmware can handle such a relocation?

Best regards

Heinrich









It should be fine for /memreserve/ entries to get applied to the memmap
during boot. Are there problems that I'm missing?


Sure. They can be applied in the UEFI memory map. By u-boot, during
boot.

/
  Leif


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

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

[Grant Likely]

On 15/09/2020 14:59, Heinrich Schuchardt wrote:

On 15.09.20 15:46, Leif Lindholm wrote:

On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:

+``/memory`` node and UEFI
+~~
+
+When booting via [UEFI]_, the system memory map is obtained via the
+GetMemoryMap() UEFI boot time service as defined in [UEFI]_ § 7.2,
+and if present, the OS must ignore any ``/memory`` nodes.



This should cover /memreserve/ entries as well.


What memory type should be used for /memreserve/? The memory reserve
block isn't nearly as expressive, so we don't have details about how to
use it. Be conservative and specify EfiReservedMemoryType?



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


Looks like in Linux the memory is reserved without the nomap behaviour
(not removed). Unlike with /reserved-memory, EfiBootServicesData won't
currently give us the behaviour we want if the kernel is currently
ignoring the memory reserved block. (for /reserved-memory, the kernel
'finds' the reservations again during early boot, so the UEFI
protections only need to extend to the ExitBootServices() call. With the
memory reserved block, the kernel has no way to know if it should
continue to respect those reservations after ExitBootServices if it
isn't parsing the block.

Should the kernel still respect Memory Reserved block when booting via
UEFI? At this point I'm inclined to say yes.



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

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

 efi/arm64: Fix fdt-related memory reservation


Does that still make sense? I understand why it was done, but is it
right to ignore those reservations outright?


Yes. It is duplication of (sources of) information, forcing the
operating system to make runtime, or compile time, judgement calls of
which source(s) of information to respect.


As more U-Boot platforms
turn on UEFI there could be unexpected consequences if the memory
reservation block are silently ignored. I'm think that on the U-Boot
platforms it is more likely that /memreserve/ is in use.


That should also make it easy to intercept? Like putting a hook in the
DT update code that triggers build error/warning (or even update the
UEFI memory map) if someone is trying to memreserve with the UEFI
interface enabled.


It should be fine for /memreserve/ entries to get applied to the memmap
during boot. Are there problems that I'm missing?


Sure. They can be applied in the UEFI memory map. By u-boot, during
boot.

The device-tree spec says they are used for device tree blobs. So I
guess in the memory map returned by GetMemoryMap() they would have to be
EfiACPIReclaimMemory like the area for the device-tree itself. We should
define this in the EBBR.


What bit is that? I see the text saying /memreserve/ adds an entry to
the blob's reservation table, but not that it is used for device tree blobs:

   Memory reservations define an entry for the devicetree blob’s memory
   reservation table. They have the form: e.g., /memreserve/ 
   ; Where  and  are 64-bit C-style integers.

g.



In the device-tree spec an example showing the syntax of /memreserve/
nodes should be added.

Best regards

Heinrich



/
 Leif


g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

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

[Grant Likely]

On 15/09/2020 14:46, Leif Lindholm wrote:

On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:

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

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

 efi/arm64: Fix fdt-related memory reservation


Does that still make sense? I understand why it was done, but is it
right to ignore those reservations outright?


Yes. It is duplication of (sources of) information, forcing the
operating system to make runtime, or compile time, judgement calls of
which source(s) of information to respect.


Not quite that simple. We're not talking about a clean cut-over from
non-UEFI to UEFI platforms, but rather a phased transition where with a
given DT, both the non-UEFI and UEFI boot paths need to work. e.g.,
U-Boot platforms where most people are using 'bootm', but want to start
encouraging them to use the UEFI infrastructure.

Or in other words, the master source of information is the .dts file,
not the firmware itself.

The other issue is that the reserved memory region may not be about
firmware at all, but rather a memory layout that is wanted only by the
OS. Regardless of the approach we take here, those regions must be
respected.


As more U-Boot platforms
turn on UEFI there could be unexpected consequences if the memory
reservation block are silently ignored. I'm think that on the U-Boot
platforms it is more likely that /memreserve/ is in use.


That should also make it easy to intercept? Like putting a hook in the
DT update code that triggers build error/warning (or even update the
UEFI memory map) if someone is trying to memreserve with the UEFI
interface enabled.


It should not be an error to use /memreserve/. That creates a hard break
between UEFI and non-UEFI boot paths for /memreserve/. Updating the
memory map is fine, which leads to the question of what memory type
should be used?

EfiBootServicesData: Memory still gets mapped in the linear map, but
nothing protects it after ExitBootServices (would require leaving
/memreserve/ intact so the OS knows to protect them).

EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but
causes a change in behaviour. The memory will not appear in the linear
map. This will possibly cause problems with existing drivers

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

Other options?




It should be fine for /memreserve/ entries to get applied to the memmap
during boot. Are there problems that I'm missing?


Sure. They can be applied in the UEFI memory map. By u-boot, during
boot.

/
 Leif


g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

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

[Grant Likely]

On 15/09/2020 09:33, Heinrich Schuchardt wrote:

Closes: #52

The no-map property of the /reserved-memory device tree nodes is used to
signal that a memory region shall not be accessed by the operating system,
even not via speculative access.

/reserved-memory nodes without the no-map property describe memory that
have special usage by the operating system.

This difference has to be reflected in the memory map returned by
GetMemoryMap().

Signed-off-by: Heinrich Schuchardt 
---
  source/chapter2-uefi.rst | 13 +
  source/references.rst|  4 
  2 files changed, 17 insertions(+)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 74ef70e..f410c57 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -74,6 +74,19 @@ that virtual addresses must equal physical addresses.

  The default RAM allocated attribute must be EFI_MEMORY_WB.

+In the device tree reserved memory in modelled as a /reserved-memory nodes
+[RESMEM]_. The reserved-memory node MAY carry either the no-map or the resue
+property. It MUST NOT carry both properties as this would be contradictary.
+

After having looked at reserved-memory.txt in the kernel and the
devicetree spec, I think this should just go straight into dtspec or
into the kernel tree. I drafted a couple patches yesterday that first
imports /reserved-memory into dtspec, and then adds the UEFI
annotations. Here's the current patch for the latter:



diff --git a/source/chapter3-devicenodes.rst
b/source/chapter3-devicenodes.rst
index 3043b8a..647e487 100644
--- a/source/chapter3-devicenodes.rst
+++ b/source/chapter3-devicenodes.rst
@@ -160,6 +160,12 @@ If the VLE storage attribute is supported, with VLE=0.
 .. note:: All other standard properties (section
:ref:`sect-standard-properties`) are allowed but are optional.

+``/memory`` node and UEFI
+~~
+
+When booting via [UEFI]_, the system memory map is obtained via the
+GetMemoryMap() UEFI boot time service as defined in [UEFI]_ § 7.2,
+and if present, the OS must ignore any ``/memory`` nodes.

 ``/memory`` Examples
 
@@ -314,6 +320,9 @@ is ignored.
 The ``no-map`` and ``reusable`` properties are mutually exclusive and
both must
 not be used together in the same node.

+Dynamic reserved memory regions must not listed in the [UEFI]_ memory map
+because they are allocated by the OS after exiting firmware boot services.
+
 Linux implementation notes:

 - If a ``linux,cma-default`` property is present, then Linux will use the
@@ -341,6 +350,19 @@ nodes by adding a ``memory-region`` property to the
device node.
Usage legend: R=Required, O=Optional, OR=Optional but Recommended,
SD=See Definition

===

+``/reserved-memory`` and UEFI
+~
+When booting via [UEFI]_, static ``/reserved-memory`` regions must
+also be listed in the system memory map obtained via the GetMemoryMap()
+UEFI boot time service as defined in [UEFI]_ § 7.2.
+The reserved memory regions need to be included in the UEFI memory map to
+protect them from memory allocations by UEFI applications.
+
+Reserved regions with the ``no-map`` property must be listed in the memory
+map with type ``EfiReservedMemoryType``.
+All other reserved regions must be listed with the type
+``EfiBootServicesData``.
+
 ``/reserved-memory`` Example
 

diff --git a/source/references.rst b/source/references.rst
index 961fa20..8400e96 100644
--- a/source/references.rst
+++ b/source/references.rst
@@ -23,3 +23,7 @@
 .. [EPAPR] *Power.org Standard for Embedded Power Architecture
Platform Requirements*, power.org, 2011,

https://www.power.org/documentation/power-org-standard-for-embedded-power-architecture-platform-requirements-epapr-v1-1-2/
+
+.. [UEFI] `Unified Extensable Firmware Interface Specification v2.8
Errata A
+
`_,
+   February 2020, `UEFI Forum `_
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

[dtspec PATCH] Import /reserved-memory specification text

[Grant Likely]

Imported from linux kernel source:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt

Very minor editorial changes made while importing, with one exception.
Added clause that the 'no-map' and 'reusable' properties are mutually
exclusive.

Signed-off-by: Grant Likely 
Cc: Rob Herring 
Cc: Heinrich Schuchardt 
Cc: Ard Biesheuvel 
---
 source/chapter3-devicenodes.rst | 199 
 1 file changed, 199 insertions(+)

diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
index 3aa4650..1c1149a 100644
--- a/source/chapter3-devicenodes.rst
+++ b/source/chapter3-devicenodes.rst
@@ -200,6 +200,205 @@ memory ranges. The 2 GB I/O region is skipped. Note that 
the
 value of 2, which means that two 32-bit cells are required to define the
 address and length for the ``reg`` property of the memory node.

+``/reserved-memory`` Node
+-
+
+Reserved memory is specified as a node under the ``/reserved-memory`` node.
+The operating system shall exclude reserved memory from normal usage
+one can create child nodes describing particular reserved (excluded from
+normal use) memory regions.
+Such memory regions are usually designed for the special usage by various
+device drivers.
+
+Parameters for each memory region can be encoded into the device tree
+with the following nodes:
+
+/reserved-memory parent node
+
+
+.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} |
+.. table:: /reserved-memory Parent Node Properties
+
+   === = = 
===
+   Property Name   Usage Value TypeDefinition
+   === = = 
===
+   ``#address-cells``  R  Specifies the number of 
 cells to
+   represent the address in the 
``reg`` property in
+   children of root.
+   ``#size-cells`` R  Specifies the number of 
 cells to
+   represent the size in the 
``reg`` property in
+   children of root.
+   ``ranges``  R   parent address to child address 
spaces (see
+   section 
:ref:`sect-standard-properties-ranges`,
+   ranges).
+   Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See 
Definition
+   
===
+
+``#address-cells`` and ``#size-cells`` should use the same values as for the 
root node,
+and ``ranges`` should be empty so that address translation logic works 
correctly.
+
+/reserved-memory/ child nodes
+~
+
+Each child of the reserved-memory node specifies one or more regions of
+reserved memory. Each child node may either use a ``reg`` property to
+specify a specific range of reserved memory, or a ``size`` property with
+optional constraints to request a dynamically allocated block of memory.
+
+Following the generic-names recommended practice, node names should
+reflect the purpose of the node (ie. "*framebuffer*" or "*dma-pool*").
+Unit address (``@``) should be appended to the name if the node
+is a static allocation.
+
+A reserved memory node requires either a ``reg`` property for static
+allocations, or a ``size`` property for dynamics allocations.
+Dynamic allocations may use ``alignment`` and ``alloc-ranges`` properties
+to constrain where the memory is allocated from.
+If both ``reg`` and ``size`` are present, then the region is treated as a
+static allocation with the ``reg`` property taking precedence and ``size``
+is ignored.
+
+.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} |
+.. table:: ``/reserved-memory/`` Child Node Properties
+
+   === = = 
===
+   Property Name   Usage Value TypeDefinition
+   === = = 
===
+   ``reg`` O   Consists of an 
arbitrary number of address and
+   size pairs that 
specify the physical address
+   and size of the 
memory ranges.
+   ``size``O   Size in bytes of 
memory to reserve for
+   dynamically 
allocated regions.
+   Size of this 
property is ba

Re: [PATCH] Refine firmware shared storage requirements.

[Grant Likely]

On 02/09/2020 13:41, Ard Biesheuvel wrote:

On Wed, 2 Sep 2020 at 15:26, Heinrich Schuchardt  wrote:


On 02.09.20 12:11, Daniel Thompson wrote:

On Tue, Sep 01, 2020 at 04:53:49PM +0200, Heinrich Schuchardt wrote:

On 01.09.20 16:49, Daniel Thompson wrote:

On Tue, Sep 01, 2020 at 03:55:15PM +0200, Heinrich Schuchardt wrote:

On 01.09.20 12:59, Grant Likely wrote:

The existing language around how firmware and an OS can share a storage
device doesn't go into sufficient detail on how the firmware should
protect firmware data on the device. Add language for both the GPT and
MBR partitioning schemes on how firmware images should be described in
the partition table.

Signed-off-by: Grant Likely 
---

I posted this patch before the v1.0.1 release, but didn't merge it at
that time because it needs a little more due diligence than can be give
on a minor point release. Posting it now for proper review.

  source/chapter4-firmware-media.rst | 67 +++---
  1 file changed, 51 insertions(+), 16 deletions(-)

diff --git a/source/chapter4-firmware-media.rst 
b/source/chapter4-firmware-media.rst
index fc71274..65da603 100644
--- a/source/chapter4-firmware-media.rst
+++ b/source/chapter4-firmware-media.rst
@@ -47,13 +47,19 @@ conflict with normal usage of the media by an OS.
  Partitioning of Shared Storage
  ==

-A shared storage device shall use GPT partitioning unless it is incompatible
-with the platform boot sequence.
-In which case, MBR partitioning shall be used. [#MBRReqExample]_
-
-.. [#MBRReqExample] For example, if the boot ROM doesn't understand GPT
-   partitioning, and will only work with an MBR, then the storage must be
-   partitioned using an MBR.
+The shared storage device must use the GUID Partition Table (GPT) disk
+layout as defined in [UEFI]_ § 5.3, unless the platform boot sequence is
+fundamentally incompatible with the GPT disk layout.
+In which case, a legacy Master Boot Recored (MBR) must be used.
+[#MBRReqExample]_
+
+.. [#MBRReqExample] For example, if the SoC boot ROM requires an MBR to
+   find the next stage firmware image, then it is incompatible with
+   the GPT boot layout.
+   Similarly, if the boot ROM expects the next stage firmware to be located
+   at LBA1 (the location of the GPT Header), then it is incompatible with
+   the GPT disk layout.
+   In both cases the shared storage device must use legacy MBR partitioning.

  .. warning::

@@ -71,15 +77,14 @@ the partition(s) containing firmware.

  However, some SoCs load firmware from a fixed offset into the storage media.
  In this case, to protect against partitioning tools overwriting firmware, the
-firmware image shall either reside entirely within the first 1MiB of storage,
-or should be covered by a protective partition entry in the partition table as
+partition table must be formed in a way to protect the firmware image(s) as
  described in sections :ref:`section-gpt-parts` and :ref:`section-mbr-parts`.

-Automatic partitioning tools (e.g. an OS installer) must not create
-partitions within the first 1MiB of storage, or delete, move, or modify
-protective partition entries.
+Automatic partitioning tools (e.g. an OS installer) must not
+delete the protective information in the partition table, or
+delete, move, or modify protective partition entries.
  Manual partitioning tools should provide warnings when modifying
-protective partitions or creating partitions within the first 1MiB.
+protective partitions.

  .. warning::

@@ -95,19 +100,49 @@ GPT partitioning
  

  The partition table must strictly conform to the UEFI specification and 
include
-a protective MBR authored exactly as described in [UEFI]_ § 5 (hybrid
+a protective MBR authored exactly as described in [UEFI]_ § 5.3 (hybrid
  partitioning schemes are not permitted).

-Protective partitions must have the Platform Required Attribute Flag set.
+Fixed-location firmware images must be protected by creating protective
+partition entries, or by placing GPT data structures away from the LBAs
+occupied by firmware,
+
+Protective partitions are entries in the partition table that cover the
+LBA region occupied by firmware and have the 'Required Partition' attribute


%s/'Required Partition'/bit 0, 'Required Partition'/


+set.


Shouldn't we also set bit 1, 'No Block IO Protocol'?


Would that make it more difficult to write EFI based firmware update
tools (that do know what the partition is used for) to write out
updates?


You would still have the Block IO Protocol on disk level. So no, I do
not think this would complicate things.


Not quite sure I agree with that.

It certainly means it is not impossible for an EFI app to update firmware
components. However not having partitioned block IO protocols sounds
like the updater would need to include additional GPT parsing code
(although on platforms where the offsets are fixed perhaps the offsets
could be burned in instead).


I don't have any strong

Re: EBBR Biweekly for 14-Sep-2020

[Grant Likely]

Notes from today:

https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2020.09.14

Please feel free to make corrections or add anything I missed.

g.

On 14/09/2020 14:15, Grant Likely wrote:

Reminder: the next EBBR regular meeting is later today at
16:00BST/08:00PDT. Draft agenda below. Right now the agenda is very
light. I'll keep the meeting short if we don't have anything to discuss.

Agenda
- Report on DT reserved-memory discussion
- issue & PR review

Send me an email if you want to add an item to the agenda, or add an
issue to the github page. Also email me if you want me to send you a
calendar invite for the meeting series.

https://github.com/arm-software/ebbr/issues

g.



Time: Every second Monday starting 31 Aug at 16:00BST, 08:00PST

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH] Add a reference to RFC 2119

[Grant Likely]

On 14/09/2020 14:48, Daniel Thompson wrote:

On Mon, Sep 14, 2020 at 02:40:20PM +0100, Daniel Thompson wrote:

Define the meanings of "MUST" and similar language for clarity.

Fixes: #46
Signed-off-by: Daniel Thompson 


Looks like Grant and I both thought "let's just fix this one before the
meeting"!

You can ignore this (unless you want to copy the specific sphinx
syntax for citing RFCs).


:-D :-D

I'll pick up the sphinx syntax. Thanks!

g.




Daniel.



---
  source/chapter1-about.rst | 4 
  1 file changed, 4 insertions(+)

diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index 3744d8a14086..3b5339a9c202 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -171,6 +171,10 @@ UEFI § 6.1 - Reference to the UEFI specification [UEFI]_ 
section 6.1
  Terms and abbreviations
  ===

+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in :rfc:`2119`.
+
  This document uses the following terms and abbreviations.

  .. glossary::
--
2.25.4


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


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

EBBR Biweekly for 14-Sep-2020

[Grant Likely]

Reminder: the next EBBR regular meeting is later today at
16:00BST/08:00PDT. Draft agenda below. Right now the agenda is very
light. I'll keep the meeting short if we don't have anything to discuss.

Agenda
- Report on DT reserved-memory discussion
- issue & PR review

Send me an email if you want to add an item to the agenda, or add an
issue to the github page. Also email me if you want me to send you a
calendar invite for the meeting series.

https://github.com/arm-software/ebbr/issues

g.



Time: Every second Monday starting 31 Aug at 16:00BST, 08:00PST

Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09

Meeting ID: 920 8136 5511
Password: 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
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

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

[Grant Likely]

On 07/09/2020 15:56, Grant Likely wrote:



On 07/09/2020 15:55, Daniel Thompson wrote:

On Mon, Sep 07, 2020 at 03:22:22PM +0100, Grant Likely wrote:

I've not heard back, and I've got a conflict this afternoon. I'm going
to resched for later in the week. Going to aim for Wednesday.


Are you trying the schedule a full EBBR meeting or just a discussion
about this thread?


Only about this thread. The next EBBR meeting will be next week Monday.

Next EBBR meeting will be 16:00BST Monday, 14th Aug. I'll add you to the
calendar invite.

g.



g.




Daniel.




g.

On 02/09/2020 13:58, Grant Likely wrote:



On 02/09/2020 07:52, Ard Biesheuvel wrote:

On Wed, 2 Sep 2020 at 09:48, Heinrich Schuchardt 
wrote:


On 9/1/20 10:51 AM, Ard Biesheuvel wrote:

On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt
 wrote:


On 8/31/20 9:01 PM, Ard Biesheuvel wrote:

On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt
 wrote:


Closes: #52

The no-map property of the /reserved-memory DT node is used by
Linux to
signal that a memory region shall not be mapped and that
speculative access
shall not be permitted.

The memory map returned by GetMemoryMap() does not have a flag
corresponding to no-map. So the closest thing we can do is not to
include
no-map reserved memory into the map returned by GetMemoryMap().



Dear Ard,

thanks for reviewing.



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


Do you have an example of a no-map /reserved-memory node used in
Linux?



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


Hello Ard,

I found the following compatibility strings for no-map areas in the
Linux device trees:

compatible = "shared-dma-pool"
compatible = "qcom,rmtfs-mem"
compatible = "qcom,cmd-db"

If Linux simply ignores the no-map property from the device-tree when
booting via UEFI and in UEFI we simply map those areas as reserved,
there is a conceptual gap as you already stated in a separate mail.



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

In other words, today we just assume that the /reserved-memory node
and the EFI memory map do not contradict each other, but we have no
definition or explicit requirement anywhere what that actually means.


Yeah, we need to clean this up and make it consistent. Would like to
have a call about this and look at some examples before trying to draft
the requirement. We probably need something in either DT or EBBR that
specifies exactly what is expected when using the UEFI boot path.

Does Monday 15:30BST work for a call?

g.


IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the contents to any other person, use it for any purpose, or store or
copy the information in any medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

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

[Grant Likely]

On 09/09/2020 09:38, Ard Biesheuvel wrote:

On Tue, 8 Sep 2020 at 09:39, Heinrich Schuchardt  wrote:


On 07.09.20 16:56, Grant Likely wrote:



On 07/09/2020 15:55, Daniel Thompson wrote:

On Mon, Sep 07, 2020 at 03:22:22PM +0100, Grant Likely wrote:

I've not heard back, and I've got a conflict this afternoon. I'm going
to resched for later in the week. Going to aim for Wednesday.


Are you trying the schedule a full EBBR meeting or just a discussion
about this thread?


Only about this thread. The next EBBR meeting will be next week Monday.

g.



Wednesday 17:30 UTC+2 would be fine for me.


Today at 17:30 UTC+2 it is. Here's a zoom meeting:



Join Zoom Meeting
https://armltd.zoom.us/j/93820204268?pwd=S01QYzhEM25XRkw3WWlRdXV1L3BuZz09=msft

Meeting ID: 938 2020 4268
Passcode: 616751
One tap mobile
+14086380968,,93820204268#,,0#,,616751# US (San Jose)
+16465189805,,93820204268#,,0#,,616751# 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: 938 2020 4268
Passcode: 616751
Find your local number: https://armltd.zoom.us/u/ab1GCAjvb8

Join by SIP
93820204...@zoomcrc.com

Join by H.323
162.255.37.11 (US West)
162.255.36.11 (US East)
115.114.131.7 (India Mumbai)
115.114.115.7 (India Hyderabad)
213.19.144.110 (Amsterdam Netherlands)
213.244.140.110 (Germany)
103.122.166.55 (Australia)
209.9.211.110 (Hong Kong SAR)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
207.226.132.110 (Japan)
Meeting ID: 938 2020 4268
Passcode: 616751
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

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

[Grant Likely]

On 07/09/2020 15:55, Daniel Thompson wrote:

On Mon, Sep 07, 2020 at 03:22:22PM +0100, Grant Likely wrote:

I've not heard back, and I've got a conflict this afternoon. I'm going
to resched for later in the week. Going to aim for Wednesday.


Are you trying the schedule a full EBBR meeting or just a discussion
about this thread?


Only about this thread. The next EBBR meeting will be next week Monday.

g.




Daniel.




g.

On 02/09/2020 13:58, Grant Likely wrote:



On 02/09/2020 07:52, Ard Biesheuvel wrote:

On Wed, 2 Sep 2020 at 09:48, Heinrich Schuchardt 
wrote:


On 9/1/20 10:51 AM, Ard Biesheuvel wrote:

On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt
 wrote:


On 8/31/20 9:01 PM, Ard Biesheuvel wrote:

On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt
 wrote:


Closes: #52

The no-map property of the /reserved-memory DT node is used by
Linux to
signal that a memory region shall not be mapped and that
speculative access
shall not be permitted.

The memory map returned by GetMemoryMap() does not have a flag
corresponding to no-map. So the closest thing we can do is not to
include
no-map reserved memory into the map returned by GetMemoryMap().



Dear Ard,

thanks for reviewing.



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


Do you have an example of a no-map /reserved-memory node used in
Linux?



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


Hello Ard,

I found the following compatibility strings for no-map areas in the
Linux device trees:

compatible = "shared-dma-pool"
compatible = "qcom,rmtfs-mem"
compatible = "qcom,cmd-db"

If Linux simply ignores the no-map property from the device-tree when
booting via UEFI and in UEFI we simply map those areas as reserved,
there is a conceptual gap as you already stated in a separate mail.



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

In other words, today we just assume that the /reserved-memory node
and the EFI memory map do not contradict each other, but we have no
definition or explicit requirement anywhere what that actually means.


Yeah, we need to clean this up and make it consistent. Would like to
have a call about this and look at some examples before trying to draft
the requirement. We probably need something in either DT or EBBR that
specifies exactly what is expected when using the UEFI boot path.

Does Monday 15:30BST work for a call?

g.


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

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

[Grant Likely]

I've not heard back, and I've got a conflict this afternoon. I'm going
to resched for later in the week. Going to aim for Wednesday.

g.

On 02/09/2020 13:58, Grant Likely wrote:



On 02/09/2020 07:52, Ard Biesheuvel wrote:

On Wed, 2 Sep 2020 at 09:48, Heinrich Schuchardt 
wrote:


On 9/1/20 10:51 AM, Ard Biesheuvel wrote:

On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt
 wrote:


On 8/31/20 9:01 PM, Ard Biesheuvel wrote:

On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt
 wrote:


Closes: #52

The no-map property of the /reserved-memory DT node is used by
Linux to
signal that a memory region shall not be mapped and that
speculative access
shall not be permitted.

The memory map returned by GetMemoryMap() does not have a flag
corresponding to no-map. So the closest thing we can do is not to
include
no-map reserved memory into the map returned by GetMemoryMap().



Dear Ard,

thanks for reviewing.



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


Do you have an example of a no-map /reserved-memory node used in
Linux?



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


Hello Ard,

I found the following compatibility strings for no-map areas in the
Linux device trees:

compatible = "shared-dma-pool"
compatible = "qcom,rmtfs-mem"
compatible = "qcom,cmd-db"

If Linux simply ignores the no-map property from the device-tree when
booting via UEFI and in UEFI we simply map those areas as reserved,
there is a conceptual gap as you already stated in a separate mail.



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

In other words, today we just assume that the /reserved-memory node
and the EFI memory map do not contradict each other, but we have no
definition or explicit requirement anywhere what that actually means.


Yeah, we need to clean this up and make it consistent. Would like to
have a call about this and look at some examples before trying to draft
the requirement. We probably need something in either DT or EBBR that
specifies exactly what is expected when using the UEFI boot path.

Does Monday 15:30BST work for a call?

g.


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture