Hi all,
I'm considering doing a quick point-release for EBBR to address the change to RuntimeServicesSupported in UEFI 2.8 Errata A. From 2.8final to 2.8_A, RuntimeServicesSupported changed from being a variable to data in a system table entry. U-Boot and Linux have been updated to the UEFI method. EBBR needs to be changed to match.
There are patches on this list under discussion now. Once that is complete and the patches merged, how does everyone feel about an EBBR v1.0.1 release before the end of May?
At this moment, the v1.0.1 changes would include:
e47952b (HEAD -> master, glikely/master) Specify details of how a DTB is passed to the OS c155e96 Update spec to address UEFI 2.8 Errata A 7fad894 (origin/master, origin/HEAD) Fix all UEFI references to be the same version 498cad2 trivial: Fix typo in chater 3 title 2c40029 Merge pull request #43 from orangecms/link-to-linux-doc 1e51a1e Update link to Linux docs which changed to rst be7ddfa Update CONTRIBUTING.rst 763aed0 Update CONTRIBUTING.rst
All of the above can be found queued up at http://github.com/glikely/ebbr
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 05.05.20 17:44, Grant Likely wrote:
Hi all,
I'm considering doing a quick point-release for EBBR to address the change to RuntimeServicesSupported in UEFI 2.8 Errata A. From 2.8final to 2.8_A, RuntimeServicesSupported changed from being a variable to data in a system table entry. U-Boot and Linux have been updated to the UEFI method. EBBR needs to be changed to match.
There are patches on this list under discussion now. Once that is complete and the patches merged, how does everyone feel about an EBBR v1.0.1 release before the end of May?
At this moment, the v1.0.1 changes would include:
e47952b (HEAD -> master, glikely/master) Specify details of how a DTB is passed to the OS
Thanks for updating the patch.
c155e96 Update spec to address UEFI 2.8 Errata A
The patch looks correct. This is what I stumbled upon looking at the rest of the runtime chapter:
The 'Runtime Variable Access' sub-chapter mentions only SetVariable() as optional while the table above it specifies all variable services as optional. Could we start the sub-chapter with a sentence
"All variable services at runtime are optional."
to avoid misunderstandings.
The `RuntimeServicesSupported` value flag in the `EFI_RT_PROPERTIES_TABLE` should be set correctly for all runtime services. Mentioning this requirement specifically for SetVariable() might be misleading.
There is a capitalization typo in the chapter:
%s/e.g., If/E.g., if/
Best regards
Heinrich
7fad894 (origin/master, origin/HEAD) Fix all UEFI references to be the same version 498cad2 trivial: Fix typo in chater 3 title 2c40029 Merge pull request #43 from orangecms/link-to-linux-doc 1e51a1e Update link to Linux docs which changed to rst be7ddfa Update CONTRIBUTING.rst 763aed0 Update CONTRIBUTING.rst
All of the above can be found queued up at http://github.com/glikely/ebbr
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
On 05/05/2020 17:41, Heinrich Schuchardt wrote:
On 05.05.20 17:44, Grant Likely wrote:
Hi all,
I'm considering doing a quick point-release for EBBR to address the change to RuntimeServicesSupported in UEFI 2.8 Errata A. From 2.8final to 2.8_A, RuntimeServicesSupported changed from being a variable to data in a system table entry. U-Boot and Linux have been updated to the UEFI method. EBBR needs to be changed to match.
There are patches on this list under discussion now. Once that is complete and the patches merged, how does everyone feel about an EBBR v1.0.1 release before the end of May?
At this moment, the v1.0.1 changes would include:
e47952b (HEAD -> master, glikely/master) Specify details of how a DTB is passed to the OS
Thanks for updating the patch.
c155e96 Update spec to address UEFI 2.8 Errata A
The patch looks correct. This is what I stumbled upon looking at the rest of the runtime chapter:
The 'Runtime Variable Access' sub-chapter mentions only SetVariable() as optional while the table above it specifies all variable services as optional. Could we start the sub-chapter with a sentence
"All variable services at runtime are optional."
to avoid misunderstandings.
The `RuntimeServicesSupported` value flag in the `EFI_RT_PROPERTIES_TABLE` should be set correctly for all runtime services. Mentioning this requirement specifically for SetVariable() might be misleading.
This is a bit tricky. In past conversations I was pushing toward making GetVariable()/GetNextVariableName() required and only SetVariable() optional, but there wasn't concensus at that time. The text as it stands it kind of a mix on whether or not GetVariable() is required or merely recommended.
For the point release that we do soon, I could tidy up the text a bit, but I'd like some thoughts on where EBBR should go for the next major revision. GetVariable() should be straight forward to implement GetVariable at runtime by using a RAM-cached value. I don't believe any work has been done to support that in U-Boot.
Thoughts?
There is a capitalization typo in the chapter:
%s/e.g., If/E.g., if/
Fixed and committed as a trivial fix.
g.
Best regards
Heinrich
7fad894 (origin/master, origin/HEAD) Fix all UEFI references to be the same version 498cad2 trivial: Fix typo in chater 3 title 2c40029 Merge pull request #43 from orangecms/link-to-linux-doc 1e51a1e Update link to Linux docs which changed to rst be7ddfa Update CONTRIBUTING.rst 763aed0 Update CONTRIBUTING.rst
All of the above can be found queued up at http://github.com/glikely/ebbr
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
On 5/6/20 3:18 PM, Grant Likely wrote:
On 05/05/2020 17:41, Heinrich Schuchardt wrote:
On 05.05.20 17:44, Grant Likely wrote:
Hi all,
I'm considering doing a quick point-release for EBBR to address the change to RuntimeServicesSupported in UEFI 2.8 Errata A. From 2.8final to 2.8_A, RuntimeServicesSupported changed from being a variable to data in a system table entry. U-Boot and Linux have been updated to the UEFI method. EBBR needs to be changed to match.
There are patches on this list under discussion now. Once that is complete and the patches merged, how does everyone feel about an EBBR v1.0.1 release before the end of May?
At this moment, the v1.0.1 changes would include:
e47952b (HEAD -> master, glikely/master) Specify details of how a DTB is passed to the OS
Thanks for updating the patch.
c155e96 Update spec to address UEFI 2.8 Errata A
The patch looks correct. This is what I stumbled upon looking at the rest of the runtime chapter:
The 'Runtime Variable Access' sub-chapter mentions only SetVariable() as optional while the table above it specifies all variable services as optional. Could we start the sub-chapter with a sentence
"All variable services at runtime are optional."
to avoid misunderstandings.
The `RuntimeServicesSupported` value flag in the `EFI_RT_PROPERTIES_TABLE` should be set correctly for all runtime services. Mentioning this requirement specifically for SetVariable() might be misleading.
This is a bit tricky. In past conversations I was pushing toward making GetVariable()/GetNextVariableName() required and only SetVariable() optional, but there wasn't concensus at that time. The text as it stands it kind of a mix on whether or not GetVariable() is required or merely recommended.
For the point release that we do soon, I could tidy up the text a bit, but I'd like some thoughts on where EBBR should go for the next major revision. GetVariable() should be straight forward to implement GetVariable at runtime by using a RAM-cached value. I don't believe any work has been done to support that in U-Boot.
See this patch series that is not yet merged: https://patchwork.ozlabs.org/project/uboot/list/?series=167069
In the series non-volatile variables are persisted in a file on the EFI system partition.
With the patch series SetVariable() is enabled at runtime. We would need a systemd service for updating the variables in the file store before a reboot but that would not be really conforming to the UEFI spec which mandates immediate update of the store.
For the other variable services the patch series provides a compliant solution.
Ilias Apalodimas has a draft patch series for using OP-TEE and MM for managing variables. But storage in the RPMB partition of an eMMC device would only work at boottime. Just what you described at last years Embedded Linux conference (https://www.youtube.com/watch?v=VnsF3uRZzNk).
Takahiro Akashi last year presented alternative patches that would enable reading variables at runtime. He recently suggested to use capsule updates to update variables and has submitted patches for capsule updates (https://patchwork.ozlabs.org/project/uboot/list/?series=172907).
If we do not have SetVariable() at runtime, I do not see much value in QueryVariableInfo(). So we shouldn't make that service compulsory.
Best regards
Heinrich
Thoughts?
There is a capitalization typo in the chapter:
%s/e.g., If/E.g., if/
Fixed and committed as a trivial fix.
g.
Best regards
Heinrich
7fad894 (origin/master, origin/HEAD) Fix all UEFI references to be the same version 498cad2 trivial: Fix typo in chater 3 title 2c40029 Merge pull request #43 from orangecms/link-to-linux-doc 1e51a1e Update link to Linux docs which changed to rst be7ddfa Update CONTRIBUTING.rst 763aed0 Update CONTRIBUTING.rst
All of the above can be found queued up at http://github.com/glikely/ebbr
On Wed, May 06, 2020 at 09:09:45PM +0200, Heinrich Schuchardt wrote:
On 5/6/20 3:18 PM, Grant Likely wrote:
[...]
For the other variable services the patch series provides a compliant solution.
Ilias Apalodimas has a draft patch series for using OP-TEE and MM for managing variables. But storage in the RPMB partition of an eMMC device would only work at boottime. Just what you described at last years Embedded Linux conference (https://www.youtube.com/watch?v=VnsF3uRZzNk).
Takahiro Akashi last year presented alternative patches that would enable reading variables at runtime. He recently suggested to use capsule updates to update variables and has submitted patches for capsule updates (https://patchwork.ozlabs.org/project/uboot/list/?series=172907).
FYI I just posted that https://lists.denx.de/pipermail/u-boot/2020-May/410772.html As Heinrich says, it only works on boottime for now, but I *think* (and I might be horribly wrong), that getting runtime variables to work would be possible.
If we do not have SetVariable() at runtime, I do not see much value in QueryVariableInfo(). So we shouldn't make that service compulsory.
Best regards
Heinrich
Thoughts?
There is a capitalization typo in the chapter:
%s/e.g., If/E.g., if/
Fixed and committed as a trivial fix.
g.
Best regards
Heinrich
7fad894 (origin/master, origin/HEAD) Fix all UEFI references to be the same version 498cad2 trivial: Fix typo in chater 3 title 2c40029 Merge pull request #43 from orangecms/link-to-linux-doc 1e51a1e Update link to Linux docs which changed to rst be7ddfa Update CONTRIBUTING.rst 763aed0 Update CONTRIBUTING.rst
All of the above can be found queued up at http://github.com/glikely/ebbr
On Wed, May 06, 2020 at 09:09:45PM +0200, Heinrich Schuchardt wrote:
On 5/6/20 3:18 PM, Grant Likely wrote:
On 05/05/2020 17:41, Heinrich Schuchardt wrote:
On 05.05.20 17:44, Grant Likely wrote:
Hi all,
I'm considering doing a quick point-release for EBBR to address the change to RuntimeServicesSupported in UEFI 2.8 Errata A. From 2.8final to 2.8_A, RuntimeServicesSupported changed from being a variable to data in a system table entry. U-Boot and Linux have been updated to the UEFI method. EBBR needs to be changed to match.
There are patches on this list under discussion now. Once that is complete and the patches merged, how does everyone feel about an EBBR v1.0.1 release before the end of May?
At this moment, the v1.0.1 changes would include:
e47952b (HEAD -> master, glikely/master) Specify details of how a DTB is passed to the OS
Thanks for updating the patch.
c155e96 Update spec to address UEFI 2.8 Errata A
The patch looks correct. This is what I stumbled upon looking at the rest of the runtime chapter:
The 'Runtime Variable Access' sub-chapter mentions only SetVariable() as optional while the table above it specifies all variable services as optional. Could we start the sub-chapter with a sentence
"All variable services at runtime are optional."
to avoid misunderstandings.
The `RuntimeServicesSupported` value flag in the `EFI_RT_PROPERTIES_TABLE` should be set correctly for all runtime services. Mentioning this requirement specifically for SetVariable() might be misleading.
This is a bit tricky. In past conversations I was pushing toward making GetVariable()/GetNextVariableName() required and only SetVariable() optional, but there wasn't concensus at that time. The text as it stands it kind of a mix on whether or not GetVariable() is required or merely recommended.
For the point release that we do soon, I could tidy up the text a bit, but I'd like some thoughts on where EBBR should go for the next major revision. GetVariable() should be straight forward to implement GetVariable at runtime by using a RAM-cached value. I don't believe any work has been done to support that in U-Boot.
See this patch series that is not yet merged: https://patchwork.ozlabs.org/project/uboot/list/?series=167069
In the series non-volatile variables are persisted in a file on the EFI system partition.
With the patch series SetVariable() is enabled at runtime. We would need a systemd service for updating the variables in the file store before a reboot but that would not be really conforming to the UEFI spec which mandates immediate update of the store.
For the other variable services the patch series provides a compliant solution.
Ilias Apalodimas has a draft patch series for using OP-TEE and MM for managing variables. But storage in the RPMB partition of an eMMC device would only work at boottime. Just what you described at last years Embedded Linux conference (https://www.youtube.com/watch?v=VnsF3uRZzNk).
Takahiro Akashi last year presented alternative patches that would enable reading variables at runtime.
Also via a kind of ram-cache, but I can agree to Heinrich's approach if UEFI variables are re-implemented from the scratch except that we don't have to stick to file system.
He recently suggested to use capsule updates to update variables and has submitted patches for capsule updates (https://patchwork.ozlabs.org/project/uboot/list/?series=172907).
Just for clarification, "variable updates" patch was included in RFC but later dropped in v1 as the discussions were immature.
Thanks, -Takahiro Akashi
If we do not have SetVariable() at runtime, I do not see much value in QueryVariableInfo(). So we shouldn't make that service compulsory.
Best regards
Heinrich
Thoughts?
There is a capitalization typo in the chapter:
%s/e.g., If/E.g., if/
Fixed and committed as a trivial fix.
g.
Best regards
Heinrich
7fad894 (origin/master, origin/HEAD) Fix all UEFI references to be the same version 498cad2 trivial: Fix typo in chater 3 title 2c40029 Merge pull request #43 from orangecms/link-to-linux-doc 1e51a1e Update link to Linux docs which changed to rst be7ddfa Update CONTRIBUTING.rst 763aed0 Update CONTRIBUTING.rst
All of the above can be found queued up at http://github.com/glikely/ebbr
On 06/05/2020 20:09, Heinrich Schuchardt wrote:
On 5/6/20 3:18 PM, Grant Likely wrote:
On 05/05/2020 17:41, Heinrich Schuchardt wrote:
On 05.05.20 17:44, Grant Likely wrote:
Hi all,
I'm considering doing a quick point-release for EBBR to address the change to RuntimeServicesSupported in UEFI 2.8 Errata A. From 2.8final to 2.8_A, RuntimeServicesSupported changed from being a variable to data in a system table entry. U-Boot and Linux have been updated to the UEFI method. EBBR needs to be changed to match.
There are patches on this list under discussion now. Once that is complete and the patches merged, how does everyone feel about an EBBR v1.0.1 release before the end of May?
At this moment, the v1.0.1 changes would include:
e47952b (HEAD -> master, glikely/master) Specify details of how a DTB is passed to the OS
Thanks for updating the patch.
c155e96 Update spec to address UEFI 2.8 Errata A
The patch looks correct. This is what I stumbled upon looking at the rest of the runtime chapter:
The 'Runtime Variable Access' sub-chapter mentions only SetVariable() as optional while the table above it specifies all variable services as optional. Could we start the sub-chapter with a sentence
"All variable services at runtime are optional."
to avoid misunderstandings.
The `RuntimeServicesSupported` value flag in the `EFI_RT_PROPERTIES_TABLE` should be set correctly for all runtime services. Mentioning this requirement specifically for SetVariable() might be misleading.
This is a bit tricky. In past conversations I was pushing toward making GetVariable()/GetNextVariableName() required and only SetVariable() optional, but there wasn't concensus at that time. The text as it stands it kind of a mix on whether or not GetVariable() is required or merely recommended.
For the point release that we do soon, I could tidy up the text a bit, but I'd like some thoughts on where EBBR should go for the next major revision. GetVariable() should be straight forward to implement GetVariable at runtime by using a RAM-cached value. I don't believe any work has been done to support that in U-Boot.
See this patch series that is not yet merged: https://patchwork.ozlabs.org/project/uboot/list/?series=167069
In the series non-volatile variables are persisted in a file on the EFI system partition.
With the patch series SetVariable() is enabled at runtime. We would need a systemd service for updating the variables in the file store before a reboot but that would not be really conforming to the UEFI spec which mandates immediate update of the store.
At that point may as well just write the file from userspace as a "variable-update-on-disk" mechanism. Simpler than SetVariable() to implement and more robust.
For the other variable services the patch series provides a compliant solution.
Ilias Apalodimas has a draft patch series for using OP-TEE and MM for managing variables. But storage in the RPMB partition of an eMMC device would only work at boottime. Just what you described at last years Embedded Linux conference (https://www.youtube.com/watch?v=VnsF3uRZzNk).
There are paths for making it work. Could use the OP-Tee supplicant to get Linux to do the RPMB writes. Alternately, could store the variable updates in SRAM and require a warm reboot of the normal world to persist changes.
Takahiro Akashi last year presented alternative patches that would enable reading variables at runtime. He recently suggested to use capsule updates to update variables and has submitted patches for capsule updates (https://patchwork.ozlabs.org/project/uboot/list/?series=172907).
If we do not have SetVariable() at runtime, I do not see much value in QueryVariableInfo(). So we shouldn't make that service compulsory.
Agreed
Okay, I'm leaning toward making GetVariable()/GetNextVariableName() at some point in the future, but leaving SetVariable()/QueryVariableInfo() optional. However, I won't do anything in this direction for the point release later this month. I'll just clean up the text to be a bit clearer.
g.
On Tue, May 12, 2020 at 06:15:26PM +0100, Grant Likely wrote:
[...]
For the other variable services the patch series provides a compliant solution.
Ilias Apalodimas has a draft patch series for using OP-TEE and MM for managing variables. But storage in the RPMB partition of an eMMC device would only work at boottime. Just what you described at last years Embedded Linux conference (https://www.youtube.com/watch?v=VnsF3uRZzNk).
There are paths for making it work. Could use the OP-Tee supplicant to get Linux to do the RPMB writes.
Both Get/Setvariable return EFI_UNSUPPORTED for now in my patchset. As you suggest this is probably fixable, but we'll have to take into account what happens if someone requests a variable and the supplicant is not up yet. A cached copy would solve that for GetVariable.
The writes, if we have any during boot (do we?), are going to be a problem though since the spec says: "The only rules the firmware must implement when saving a nonvolatile variable is that it has actually been saved to nonvolatile storage before returning EFI_SUCCESS". I'll have a closer look once I manage to merge all the required patches.
Alternately, could store the variable updates in SRAM and require a warm reboot of the normal world to persist changes.
Takahiro Akashi last year presented alternative patches that would enable reading variables at runtime. He recently suggested to use capsule updates to update variables and has submitted patches for capsule updates (https://patchwork.ozlabs.org/project/uboot/list/?series=172907).
If we do not have SetVariable() at runtime, I do not see much value in QueryVariableInfo(). So we shouldn't make that service compulsory.
Agreed
Okay, I'm leaning toward making GetVariable()/GetNextVariableName() at some point in the future, but leaving SetVariable()/QueryVariableInfo() optional. However, I won't do anything in this direction for the point release later this month. I'll just clean up the text to be a bit clearer.
g.
Regards /Ilias
Am May 12, 2020 5:15:26 PM UTC schrieb Grant Likely grant.likely@arm.com:
On 06/05/2020 20:09, Heinrich Schuchardt wrote:
On 5/6/20 3:18 PM, Grant Likely wrote:
On 05/05/2020 17:41, Heinrich Schuchardt wrote:
On 05.05.20 17:44, Grant Likely wrote:
Hi all,
I'm considering doing a quick point-release for EBBR to address
the
change to RuntimeServicesSupported in UEFI 2.8 Errata A. From
2.8final
to 2.8_A, RuntimeServicesSupported changed from being a variable
to data
in a system table entry. U-Boot and Linux have been updated to the
UEFI
method. EBBR needs to be changed to match.
There are patches on this list under discussion now. Once that is complete and the patches merged, how does everyone feel about an
EBBR
v1.0.1 release before the end of May?
At this moment, the v1.0.1 changes would include:
e47952b (HEAD -> master, glikely/master) Specify details of how a
DTB is
passed to the OS
Thanks for updating the patch.
c155e96 Update spec to address UEFI 2.8 Errata A
The patch looks correct. This is what I stumbled upon looking at
the
rest of the runtime chapter:
The 'Runtime Variable Access' sub-chapter mentions only
SetVariable() as
optional while the table above it specifies all variable services
as
optional. Could we start the sub-chapter with a sentence
"All variable services at runtime are optional."
to avoid misunderstandings.
The `RuntimeServicesSupported` value flag in the `EFI_RT_PROPERTIES_TABLE` should be set correctly for all runtime services. Mentioning this requirement specifically for
SetVariable()
might be misleading.
This is a bit tricky. In past conversations I was pushing toward
making
GetVariable()/GetNextVariableName() required and only SetVariable() optional, but there wasn't concensus at that time. The text as it
stands
it kind of a mix on whether or not GetVariable() is required or
merely
recommended.
For the point release that we do soon, I could tidy up the text a
bit,
but I'd like some thoughts on where EBBR should go for the next
major
revision. GetVariable() should be straight forward to implement GetVariable at runtime by using a RAM-cached value. I don't believe
any
work has been done to support that in U-Boot.
See this patch series that is not yet merged: https://patchwork.ozlabs.org/project/uboot/list/?series=167069
In the series non-volatile variables are persisted in a file on the
EFI
system partition.
With the patch series SetVariable() is enabled at runtime. We would
need
a systemd service for updating the variables in the file store before
a
reboot but that would not be really conforming to the UEFI spec which mandates immediate update of the store.
At that point may as well just write the file from userspace as a "variable-update-on-disk" mechanism. Simpler than SetVariable() to implement and more robust.
In my daily routine GRUB is the only program that tries to update UEFI variables when the GRUB configuration is updated. The other program that might be nice to work with is efibootmgr.
If you want to work with such standard software, you have to provide SetVariables(). Whether the data is written before returning success as required by the UEFI spec or by a later process is of less importance in these scenarios. Anyway I have not found any solution that will not either need a runtime driver for an exclusive storage medium in the firmware or a helper program in the OS for persisting variables.
For the other variable services the patch series provides a compliant solution.
Ilias Apalodimas has a draft patch series for using OP-TEE and MM for managing variables. But storage in the RPMB partition of an eMMC
device
would only work at boottime. Just what you described at last years Embedded Linux conference
(https://www.youtube.com/watch?v=VnsF3uRZzNk).
There are paths for making it work. Could use the OP-Tee supplicant to get Linux to do the RPMB writes. Alternately, could store the variable updates in SRAM and require a warm reboot of the normal world to persist changes.
What will happen if an EFI application not offering an OP-TEE supplicant calls SetVariable() relying on OP-TEE after ExitBootServices?
The problem with warmstart memory is that memory discovery or timing training using writes, or simply a firmware erasing all memory may result in failure.
Best regards
Heinrich
Takahiro Akashi last year presented alternative patches that would enable reading variables at runtime. He recently suggested to use capsule updates to update variables and has submitted patches for capsule updates (https://patchwork.ozlabs.org/project/uboot/list/?series=172907).
If we do not have SetVariable() at runtime, I do not see much value
in
QueryVariableInfo(). So we shouldn't make that service compulsory.
Agreed
Okay, I'm leaning toward making GetVariable()/GetNextVariableName() at some point in the future, but leaving SetVariable()/QueryVariableInfo()
optional. However, I won't do anything in this direction for the point release later this month. I'll just clean up the text to be a bit clearer.
g. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 12/05/2020 20:21, Heinrich Schuchardt wrote:
Am May 12, 2020 5:15:26 PM UTC schrieb Grant Likely grant.likely@arm.com:
On 06/05/2020 20:09, Heinrich Schuchardt wrote:
On 5/6/20 3:18 PM, Grant Likely wrote:
On 05/05/2020 17:41, Heinrich Schuchardt wrote:
On 05.05.20 17:44, Grant Likely wrote:
Hi all,
I'm considering doing a quick point-release for EBBR to address
the
change to RuntimeServicesSupported in UEFI 2.8 Errata A. From
2.8final
to 2.8_A, RuntimeServicesSupported changed from being a variable
to data
in a system table entry. U-Boot and Linux have been updated to the
UEFI
method. EBBR needs to be changed to match.
There are patches on this list under discussion now. Once that is complete and the patches merged, how does everyone feel about an
EBBR
v1.0.1 release before the end of May?
At this moment, the v1.0.1 changes would include:
e47952b (HEAD -> master, glikely/master) Specify details of how a
DTB is
passed to the OS
Thanks for updating the patch.
c155e96 Update spec to address UEFI 2.8 Errata A
The patch looks correct. This is what I stumbled upon looking at
the
rest of the runtime chapter:
The 'Runtime Variable Access' sub-chapter mentions only
SetVariable() as
optional while the table above it specifies all variable services
as
optional. Could we start the sub-chapter with a sentence
"All variable services at runtime are optional."
to avoid misunderstandings.
The `RuntimeServicesSupported` value flag in the `EFI_RT_PROPERTIES_TABLE` should be set correctly for all runtime services. Mentioning this requirement specifically for
SetVariable()
might be misleading.
This is a bit tricky. In past conversations I was pushing toward
making
GetVariable()/GetNextVariableName() required and only SetVariable() optional, but there wasn't concensus at that time. The text as it
stands
it kind of a mix on whether or not GetVariable() is required or
merely
recommended.
For the point release that we do soon, I could tidy up the text a
bit,
but I'd like some thoughts on where EBBR should go for the next
major
revision. GetVariable() should be straight forward to implement GetVariable at runtime by using a RAM-cached value. I don't believe
any
work has been done to support that in U-Boot.
See this patch series that is not yet merged: https://patchwork.ozlabs.org/project/uboot/list/?series=167069
In the series non-volatile variables are persisted in a file on the
EFI
system partition.
With the patch series SetVariable() is enabled at runtime. We would
need
a systemd service for updating the variables in the file store before
a
reboot but that would not be really conforming to the UEFI spec which mandates immediate update of the store.
At that point may as well just write the file from userspace as a "variable-update-on-disk" mechanism. Simpler than SetVariable() to implement and more robust.
In my daily routine GRUB is the only program that tries to update UEFI variables when the GRUB configuration is updated. The other program that might be nice to work with is efibootmgr.
If you want to work with such standard software, you have to provide SetVariables(). Whether the data is written before returning success as required by the UEFI spec or by a later process is of less importance in these scenarios. Anyway I have not found any solution that will not either need a runtime driver for an exclusive storage medium in the firmware or a helper program in the OS for persisting variables.
For the other variable services the patch series provides a compliant solution.
Ilias Apalodimas has a draft patch series for using OP-TEE and MM for managing variables. But storage in the RPMB partition of an eMMC
device
would only work at boottime. Just what you described at last years Embedded Linux conference
(https://www.youtube.com/watch?v=VnsF3uRZzNk).
There are paths for making it work. Could use the OP-Tee supplicant to get Linux to do the RPMB writes. Alternately, could store the variable updates in SRAM and require a warm reboot of the normal world to persist changes.
What will happen if an EFI application not offering an OP-TEE supplicant calls SetVariable() relying on OP-TEE after ExitBootServices?
To possible options are: - If the supplicant isn't running at the time of the call, SetVariable() returns a failure - Hold the values as pending until the supplication starts.
Whichever direction we go, we should get it encoded into either EBBR or UEFI.
The problem with warmstart memory is that memory discovery or timing training using writes, or simply a firmware erasing all memory may result in failure.
Warmstart memory does 100% require the platform reliably being able to preserve warmstart memory. I don't see that as any different from any of the other things we require the platform to do correctly. We've got influence over TF-A on up for a lot of these platforms. Warmboot requirements can be speced out, and platforms that are not capable must then not use a warmboot approach.
Best regards
Heinrich
Takahiro Akashi last year presented alternative patches that would enable reading variables at runtime. He recently suggested to use capsule updates to update variables and has submitted patches for capsule updates (https://patchwork.ozlabs.org/project/uboot/list/?series=172907).
If we do not have SetVariable() at runtime, I do not see much value
in
QueryVariableInfo(). So we shouldn't make that service compulsory.
Agreed
Okay, I'm leaning toward making GetVariable()/GetNextVariableName() at some point in the future, but leaving SetVariable()/QueryVariableInfo()
optional. However, I won't do anything in this direction for the point release later this month. I'll just clean up the text to be a bit clearer.
g. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Mon, 18 May 2020 at 14:26, Grant Likely grant.likely@arm.com wrote:
On 12/05/2020 20:21, Heinrich Schuchardt wrote:
Am May 12, 2020 5:15:26 PM UTC schrieb Grant Likely <
grant.likely@arm.com>:
On 06/05/2020 20:09, Heinrich Schuchardt wrote:
On 5/6/20 3:18 PM, Grant Likely wrote:
On 05/05/2020 17:41, Heinrich Schuchardt wrote:
On 05.05.20 17:44, Grant Likely wrote: > Hi all, > > I'm considering doing a quick point-release for EBBR to address
the
> change to RuntimeServicesSupported in UEFI 2.8 Errata A. From
2.8final
> to 2.8_A, RuntimeServicesSupported changed from being a variable
to data
> in a system table entry. U-Boot and Linux have been updated to the
UEFI
> method. EBBR needs to be changed to match. > > There are patches on this list under discussion now. Once that is > complete and the patches merged, how does everyone feel about an
EBBR
> v1.0.1 release before the end of May? > > At this moment, the v1.0.1 changes would include: > > e47952b (HEAD -> master, glikely/master) Specify details of how a
DTB is
> passed to the OS
Thanks for updating the patch.
> c155e96 Update spec to address UEFI 2.8 Errata A
The patch looks correct. This is what I stumbled upon looking at
the
rest of the runtime chapter:
The 'Runtime Variable Access' sub-chapter mentions only
SetVariable() as
optional while the table above it specifies all variable services
as
optional. Could we start the sub-chapter with a sentence
"All variable services at runtime are optional."to avoid misunderstandings.
The `RuntimeServicesSupported` value flag in the `EFI_RT_PROPERTIES_TABLE` should be set correctly for all runtime services. Mentioning this requirement specifically for
SetVariable()
might be misleading.
This is a bit tricky. In past conversations I was pushing toward
making
GetVariable()/GetNextVariableName() required and only SetVariable() optional, but there wasn't concensus at that time. The text as it
stands
it kind of a mix on whether or not GetVariable() is required or
merely
recommended.
For the point release that we do soon, I could tidy up the text a
bit,
but I'd like some thoughts on where EBBR should go for the next
major
revision. GetVariable() should be straight forward to implement GetVariable at runtime by using a RAM-cached value. I don't believe
any
work has been done to support that in U-Boot.
See this patch series that is not yet merged: https://patchwork.ozlabs.org/project/uboot/list/?series=167069
In the series non-volatile variables are persisted in a file on the
EFI
system partition.
With the patch series SetVariable() is enabled at runtime. We would
need
a systemd service for updating the variables in the file store before
a
reboot but that would not be really conforming to the UEFI spec which mandates immediate update of the store.
At that point may as well just write the file from userspace as a "variable-update-on-disk" mechanism. Simpler than SetVariable() to implement and more robust.
In my daily routine GRUB is the only program that tries to update UEFI
variables when the GRUB configuration is updated. The other program that might be nice to work with is efibootmgr.
If you want to work with such standard software, you have to provide
SetVariables(). Whether the data is written before returning success as required by the UEFI spec or by a later process is of less importance in these scenarios. Anyway I have not found any solution that will not either need a runtime driver for an exclusive storage medium in the firmware or a helper program in the OS for persisting variables.
For the other variable services the patch series provides a compliant solution.
Ilias Apalodimas has a draft patch series for using OP-TEE and MM for managing variables. But storage in the RPMB partition of an eMMC
device
would only work at boottime. Just what you described at last years Embedded Linux conference
(https://www.youtube.com/watch?v=VnsF3uRZzNk).
There are paths for making it work. Could use the OP-Tee supplicant to get Linux to do the RPMB writes. Alternately, could store the variable updates in SRAM and require a warm reboot of the normal world to persist changes.
What will happen if an EFI application not offering an OP-TEE supplicant
calls SetVariable() relying on OP-TEE after ExitBootServices?
To possible options are:
- If the supplicant isn't running at the time of the call, SetVariable()
returns a failure
- Hold the values as pending until the supplication starts.
Whichever direction we go, we should get it encoded into either EBBR or UEFI.
The problem with warmstart memory is that memory discovery or timing
training using writes, or simply a firmware erasing all memory may result in failure.
Warmstart memory does 100% require the platform reliably being able to preserve warmstart memory. I don't see that as any different from any of the other things we require the platform to do correctly. We've got influence over TF-A on up for a lot of these platforms. Warmboot requirements can be speced out, and platforms that are not capable must then not use a warmboot approach.
Isn't this mean indirectly that we need a form of requirements equivalent
to SBBR/SBSA ? -> EBBR/EBSA? Are there any hardware that can be used as "mailboxes" between the past and next environments of a warm boot? Would it be a TPM corner use case? A secure storage warmboot exchange area?
Best regards
Heinrich
Takahiro Akashi last year presented alternative patches that would enable reading variables at runtime. He recently suggested to use capsule updates to update variables and has submitted patches for capsule updates (https://patchwork.ozlabs.org/project/uboot/list/?series=172907).
If we do not have SetVariable() at runtime, I do not see much value
in
QueryVariableInfo(). So we shouldn't make that service compulsory.
Agreed
Okay, I'm leaning toward making GetVariable()/GetNextVariableName() at some point in the future, but leaving SetVariable()/QueryVariableInfo()
optional. However, I won't do anything in this direction for the point release later this month. I'll just clean up the text to be a bit clearer.
g. _______________________________________________ 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
On 18/05/2020 13:35, François Ozog wrote: [...]
> The problem with warmstart memory is that memory discovery or timing training using writes, or simply a firmware erasing all memory may result in failure. Warmstart memory does 100% require the platform reliably being able to preserve warmstart memory. I don't see that as any different from any of the other things we require the platform to do correctly. We've got influence over TF-A on up for a lot of these platforms. Warmboot requirements can be speced out, and platforms that are not capable must then not use a warmboot approach.Isn't this mean indirectly that we need a form of requirements equivalent to SBBR/SBSA ? -> EBBR/EBSA?
I think this remains in the EBBR domain. Arm does not have an equivalent of SBSA for the embedded space because we're not aiming in embedded for the level of standardization as required in the server world.
We do need to be careful about the warmboot language. It is an implementation option that won't always be needed:
- Secureworld had dedicated storage: runtime updates committed immediately - Secureworld uses eMMC/UFS RPMB: warmboot allows variable updates in ram to be committed after reboot. - Secureworld uses eMMC/UFS RPMB, but OP-TEE supplicant running: runtime updates committed immediately.
Are there any hardware that can be used as "mailboxes" between the past and next environments of a warm boot?
Possibly, but that is a very platform specific question. DRAM or SRAM would be the common case.
Would it be a TPM corner use case?
How much scratch ram is available in a TPM device? I didn't think TPMs exposed general purpose memory
A secure storage warmboot exchange area?
Depends on what code is committing the change. Alternatively it could be stored in normal world RAM as long as it get preserved over a warm reboot.
g.
> > Best regards > > Heinrich > >> >>> Takahiro Akashi last year presented alternative patches that would >>> enable reading variables at runtime. He recently suggested to use >>> capsule updates to update variables and has submitted patches for >>> capsule updates >>> (https://patchwork.ozlabs.org/project/uboot/list/?series=172907). >>> >>> If we do not have SetVariable() at runtime, I do not see much value >> in >>> QueryVariableInfo(). So we shouldn't make that service compulsory. >> >> Agreed >> >> Okay, I'm leaning toward making GetVariable()/GetNextVariableName() at >> some point in the future, but leaving SetVariable()/QueryVariableInfo() >> >> optional. However, I won't do anything in this direction for the point >> release later this month. I'll just clean up the text to be a bit >> clearer. >> >> g. >> _______________________________________________ >> boot-architecture mailing list >> boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> >> https://lists.linaro.org/mailman/listinfo/boot-architecture > _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org <mailto: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.ozog@linaro.org mailto:francois.ozog@linaro.org | Skype: ffozog
boot-architecture@lists.linaro.org
-
AKASHI Takahiro -
François Ozog -
Grant Likely -
Heinrich Schuchardt -
Ilias Apalodimas