Instead of masking out GetVariable() when SetVariable() isn't available
during runtime services, simplify the requirements without losing the
ability to read variables by using the RuntimeServicesSupported variable
from UEFI v2.8.1 (unreleased); Mantis issue 1961.
Peter Jones's earlier patch also specified a Capsule-on-Disk format for
updating variables that the OS could store in the ESP. I've not included
that specification in this patch as it is logically a separate feature.
It may reappear in a separate patch at a later date, or it may get
proposed for inclusion in the UEFI spec proper.
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
Cc: Peter Jones <pjones(a)redhat.com>
---
source/chapter2-uefi.rst | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 379f0ca..4f74d43 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -201,14 +201,15 @@ variables stored on shared media. [#OPTEESupplicant]_
If a platform does not implement modifying non-volatile variables with
SetVariable() after ExitBootServices(),
-then it must not provide any variable operations after ExitBootServices().
-Firmware shall return EFI_UNSUPPORTED for any call to GetVariable(),
-GetNextVariableName() and SetVariable().
-Firmware shall not emulated non-volatile variables using volatile RAM cache.
+then firmware shall return EFI_UNSUPPORTED for any call to SetVariable(),
+and must advertise that SetVariable() isn't available during runtime services
+via the "RuntimeServicesSupported" variable as defined in UEFI version 2.8.1.
+EFI applications can read RuntimeServicesSupported to determine if calls
+to SetVariable() need to be performed before calling ExitBootServices().
-.. note:: The behaviour when SetVariable() is not supported during runtime
- services is still under discussion and subject to change.
- Do not make any firmware implementation decisions based on this text yet.
+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.
.. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem
regarding secure storage.
@@ -216,5 +217,7 @@ Firmware shall not emulated non-volatile variables using volatile RAM cache.
storage operations on behalf of OP-TEE.
The same solution may be applicable to solving the UEFI non-volatile
variable problem, but it requires additional OS support to work.
+ Regardless, EBBR compliance does not require SetVariable() support
+ during runtime services.
https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage…
--
2.13.0
On Fri, Dec 7, 2018 at 9:16 AM Mark Brown <broonie(a)kernel.org> wrote:
>
> On Fri, Dec 07, 2018 at 08:57:06AM -0600, Rob Herring wrote:
> > On Thu, Dec 6, 2018 at 2:07 PM Mark Brown <broonie(a)kernel.org> wrote:
>
> > > The issues with the existing install_dtbs sounded unrelated to this.
>
> > Maybe, what are the issues? We can't change the source layout
> > transparently if dtbs_install is not being used.
>
> I thought that was the thing with adding -@ so overlays could be used?
I don't think so as that is during building, not install. Any user can
set '-@' with 'make DTC_FLAGS="-@" ...' already. The issue with that
was changing the default globally and no way to set per platform. Now
that I think about, moving the sources to subdirs may allow setting
DTC_FLAGS per subdir which may be good enough.
Rob
On Thu, Dec 6, 2018 at 2:07 PM Mark Brown <broonie(a)kernel.org> wrote:
>
> On Thu, Dec 06, 2018 at 01:06:43PM -0600, Rob Herring wrote:
> > On Thu, Dec 6, 2018 at 7:32 AM Andreas Färber <afaerber(a)suse.de> wrote:
>
> > > I'd be okay with distinguishing source vs. install location. Due to the
> > > issue I mention below (and more) we can't use install_dtbs for openSUSE
> > > and had to reimplement it, which we'd need to (and can) adjust.
>
> > What would be needed for dtbs_install to work? arm64 needs to support
> > a flat install? If it doesn't work for Debian or openSUSE, I'm not
> > sure why we have it. So I'd like to make it work.
>
> Correct me if I'm wrong but as far as the flat vs directory thing goes
> isn't the issue that this winds up being a rename for an existing 32 bit
> system? If you just install the dtbs in the default location then a
> bootloader or whatever that is hard coded to look for foo-bar.dtb won't
> see the new foo/foo-bar.dtb (or whatever) and will continue to use the
> old binary. It's not the fact that that it's in a directory, it's the
> fact that the bootloader sees the name it needs to look for change (if
> it's looking on a filesystem at all).
Correct.
> This isn't a problem for arm64 as
> the location isn't changing, it's used directories from day one.
The kernel may have used directories, but that's not what the distros
did according to Andreas:
> We already had that discussion for arm64 because Debian chose to ignore
> the kernel-installed subdirectories and installed .dtb files into a flat
> directory, which collided with openSUSE sticking to the kernel choice.
So are the distros different or who changed to align? That's not clear
from this thread.
> The issues with the existing install_dtbs sounded unrelated to this.
Maybe, what are the issues? We can't change the source layout
transparently if dtbs_install is not being used.
My question here is whether a flat install is useful on arm64. We can
either have a kconfig variable that arm32 sets to do flat installs or
it could be some command line make variable and then any user can pick
what they want for any arch.
Rob
On Thu, Dec 6, 2018 at 12:07 PM Mark Brown <broonie(a)kernel.org> wrote:
>
> On Thu, Dec 06, 2018 at 01:06:43PM -0600, Rob Herring wrote:
> > On Thu, Dec 6, 2018 at 7:32 AM Andreas Färber <afaerber(a)suse.de> wrote:
>
> > > I'd be okay with distinguishing source vs. install location. Due to the
> > > issue I mention below (and more) we can't use install_dtbs for openSUSE
> > > and had to reimplement it, which we'd need to (and can) adjust.
>
> > What would be needed for dtbs_install to work? arm64 needs to support
> > a flat install? If it doesn't work for Debian or openSUSE, I'm not
> > sure why we have it. So I'd like to make it work.
>
> Correct me if I'm wrong but as far as the flat vs directory thing goes
> isn't the issue that this winds up being a rename for an existing 32 bit
> system? If you just install the dtbs in the default location then a
> bootloader or whatever that is hard coded to look for foo-bar.dtb won't
> see the new foo/foo-bar.dtb (or whatever) and will continue to use the
> old binary. It's not the fact that that it's in a directory, it's the
> fact that the bootloader sees the name it needs to look for change (if
> it's looking on a filesystem at all). This isn't a problem for arm64 as
> the location isn't changing, it's used directories from day one.
Yeah, install needs to remain flat even if the dts files move into
subdirectories. It will be painful for everybody if the install
location moves.
> The issues with the existing install_dtbs sounded unrelated to this.
Agreed.
-Olof
Rob,
Am 04.12.18 um 19:36 schrieb Rob Herring:
> I've put together a script to move the dts files and update the
> makefiles. It doesn't handle files not following a common prefix which
> isn't many and some includes within the dts files will need some fixups
> by hand.
>
> MAINTAINERS will also need updating.
>
> A few questions:
>
> Do we want to move absolutely everything to subdirs?
This refactoring is a terrible idea!
While it would've been nice to have more structure from the start,
bootloaders like U-Boot expect a flat structure for arm .dtb files now.
If you start installing them into subdirs instead, they won't find the
files anymore under the hardcoded name.
Doing this only for new platforms would be much less invasive and allow
to prepare bootloaders accordingly. Alternatively, white-list which ones
are safe to move around. But don't just script a refactoring because it
looks nicer in the source tree, without testing what side effects this
can have for board/distro users of the compiled files in practice.
We already had that discussion for arm64 because Debian chose to ignore
the kernel-installed subdirectories and installed .dtb files into a flat
directory, which collided with openSUSE sticking to the kernel choice.
This topic becomes even more important with EBBR: There is neither a
mechanism in place to sync .dts files into U-Boot or EDK2 source trees,
nor are capsule updates implemented in U-Boot for easily deploying such
bootloaders with new .dts sources or paths yet. And I can assure you
that just getting users to dd the right bootloader can be difficult...
Since DT forward and backward compatibility is often being neglected,
for example with optional properties or renamed compatibles that break
booting with previous drivers, new kernel versions often need updated
Device Trees to make use of new/enhanced drivers. Therefore it is
unfortunately often enough a necessity to load newer kernel-based .dtb
files matching the kernel (as opposed to the dream of kernel-independent
hardware descriptions) when working with the latest -rc or -next kernels
at least. For examples of DTs needing updates, look no further than
Linaro's 96boards - in case of hikey960/EDK2 GRUB is another layer where
.dtb paths may be hardcoded, ditto for arm; and Armada was an example
where the upstream bindings for the network IP changed incompatibly.
DT overlays are another topic that is not making any progress upstream
according to the ELCE BoF, so beyond the Raspberry Pi the only known
working way to apply them is to write a U-Boot boot.scr script, which
can either reuse $fdtcontroladdr DT or use the filename $fdtfile or
hardcode one, the latter two of which would break with your renaming.
So expect people to be using .dtb files, expect them to be affected by
file movements to subdirectories here, and don't expect each user to
understand or be able to fix things themselves if they fall apart as
result of your changes and they suddenly no longer have Ethernet/Wifi.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
I don't have an agenda for today. The one remaining blocker for 1.0 release is still open. I had hoped to get it written this past week, but haven't got it done yet.
I did have a very productive meeting with Qualcomm last week. They have good feedback on the v0.6 draft, but I'll let them speak for themselves.
I'm cancelling todays meeting, but I'll open the call anyway simply because it is so late that I'm sending this email. If you want to chat, feel free to dial in.
If you do have a topic you want to discuss next week, please email me in the next week.
g.
Any agenda items for todays call? Here is what I have so far:
- Updates
- SetVariable()
- Compatibility statement
- EBBR Plugfest?
- Other Business
Next week (15 Nov) we won't have a call, nor will there be a call on 29 Nov.
g.
The UEFI spec already specifies the image format. No need to specify in
EBBR.
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter2-uefi.rst | 6 ------
1 file changed, 6 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 177a81c..f89ac04 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -73,12 +73,6 @@ that virtual addresses must equal physical addresses.
The default RAM allocated attribute must be EFI_MEMORY_WB.
-UEFI Loaded Images
-------------------
-
-UEFI loaded images for AArch64 must be in 64-bit PE/COFF format and must
-contain only A64 code.
-
Configuration Tables
--------------------
--
2.13.0
This weeks meeting will need to be short as I've got a conflict at the
top of the hour. We'll do a quick round table, and then I'd like to talk
a bit more about the SetVariable() proposal made by Peter J. I
personally am a bit confused as to the scope of the proposal.
Agenda 01/11/2018:
- Release progress
- Round table
- SetVariable() proposal from Peter Jones
Anyone is welcome to join. Feel free to pass this invitation along. Let
me know if anyone has trouble dialling/connecting to the WebEx bridge.
Time: Every Thursday at 16:30-17:30 BST (8:30 PDT, 23:30 CST)
g.
---
Grant Likely's Personal Room
https://arm-onsite.webex.com/meet/gralik01
Access code: 809 053 990
Join by phone
1-408-792-6300 Call-in toll number (US/Canada)
1-877-668-4490 Call-in toll-free number (US/Canada)
44-203-478-5285 Call-in toll number (UK)
08-002061177 Call-in toll-free (UK)
Access code: 809 053 990
More access numbers:
https://arm-onsite.webex.com/cmp3300/webcomponents/widget/globalcallin/glob…https://www.webex.com/pdf/tollfree_restrictions.pdf
Hi everyone,
I've tagged v0.7 of EBBR for review. Please feel free to circulate and
solicit feedback. It will certainly be discussed at ELC Europe next week
in Edinburgh.
https://github.com/ARM-software/ebbr/releases/tag/v0.7
Thanks,
g.
ResetSystem() was over-specified in the document. UEFI already documents
the behaviour of ResetSystem() sufficiently. Add notes on expected
behaviour when platform specific or standard interface methods are
available.
Resolves: #29
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter2-uefi.rst | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 0cbddff..8a3ff1a 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -175,23 +175,16 @@ and the OS must use a device driver to control the RTC.
UEFI Reset and Shutdown
-----------------------
-The UEFI Runtime service ResetSystem() must implement the following commands,
-for purposes of power management and system control.
-
-- EfiResetCold()
-- EfiResetShutdown()
- * EfiResetShutdown must not reboot the system.
-
-If firmware updates are supported through the Runtime Service of
-UpdateCapsule(), then ResetSystem() might need to support the following
-command:
-
-- EfiWarmReset()
-
-.. note:: On platforms implementing the Power State Coordination Interface
- specification [PSCI]_, it is still required that EBBR compliant
- Operating Systems calls to reset the system will go via Runtime Services
- and not directly to PSCI.
+ResetSystem() is required to be implemented in boot services, but it is
+optional for runtime services.
+During runtime services, the operating system should first attempt to
+use ResetSystem() to reset the system.
+If ResetSystem() returns EFI_UNSUPPORTED, then the OS may fall back to
+an architecture or platform specific mechanism.
+
+On AArch64 platforms implementing [PSCI]_,
+if ResetSystem() is not implemented then the Operating System should fall
+back to making a PSCI call to reset or shutdown the system.
Runtime Variable Access
-----------------------
--
2.13.0
For those of you dialing into the weekly EBBR call, the dial in details
have changed (see below). We'll use WebEx instead of Skype for Business
from here on.
Agenda 27/09/2018:
• YVR18 Recap
• Review meeting time
• Release schedule
• Get/SetVariable – once more with feeling
• reference platforms/qemu
Anyone is welcome to join. Feel free to pass this invitation along. Let
me know if anyone has trouble dialling/connecting to the SfB bridge.
Time: Every Thursday at 16:30-17:30 BST (8:30 PDT, 23:30 CST)
[1]
https://lists.linaro.org/pipermail/boot-architecture/2018-April/000419.html
g.
---
Grant Likely's Personal Room
https://arm-onsite.webex.com/meet/gralik01
Access code: 809 053 990
Join by phone
1-408-792-6300 Call-in toll number (US/Canada)
1-877-668-4490 Call-in toll-free number (US/Canada)
44-203-478-5285 Call-in toll number (UK)
08-002061177 Call-in toll-free (UK)
Access code: 809 053 990
More access numbers:
https://arm-onsite.webex.com/cmp3300/webcomponents/widget/globalcallin/glob…https://www.webex.com/pdf/tollfree_restrictions.pdf
Hello,
Can we add a discussion in upcoming meetings about the participation
of SMMU in the booting procedure?
In the past there's been a number of proposals on how to mitigate
attacks, were a rogue PCI card is inserted into the system.
Some of them include shutting down external DMA ports until the OS
explicitly powers them up or blocking DMA using BME bit etc
Keeping in mind this will enhance the security of devices would it
make sense to include it as a 'MUST' if the hardware is present or a
recommendation would be enough?
If we enable if a number of questions will rise as well such as, What
happens if the SMMU is already configured? Should the OS reconfigure
it ?
/Ilias
On 27/09/2018 22:19, Mark Brown wrote:
> On Thu, Sep 27, 2018 at 04:25:29PM +0100, Grant Likely wrote:
>
>> Anyone is welcome to join. Feel free to pass this invitation along. Let me
>> know if anyone has trouble dialling/connecting to the SfB bridge.
>
> Highlighting in case anyone else makes the same mistake I did today: the
> dial in details have changed, if you've copied them into your personal
> calendar or similar you'll need to update!
Oops! The current calendar invite is about to expire, and I'm going to
try and rearrange the meeting to be at the top of the hour (need to
coordinate with Linaro LEDGE SC meeting). There will be a new invite in
the near future.
Mark, I also maintain a regular calendar invite. Would you like me to
add you to that?
g.
>
>> Time: Every Thursday at 16:30-17:30 BST (8:30 PDT, 23:30 CST)
>>
>> [1]
>> https://lists.linaro.org/pipermail/boot-architecture/2018-April/000419.html
>>
>> g.
>>
>> ---
>> Grant Likely's Personal Room
>> https://arm-onsite.webex.com/meet/gralik01
>> Access code: 809 053 990
>>
>> Join by phone
>> 1-408-792-6300 Call-in toll number (US/Canada)
>> 1-877-668-4490 Call-in toll-free number (US/Canada)
>> 44-203-478-5285 Call-in toll number (UK)
>> 08-002061177 Call-in toll-free (UK)
>> Access code: 809 053 990
>>
>> More access numbers:
>> https://arm-onsite.webex.com/cmp3300/webcomponents/widget/globalcallin/glob…
>> https://www.webex.com/pdf/tollfree_restrictions.pdf
Hi all, There is a face to face EBBR meeting scheduled at Linaro Connect
YVR18. I’m setting up this Skype dial-in for those who won’t be on-site.
Time: Tuesday 18 Sept 2018 at 10:00-11:00 PDT
.........................................................................................................................................
Join online meeting
https://meet.lync.com/armh/grant.likely/97ATLDZ1
Join by Phone
+442033215213 (Dial-in Number) English (United Kingdom)
Find a local number
https://dialin.lync.com/7bdb65cd-97d0-44fe-bc03-bf8072eadc33
Conference ID:
14562158
Forgot your dial-in PIN?
https://dialin.lync.com/7bdb65cd-97d0-44fe-bc03-bf8072eadc33
.........................................................................................................................................
Hi all,
I'd like to use today's EBBR meeting to discuss the demo for Linaro
connect. It would be great if we can have several distro images and show
them booting on multiple boards without fuss. Let's coordinate on which
boards are feasable candidates to use and which OS images should be used.
Talk to you at 16:30BST.
Cheers,
g.
---
Every Thursday at 16:30 UTC/BST, 8:30 PST/PDT, 00:30 CST
(following UTC/BST daylight savings time shifts)
Online meeting: https://meet.lync.com/armh/grant.likely/YBY93TIK
Skype Web App: https://meet.lync.com/armh/grant.likely/YBY93TIK?sl=1
Phone +44 2033215213,, 4664465#
Find a local number:
https://dialin.lync.com/7bdb65cd-97d0-44fe-bc03-bf8072eadc33
Conference ID: 4664465
On 30/08/2018 15:19, Mark Brown wrote:
> On Thu, Aug 30, 2018 at 03:14:47PM +0100, Grant Likely wrote:
>
>> Online meeting: https://meet.lync.com/armh/grant.likely/YBY93TIK
>> Skype Web App: https://meet.lync.com/armh/grant.likely/YBY93TIK?sl=1
>
> I keep meaning to mention - these links never seem to work for me, I
> always have to join via phone. Not sure if it's just me or not.
>
Yeah, skype4business is a pain on Linux. Sadly it's the tool Arm pays
for. I've been meaning to see if Arm will supply a Bluejeans account for
these meetings.
Dial-in always works. You could also try the Skype4Business Android or
iOS apps.
g.
Hi all,
Today's EBBR meeting is cancelled due to conflicts with other meetings. We'll meet again 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.
On 03/08/2018 17:40, Mark Brown wrote:
> On Fri, Aug 03, 2018 at 05:34:05PM +0100, Grant Likely wrote:
>
>> Anyone familiar with Open Source Firmware Conference coming up in
>> September? Is this just a PC firmware thing, or do we have some U-Boot
>> involvement?
>>
>> https://osfc.io/
>
> Their CFP lists LinuxBoot, coreboot, U-Boot, TianoCore and ARM Trusted
> Firmware.
Their CFP lists that, but it seems to be mostly Coreboot and LinuxBoot
folks. I was on the Linuxboot call today, and they don't seem to have
much contact with people from U-Boot or other 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.
Anyone familiar with Open Source Firmware Conference coming up in
September? Is this just a PC firmware thing, or do we have some U-Boot
involvement?
https://osfc.io/
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.
Tom,
thanks, I appreciate all of your hard work, the code base looks good..
David
On Thu, 26 Jul 2018 at 16:11 Tom Rini <trini(a)konsulko.com> wrote:
> On Thu, Jul 26, 2018 at 01:55:51PM +0100, Peter Robinson wrote:
> > On Thu, Jul 26, 2018 at 1:46 PM, David Rusling <david.rusling(a)linaro.org>
> wrote:
> > > Peter,
> > > thanks, that was one explanation that I hadn't thought of (32b = 32
> > > bits). Really helpful, onwards and upwards...
> >
> > FYI they work fine 32 and 64 bits on both the 3B and 3B+ for me, only
> > currently tested 64 bit with uefi but they work fine for me, plus a
> > bunch of other 96boards.
>
> A Pi 3B is also in my CI loop (32bit then 64bit) so our (U-Boot's)
> test.py bits run on it reliably or I start yelling at people :)
>
> --
> Tom
>
--
David A Rusling
CTO, Linaro
https://linaro.org
Remove the link to the draft index.rst file and replace it with a link
to the releases page. The link to the index.rst doesn't make sense
anymore now that the text is broken out into one file per chapter.
Resolves: #24
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
README.rst | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/README.rst b/README.rst
index f20ddbf..db2aa4a 100644
--- a/README.rst
+++ b/README.rst
@@ -13,16 +13,9 @@ expected in September 2018. You can find the current draft text in this
repository, but be aware that everything in the draft text is subject to
change before an official v1.0 release is published.
-This repository can be used to build a .pdf of the document, and soon there
-will be a CI loop generating a .pdf for each commit. In the mean time you
-can look at the source text directly here:
+Released EBBR PDFs can be found here:
-`EBBR Draft Text`_
-
-GitHub does a good job of rendering the reStructuredText markup into
-something readable.
-
-.. _`EBBR Draft Text`: source/index.rst
+https://github.com/ARM-software/ebbr/releases
Build Instructions
==================
--
2.13.0
Add the conference call details to the CONTRIBUTING file so it is easy to find.
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
CONTRIBUTING.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
index 25ad49d..2b69bf5 100644
--- a/CONTRIBUTING.rst
+++ b/CONTRIBUTING.rst
@@ -20,6 +20,16 @@ Past discussions can be found in the boot-architecture-archive_.
We use the IRC channel `#ebbr`_ on OFTC_.
+There is a weekly conference call to discuss EBBR topics every Thursday
+at 16:30 UTC/BST, 8:30 PST/PDT, 00:30 CST
+(following UTC/BST daylight savings time shifts):
+
+- Online meeting: https://meet.lync.com/armh/grant.likely/YBY93TIK
+- Skype Web App: https://meet.lync.com/armh/grant.likely/YBY93TIK?sl=1
+- Phone: +44 2033215213,, 4664465#
+- Find a local number: https://dialin.lync.com/7bdb65cd-97d0-44fe-bc03-bf8072eadc33
+- Conference ID: 4664465
+
DCO Attestation
---------------
--
2.13.0
