Hi,
Following implementation (or work towards) of EBBR 1.0 + UEFI Secure boot + UEFI update capsule we learnt a lot.
Here are some topics that may need some clarification on the EBBR specs and It looks timely to start working on EBBR evolution.
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The language need to be explicit.
I - protective offsets EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that "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."
StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without the variable rework done and update capsules. 4MB seems the minimum. 8MB to get margin and 16MB for A/B scheme.
EBBR same paragraph also states: "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. Manual partitioning tools should provide warnings when modifying protective partitions or creating partitions within the first 1MiB."
is it expected that Linaro upstreams changes in installation tools, partition tools to conform to this (with updated to be agreed minimum)?
II - identifying partitions Having two EFI partitions defined with EFI_GUID need a precise behaviour defined: boot with first or boot with second.
Shall we have a EFI_GUID_ALT defined for A/B partition schemes? If not, the BootXXX variables should be used as selector? We lean towards BootXXX variables and not defining a new GUID. But this would mean explicit behavior to be stated in case of lack of BootXXX.
I think GPT volume mirroring should be used in conjunction with A/B: A/B to recover version failures with current hardware, surrounding software; mirroring to protect against storage failures.
Is there any recommendation on mirrored EFI volumes handling ?
III - 32 bits are there any 32 bits specific considerations to be added?
IV - UEFI_RNG_PROTOCOL Following my view in 0) I think this shall be made mandatory
Linaro has upstreamed this in U-Boot and started to implement additional hardware drivers. KASLR is thus functional in 64 bits and will be in 32bits.
V - UEFI SecureBoot Following my view in 0) I think this shall be made mandatory
UEFI SecureBoot is not mentioned in section 2.6 so we need to clarify what needs to be implemented. In particular, we need to implement EFI_LOAD_FILE2_PROTOCOL for initrd signature checking.
VI - UEFI update capsules Following my view in 0) I think this shall be made mandatory
Section 2.6 of UEFI spec 2.7 mentions At some point in time we will need to propose UEFI specification update for: - anti-bricking anti rollback expected behavior - abstract capsules for "start transaction", "commit", "rollback" when we will be dealing with system wide transactional updates. There is probably a lot to state here but I am just starting the discussion.
VII - UEFI watchdog Following my view in 0) I think this shall be made mandatory
In addition to its definition, it should also integrate consistent parameters to define total duration covered as well as number of failed consecutive updates to be triggered as well as how it is delivered (powercycle, NMI, secureIRQ...)
Cheers
Minor comment:
On Tue, Mar 10, 2020 at 17:02:27 +0100, Francois Ozog wrote:
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The
IETF "SHALL" is a synonym for IETF "MUST" (whereas IETF bans use of "MUST").
language need to be explicit.
It is important to stick to a clearly identified set of definitions, but this particular case is not conflicting.
/ Leif
https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/AGuideToWritingWorld... vs. https://tools.ietf.org/html/rfc2119
Hi Francois,
This is really good. EBBR regular meetings have been on hold while the U-Boot work progressed, but it is probably about time to start them up again. This is list is a great first agenda item.
Comments below...
On 10/03/2020 16:02, Francois Ozog wrote:
Hi,
Following implementation (or work towards) of EBBR 1.0 + UEFI Secure boot + UEFI update capsule we learnt a lot.
Here are some topics that may need some clarification on the EBBR specs and It looks timely to start working on EBBR evolution.
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
Have you got a comparison of the protocols needed in each scenario? It has been pretty clear that both models are important, is there a large delta from one to the other, and it is an extra burden to support all of them in U-Boot (e.g., once implemented in mainline, most of the protocols should work for all).
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The language need to be explicit.
Fair point. Do you have a suggesting on how to proceed here?
I - protective offsets EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that "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."
StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without the variable rework done and update capsules. 4MB seems the minimum. 8MB to get margin and 16MB for A/B scheme.
The 1MB was to deal with limitations in the boot rom. If the boot rom needs extra space, would it not be better to have an initial loader that understands partitioning in the 1st 1MB and load the remaining images from a real partition?
EBBR same paragraph also states: "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. Manual partitioning tools should provide warnings when modifying protective partitions or creating partitions within the first 1MiB."
is it expected that Linaro upstreams changes in installation tools, partition tools to conform to this (with updated to be agreed minimum)?
I would expect so, if they aren't already doing that.
II - identifying partitions Having two EFI partitions defined with EFI_GUID need a precise behaviour defined: boot with first or boot with second.
Shall we have a EFI_GUID_ALT defined for A/B partition schemes? If not, the BootXXX variables should be used as selector? We lean towards BootXXX variables and not defining a new GUID. But this would mean explicit behavior to be stated in case of lack of BootXXX.
I think GPT volume mirroring should be used in conjunction with A/B: A/B to recover version failures with current hardware, surrounding software; mirroring to protect against storage failures.
Is there any recommendation on mirrored EFI volumes handling ?
This is definitely a big gap. UEFI in general doesn't say much on handling A/B updates.
III - 32 bits are there any 32 bits specific considerations to be added?
IV - UEFI_RNG_PROTOCOL Following my view in 0) I think this shall be made mandatory
Linaro has upstreamed this in U-Boot and started to implement additional hardware drivers. KASLR is thus functional in 64 bits and will be in 32bits. > V - UEFI SecureBoot Following my view in 0) I think this shall be made mandatory
UEFI SecureBoot is not mentioned in section 2.6 so we need to clarify what needs to be implemented. In particular, we need to implement EFI_LOAD_FILE2_PROTOCOL for initrd signature checking.
VI - UEFI update capsules Following my view in 0) I think this shall be made mandatory
Section 2.6 of UEFI spec 2.7 mentions At some point in time we will need to propose UEFI specification update for:
- anti-bricking anti rollback expected behavior
- abstract capsules for "start transaction", "commit", "rollback" when
we will be dealing with system wide transactional updates. There is probably a lot to state here but I am just starting the discussion.
VII - UEFI watchdog Following my view in 0) I think this shall be made mandatory
In addition to its definition, it should also integrate consistent parameters to define total duration covered as well as number of failed consecutive updates to be triggered as well as how it is delivered (powercycle, NMI, secureIRQ...)
All above look reasonable and need discussion on whether to adopt and how to put it into the document.
I'll schedule the next meeting and send it out to the list.
g.
Cheers
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 Tue, 10 Mar 2020 at 17:18, Grant Likely grant.likely@arm.com wrote:
Hi Francois,
This is really good. EBBR regular meetings have been on hold while the U-Boot work progressed, but it is probably about time to start them up again. This is list is a great first agenda item.
Comments below...
On 10/03/2020 16:02, Francois Ozog wrote:
Hi,
Following implementation (or work towards) of EBBR 1.0 + UEFI Secure boot + UEFI update capsule we learnt a lot.
Here are some topics that may need some clarification on the EBBR specs and It looks timely to start working on EBBR evolution.
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
I would like people to think about this one before getting into the meeting because without this we can't discuss most of the rest.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
Have you got a comparison of the protocols needed in each scenario? It has been pretty clear that both models are important, is there a large delta from one to the other, and it is an extra burden to support all of them in U-Boot (e.g., once implemented in mainline, most of the protocols should work for all).
Supporting industrial players require EFI_LOAD_FILE2_PROTOCOL in addition to the distro subset. Pushed upstream. Ilias may comment about merging
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The language need to be explicit.
Fair point. Do you have a suggesting on how to proceed here?
Thanks Leif for the links. I tend to like the ETSI one because it is somewhat complete on necessary english grammar stuff. But I am flexible, important we state explicitly the reference document and we use the language constructs.
I - protective offsets EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that "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."
StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without the variable rework done and update capsules. 4MB seems the minimum. 8MB to get margin and 16MB for A/B scheme.
The 1MB was to deal with limitations in the boot rom. If the boot rom needs extra space, would it not be better to have an initial loader that understands partitioning in the 1st 1MB and load the remaining images from a real partition?
This is driven by the BL2 which is platform specific and I am not sure we can have any influence. The flashimage.bin in a number of system consists of a (blob) FIP that has BL2, SCP stuff, BL31, BL32, BL33. Ilias upstream U-Boot patches to change from "ADR" to "ADRL" because the code grew too much.
EBBR same paragraph also states: "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. Manual partitioning tools should provide warnings when modifying protective partitions or creating partitions within the first 1MiB."
is it expected that Linaro upstreams changes in installation tools, partition tools to conform to this (with updated to be agreed minimum)?
I would expect so, if they aren't already doing that.
Will need to create initiatives for that.
II - identifying partitions Having two EFI partitions defined with EFI_GUID need a precise behaviour defined: boot with first or boot with second.
Shall we have a EFI_GUID_ALT defined for A/B partition schemes? If not, the BootXXX variables should be used as selector? We lean towards BootXXX variables and not defining a new GUID. But this would mean explicit behavior to be stated in case of lack of BootXXX.
I think GPT volume mirroring should be used in conjunction with A/B: A/B to recover version failures with current hardware, surrounding software; mirroring to protect against storage failures.
Is there any recommendation on mirrored EFI volumes handling ?
This is definitely a big gap. UEFI in general doesn't say much on handling A/B updates.
III - 32 bits are there any 32 bits specific considerations to be added?
IV - UEFI_RNG_PROTOCOL Following my view in 0) I think this shall be made mandatory
Linaro has upstreamed this in U-Boot and started to implement additional hardware drivers. KASLR is thus functional in 64 bits and will be in 32bits. > V - UEFI SecureBoot Following my view in 0) I think this shall be made mandatory
UEFI SecureBoot is not mentioned in section 2.6 so we need to clarify what needs to be implemented. In particular, we need to implement EFI_LOAD_FILE2_PROTOCOL for initrd signature checking.
VI - UEFI update capsules Following my view in 0) I think this shall be made mandatory
Section 2.6 of UEFI spec 2.7 mentions At some point in time we will need to propose UEFI specification update for:
- anti-bricking anti rollback expected behavior
- abstract capsules for "start transaction", "commit", "rollback" when
we will be dealing with system wide transactional updates. There is probably a lot to state here but I am just starting the discussion.
VII - UEFI watchdog Following my view in 0) I think this shall be made mandatory
In addition to its definition, it should also integrate consistent parameters to define total duration covered as well as number of failed consecutive updates to be triggered as well as how it is delivered (powercycle, NMI, secureIRQ...)
All above look reasonable and need discussion on whether to adopt and how to put it into the document.
I'll schedule the next meeting and send it out to the list.
g.
Cheers
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 Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote:
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The language need to be explicit.
Fair point. Do you have a suggesting on how to proceed here?
Thanks Leif for the links. I tend to like the ETSI one because it is somewhat complete on necessary english grammar stuff. But I am flexible, important we state explicitly the reference document and we use the language constructs.
Does ETSI offer us "features" that are missing from RFC 2119.
Personally I would favour RFC 2119 simply because it is so much better known than the ETSI drafting rules.
If you cite RFC 2119 and I don't have to go and read anything... and even if I did it is super concise and quick to read.
Cite ETSI drafting rules, clause 3 and I have to put in a lot more effort.
I - protective offsets EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that "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."
StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without the variable rework done and update capsules. 4MB seems the minimum. 8MB to get margin and 16MB for A/B scheme.
The 1MB was to deal with limitations in the boot rom. If the boot rom needs extra space, would it not be better to have an initial loader that understands partitioning in the 1st 1MB and load the remaining images from a real partition?
This is driven by the BL2 which is platform specific and I am not sure we can have any influence. The flashimage.bin in a number of system consists of a (blob) FIP that has BL2, SCP stuff, BL31, BL32, BL33. Ilias upstream U-Boot patches to change from "ADR" to "ADRL" because the code grew too much.
I'm not quite sure I understand the concern here.
Are you still working on systems where the boot ROM mandates using MBR partitioning and attempting to put secure boot on it? If so perhaps we could simply discontinue MBR support for systems with secure boot!
In all other cases a bulky firmware installed on shared media must have a protective partition (with the appropriate flags) to prevent partition tools from damaging it anyway. In such a case it does not matter if there is firmware above the 1MB boundary.
EBBR same paragraph also states: "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. Manual partitioning tools should provide warnings when modifying protective partitions or creating partitions within the first 1MiB."
is it expected that Linaro upstreams changes in installation tools, partition tools to conform to this (with updated to be agreed minimum)?
I would expect so, if they aren't already doing that.
Will need to create initiatives for that.
Pretty much all tools already respect the 1MiB boundary. Sometimes they use an "expert mode" rather than a explicit warning but I'd view that as equivalent.
Daniel.
Le mar. 10 mars 2020 à 18:37, Daniel Thompson daniel.thompson@linaro.org a écrit :
On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote:
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The language need to be explicit.
Fair point. Do you have a suggesting on how to proceed here?
Thanks Leif for the links. I tend to like the ETSI one because it is somewhat complete on necessary english grammar stuff. But I am flexible, important we state explicitly the reference document and we use the language constructs.
Does ETSI offer us "features" that are missing from RFC 2119.
Personally I would favour RFC 2119 simply because it is so much better known than the ETSI drafting rules.
If you cite RFC 2119 and I don't have to go and read anything... and even if I did it is super concise and quick to read.
Cite ETSI drafting rules, clause 3 and I have to put in a lot more effort.
I - protective offsets EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that "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."
StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without
the
variable rework done and update capsules. 4MB seems the minimum. 8MB to get margin and 16MB for A/B scheme.
The 1MB was to deal with limitations in the boot rom. If the boot rom needs extra space, would it not be better to have an initial loader
that
understands partitioning in the 1st 1MB and load the remaining images from a real partition?
This is driven by the BL2 which is platform specific and I am not sure we can have any influence. The flashimage.bin in a number of system consists of a (blob) FIP that has BL2, SCP stuff, BL31, BL32, BL33. Ilias upstream U-Boot patches to change from "ADR" to "ADRL" because the code grew too much.
I'm not quite sure I understand the concern here.
Are you still working on systems where the boot ROM mandates using MBR partitioning and attempting to put secure boot on it? If so perhaps we could simply discontinue MBR support for systems with secure boot!
Well..... we want Products on the market to benefit from EBBR compliance rather than two years from now. So MBR is inevitable. And is not that a pain ;-) Of course its not as clean as we would like but “sales first”!
In all other cases a bulky firmware installed on shared media must have a protective partition (with the appropriate flags) to prevent partition tools from damaging it anyway. In such a case it does not matter if there is firmware above the 1MB boundary.
EBBR same paragraph also states: "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. Manual partitioning tools should provide warnings when modifying protective partitions or creating partitions within the first 1MiB."
is it expected that Linaro upstreams changes in installation tools, partition tools to conform to this (with updated to be agreed minimum)?
I would expect so, if they aren't already doing that.
Will need to create initiatives for that.
Pretty much all tools already respect the 1MiB boundary. Sometimes they use an "expert mode" rather than a explicit warning but I'd view that as equivalent.
Daniel.
On 3/10/20 7:37 PM, Francois Ozog wrote:
Le mar. 10 mars 2020 à 18:37, Daniel Thompson daniel.thompson@linaro.org a écrit :
On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote:
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The language need to be explicit.
Fair point. Do you have a suggesting on how to proceed here?
Thanks Leif for the links. I tend to like the ETSI one because it is somewhat complete on necessary english grammar stuff. But I am flexible, important we state explicitly the reference document and we use the language constructs.
Does ETSI offer us "features" that are missing from RFC 2119.
Personally I would favour RFC 2119 simply because it is so much better known than the ETSI drafting rules.
If you cite RFC 2119 and I don't have to go and read anything... and even if I did it is super concise and quick to read.
Cite ETSI drafting rules, clause 3 and I have to put in a lot more effort.
I - protective offsets EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that "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."
StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without
the
variable rework done and update capsules. 4MB seems the minimum. 8MB to get margin and 16MB for A/B scheme.
The 1MB was to deal with limitations in the boot rom. If the boot rom needs extra space, would it not be better to have an initial loader
that
understands partitioning in the 1st 1MB and load the remaining images from a real partition?
This is driven by the BL2 which is platform specific and I am not sure we can have any influence. The flashimage.bin in a number of system consists of a (blob) FIP that has BL2, SCP stuff, BL31, BL32, BL33. Ilias upstream U-Boot patches to change from "ADR" to "ADRL" because the code grew too much.
I'm not quite sure I understand the concern here.
Are you still working on systems where the boot ROM mandates using MBR partitioning and attempting to put secure boot on it? If so perhaps we could simply discontinue MBR support for systems with secure boot!
Well..... we want Products on the market to benefit from EBBR compliance rather than two years from now. So MBR is inevitable. And is not that a pain ;-) Of course its not as clean as we would like but “sales first”!
A typical problem is that a SoC has an entry address within the first 17 KiB, e.g. the Allwinner CPUs want a firmware entry point at 0x2000. If I correctly understand the UEFI standard, one might use PartitionEntryLBA to place the GPT Partition Entry Array behind the firmware in this case.
Best regards
Heinrich
In all other cases a bulky firmware installed on shared media must have a protective partition (with the appropriate flags) to prevent partition tools from damaging it anyway. In such a case it does not matter if there is firmware above the 1MB boundary.
EBBR same paragraph also states: "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. Manual partitioning tools should provide warnings when modifying protective partitions or creating partitions within the first 1MiB."
is it expected that Linaro upstreams changes in installation tools, partition tools to conform to this (with updated to be agreed minimum)?
I would expect so, if they aren't already doing that.
Will need to create initiatives for that.
Pretty much all tools already respect the 1MiB boundary. Sometimes they use an "expert mode" rather than a explicit warning but I'd view that as equivalent.
Daniel.
On 3/11/20 12:04 AM, Heinrich Schuchardt wrote:
On 3/10/20 7:37 PM, Francois Ozog wrote:
Le mar. 10 mars 2020 à 18:37, Daniel Thompson daniel.thompson@linaro.org a écrit :
On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote:
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The language need to be explicit.
Fair point. Do you have a suggesting on how to proceed here?
Thanks Leif for the links. I tend to like the ETSI one because it is somewhat complete on necessary english grammar stuff. But I am flexible, important we state explicitly the reference document and we use the language constructs.
Does ETSI offer us "features" that are missing from RFC 2119.
Personally I would favour RFC 2119 simply because it is so much better known than the ETSI drafting rules.
If you cite RFC 2119 and I don't have to go and read anything... and even if I did it is super concise and quick to read.
Cite ETSI drafting rules, clause 3 and I have to put in a lot more effort.
I - protective offsets EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that "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."
StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without
the
variable rework done and update capsules. 4MB seems the minimum. 8MB to get margin and 16MB for A/B scheme.
The 1MB was to deal with limitations in the boot rom. If the boot rom needs extra space, would it not be better to have an initial loader
that
understands partitioning in the 1st 1MB and load the remaining images from a real partition?
This is driven by the BL2 which is platform specific and I am not sure we can have any influence. The flashimage.bin in a number of system consists of a (blob) FIP that has BL2, SCP stuff, BL31, BL32, BL33. Ilias upstream U-Boot patches to change from "ADR" to "ADRL" because the code grew too much.
I'm not quite sure I understand the concern here.
Are you still working on systems where the boot ROM mandates using MBR partitioning and attempting to put secure boot on it? If so perhaps we could simply discontinue MBR support for systems with secure boot!
Well..... we want Products on the market to benefit from EBBR compliance rather than two years from now. So MBR is inevitable. And is not that a pain ;-) Of course its not as clean as we would like but “sales first”!
A typical problem is that a SoC has an entry address within the first 17 KiB, e.g. the Allwinner CPUs want a firmware entry point at 0x2000. If I correctly understand the UEFI standard, one might use PartitionEntryLBA to place the GPT Partition Entry Array behind the firmware in this case.
In the expert mode of gdisk there is command 'j' for moving the GPT Partition Entry Array to an arbitrary sector. This will protect the area between the GPT header and the GPT Partition Entry Array from being used for a partition. The same can be done with parameter -j of sgdisk.
Furthermore gdisk supports creating a hybrid MBR. This allow to have GUID partition table and a MBR partion table at the same time where the MBR partition table mirrors up to three GPT partitions and the fourth MBR partition is used to protect the GUID partition table.
So requiring GPT and having boards only supporting booting from an MBR partition (like the Raspberry) seems not to be exclusive.
Best regards
Heinrich
In all other cases a bulky firmware installed on shared media must have a protective partition (with the appropriate flags) to prevent partition tools from damaging it anyway. In such a case it does not matter if there is firmware above the 1MB boundary.
EBBR same paragraph also states: "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. Manual partitioning tools should provide warnings when modifying protective partitions or creating partitions within the first 1MiB."
is it expected that Linaro upstreams changes in installation tools, partition tools to conform to this (with updated to be agreed minimum)?
I would expect so, if they aren't already doing that.
Will need to create initiatives for that.
Pretty much all tools already respect the 1MiB boundary. Sometimes they use an "expert mode" rather than a explicit warning but I'd view that as equivalent.
Daniel.
On Wed, 11 Mar 2020 at 07:48, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 3/11/20 12:04 AM, Heinrich Schuchardt wrote:
On 3/10/20 7:37 PM, Francois Ozog wrote:
Le mar. 10 mars 2020 à 18:37, Daniel Thompson daniel.thompson@linaro.org a écrit :
On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote:
> 0.2 - normative text > The normative section shall be stated clearly: is " 1.2. Guiding > Principles" normative? > > IETF and ETSI have different language conventions to express > absolutely mandated and various levels of optionality. This spec may > be red by Telecom people or Linux people. Their interpretation may be > erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The > language need to be explicit.
Fair point. Do you have a suggesting on how to proceed here?
Thanks Leif for the links. I tend to like the ETSI one because it is somewhat complete on necessary english grammar stuff. But I am flexible, important we state explicitly the reference document and we use the language constructs.
Does ETSI offer us "features" that are missing from RFC 2119.
Personally I would favour RFC 2119 simply because it is so much better known than the ETSI drafting rules.
If you cite RFC 2119 and I don't have to go and read anything... and even if I did it is super concise and quick to read.
Cite ETSI drafting rules, clause 3 and I have to put in a lot more effort.
> I - protective offsets > EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that > "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." > > StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without
the
> variable rework done and update capsules. 4MB seems the minimum. 8MB > to get margin and 16MB for A/B scheme.
The 1MB was to deal with limitations in the boot rom. If the boot rom needs extra space, would it not be better to have an initial loader
that
understands partitioning in the 1st 1MB and load the remaining images from a real partition?
This is driven by the BL2 which is platform specific and I am not sure we can have any influence. The flashimage.bin in a number of system consists of a (blob) FIP that has BL2, SCP stuff, BL31, BL32, BL33. Ilias upstream U-Boot patches to change from "ADR" to "ADRL" because the code grew too much.
I'm not quite sure I understand the concern here.
Are you still working on systems where the boot ROM mandates using MBR partitioning and attempting to put secure boot on it? If so perhaps we could simply discontinue MBR support for systems with secure boot!
Well..... we want Products on the market to benefit from EBBR compliance rather than two years from now. So MBR is inevitable. And is not that a pain ;-) Of course its not as clean as we would like but “sales first”!
A typical problem is that a SoC has an entry address within the first 17 KiB, e.g. the Allwinner CPUs want a firmware entry point at 0x2000. If I correctly understand the UEFI standard, one might use PartitionEntryLBA to place the GPT Partition Entry Array behind the firmware in this case.
In the expert mode of gdisk there is command 'j' for moving the GPT Partition Entry Array to an arbitrary sector. This will protect the area between the GPT header and the GPT Partition Entry Array from being used for a partition. The same can be done with parameter -j of sgdisk.
Furthermore gdisk supports creating a hybrid MBR. This allow to have GUID partition table and a MBR partion table at the same time where the MBR partition table mirrors up to three GPT partitions and the fourth MBR partition is used to protect the GUID partition table.
So requiring GPT and having boards only supporting booting from an MBR partition (like the Raspberry) seems not to be exclusive.
That sounds like a great solution!
Best regards
Heinrich
In all other cases a bulky firmware installed on shared media must have a protective partition (with the appropriate flags) to prevent partition tools from damaging it anyway. In such a case it does not matter if there is firmware above the 1MB boundary.
> EBBR same paragraph also states: > "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. Manual partitioning tools should > provide warnings when modifying protective partitions or creating > partitions within the first 1MiB." > > is it expected that Linaro upstreams changes in installation tools, > partition tools to conform to this (with updated to be agreed > minimum)?
I would expect so, if they aren't already doing that.
Will need to create initiatives for that.
Pretty much all tools already respect the 1MiB boundary. Sometimes they use an "expert mode" rather than a explicit warning but I'd view that as equivalent.
Daniel.
On Wed, Mar 11, 2020 at 11:20:17AM +0100, Francois Ozog wrote:
On Wed, 11 Mar 2020 at 07:48, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 3/11/20 12:04 AM, Heinrich Schuchardt wrote:
On 3/10/20 7:37 PM, Francois Ozog wrote:
Le mar. 10 mars 2020 à 18:37, Daniel Thompson daniel.thompson@linaro.org a écrit :
On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote:
This is driven by the BL2 which is platform specific and I am not sure we can have any influence. The flashimage.bin in a number of system consists of a (blob) FIP that has BL2, SCP stuff, BL31, BL32, BL33. Ilias upstream U-Boot patches to change from "ADR" to "ADRL" because the code grew too much.
I'm not quite sure I understand the concern here.
Are you still working on systems where the boot ROM mandates using MBR partitioning and attempting to put secure boot on it? If so perhaps we could simply discontinue MBR support for systems with secure boot!
Well..... we want Products on the market to benefit from EBBR compliance rather than two years from now. So MBR is inevitable. And is not that a pain ;-) Of course its not as clean as we would like but “sales first”!
A typical problem is that a SoC has an entry address within the first 17 KiB, e.g. the Allwinner CPUs want a firmware entry point at 0x2000. If I correctly understand the UEFI standard, one might use PartitionEntryLBA to place the GPT Partition Entry Array behind the firmware in this case.
In the expert mode of gdisk there is command 'j' for moving the GPT Partition Entry Array to an arbitrary sector. This will protect the area between the GPT header and the GPT Partition Entry Array from being used for a partition. The same can be done with parameter -j of sgdisk.
Furthermore gdisk supports creating a hybrid MBR. This allow to have GUID partition table and a MBR partion table at the same time where the MBR partition table mirrors up to three GPT partitions and the fourth MBR partition is used to protect the GUID partition table.
So requiring GPT and having boards only supporting booting from an MBR partition (like the Raspberry) seems not to be exclusive.
That sounds like a great solution!
The last time we discussed this there was *very* strong opposition during meetings to hybrid partitioning and IIRC language was added to the spec to prohibit it.
Hybrid partitioning is a problem because it imposes to difficult to meet constraints on partitioning tools provided by the operating system.
In other words if we permit hybrid partitioning in order that boot code can find the firmware then the operating system would inherit a duty to not to screw up the firmware loading when it modifies the partition tables. It is hard to express how the OS should go about that.
Hence the current approach where we accept that MBR partitioning offers an inferior feature set to GPT.
Daniel.
On Wed, Mar 11, 2020 at 12:04:45AM +0100, Heinrich Schuchardt wrote:
The 1MB was to deal with limitations in the boot rom. If the boot rom needs extra space, would it not be better to have an initial loader
that
understands partitioning in the 1st 1MB and load the remaining images from a real partition?
This is driven by the BL2 which is platform specific and I am not sure we can have any influence. The flashimage.bin in a number of system consists of a (blob) FIP that has BL2, SCP stuff, BL31, BL32, BL33. Ilias upstream U-Boot patches to change from "ADR" to "ADRL" because the code grew too much.
I'm not quite sure I understand the concern here.
Are you still working on systems where the boot ROM mandates using MBR partitioning and attempting to put secure boot on it? If so perhaps we could simply discontinue MBR support for systems with secure boot!
Well..... we want Products on the market to benefit from EBBR compliance rather than two years from now. So MBR is inevitable. And is not that a pain ;-) Of course its not as clean as we would like but “sales first”!
A typical problem is that a SoC has an entry address within the first 17 KiB, e.g. the Allwinner CPUs want a firmware entry point at 0x2000. If I correctly understand the UEFI standard, one might use PartitionEntryLBA to place the GPT Partition Entry Array behind the firmware in this case.
Often when you try to get clever with the GPT stuff in the UEFI standard you find a field that does what you want and then somewhere else a bit a language that restricts what you can set it too ;-).
However I can't find anything like that for PartitionEntryLBA so this would certainly make the problem extremely narrow.
1. System boots from shared media
2. System cannot use hardware partitioning features of the shared boot media (perhaps it is an SD card or because the boot ROM does not try eMMC boot protocol first)
3. Either Boot ROM entry point makes GPT partitioning impossible or Boot ROM automatically parses MBR to locate additional boot code and therefore needs a real MBR partition.
4. We care that automatic partition tools doesn't know how to avoid reallocating space allocated to the firmware (and that manual tools can't warn about it).
Given the extremely narrow scope, I'm suggest that requirement #4 does not exist on any system ;-).
Daniel.
Hi,
Sorry for joining in late
[...]
The 1MB was to deal with limitations in the boot rom. If the boot rom needs extra space, would it not be better to have an initial loader that understands partitioning in the 1st 1MB and load the remaining images from a real partition?
This is driven by the BL2 which is platform specific and I am not sure we can have any influence. The flashimage.bin in a number of system consists of a (blob) FIP that has BL2, SCP stuff, BL31, BL32, BL33. Ilias upstream U-Boot patches to change from "ADR" to "ADRL" because the code grew too much.
Not U-boot but OP-TEE but the case stands
EBBR same paragraph also states: "Automatic partitioning tools (e.g. an OS installer) must not create
Regards /Ilias
Hi Francois,
On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote:
On Tue, 10 Mar 2020 at 17:18, Grant Likely grant.likely@arm.com wrote:
Hi Francois,
This is really good. EBBR regular meetings have been on hold while the U-Boot work progressed, but it is probably about time to start them up again. This is list is a great first agenda item.
Comments below...
On 10/03/2020 16:02, Francois Ozog wrote:
Hi,
Following implementation (or work towards) of EBBR 1.0 + UEFI Secure boot + UEFI update capsule we learnt a lot.
Here are some topics that may need some clarification on the EBBR specs and It looks timely to start working on EBBR evolution.
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
I would like people to think about this one before getting into the meeting because without this we can't discuss most of the rest.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
Have you got a comparison of the protocols needed in each scenario? It has been pretty clear that both models are important, is there a large delta from one to the other, and it is an extra burden to support all of them in U-Boot (e.g., once implemented in mainline, most of the protocols should work for all).
Supporting industrial players require EFI_LOAD_FILE2_PROTOCOL in addition to the distro subset. Pushed upstream. Ilias may comment about merging
This is in U-Boot already and should go in kernel 5.7. IIRC EDK2 also got a command line to register and use the protocol.
The idea behind this is that we use a number of different and rather complicated ways of passing the initrd to the kernel. This is an arch-agnostic approach. The kernel efi stub allocates a memory during booting and requests the firmware for the file right before it needs to run it.
Nothing authenticates the file, but on U-boot for example, the file name is a config option, thus built-in into U-Boot. In conjuction with TF-A verifying the bootloader it offers some kind of (maybe naive??) security since you can't change the file location. A user can still overwrite the initrd contents though. There's ways to verify the initrd itself on linux if that's necessary.
But I am flexible, important we state explicitly the reference document and we use the language constructs.
[...]
I - protective offsets
Regards /Ilias
On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote:
Hi,
Following implementation (or work towards) of EBBR 1.0 + UEFI Secure boot + UEFI update capsule we learnt a lot.
Here are some topics that may need some clarification on the EBBR specs and It looks timely to start working on EBBR evolution.
Thanks for circulating this.
I'm going to respond piecemeal (so I can join the right sub-threads) but since so many of your later comments include "Following my view in 0) I think this shall be made mandatory" let me kick off with the comment below!
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
We have resisted levels in EBBR until now but this might be where might have a need for them.
Put another way I agree that getting explicit about mandatory features for secure boot flows is useful.
However I also think that is remains valuable to define best practice for how firmware and OS interact on systems that have not implemented secure boot.
Daniel.
On Tue, 10 Mar 2020 at 18:19, Daniel Thompson daniel.thompson@linaro.org wrote:
On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote:
Hi,
Following implementation (or work towards) of EBBR 1.0 + UEFI Secure boot + UEFI update capsule we learnt a lot.
Here are some topics that may need some clarification on the EBBR specs and It looks timely to start working on EBBR evolution.
Thanks for circulating this.
I'm going to respond piecemeal (so I can join the right sub-threads) but since so many of your later comments include "Following my view in 0) I think this shall be made mandatory" let me kick off with the comment below!
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
We have resisted levels in EBBR until now but this might be where might have a need for them.
Put another way I agree that getting explicit about mandatory features for secure boot flows is useful.
However I also think that is remains valuable to define best practice for how firmware and OS interact on systems that have not implemented secure boot.
It's all about the target use:
1) industrial (manufacturing, automotive, robotics, medical...) components 2) telecom edge 3) 96boards 4) developer desktop 5) server
As I just consider 1 and 2, I have no case without secure boot... Now the dev platform can come without the secureboot active and SElinx deactivated.... In what context you think this is usefull?
Daniel.
On Tue, Mar 10, 2020 at 06:34:35PM +0100, Francois Ozog wrote:
On Tue, 10 Mar 2020 at 18:19, Daniel Thompson daniel.thompson@linaro.org wrote:
On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote:
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
We have resisted levels in EBBR until now but this might be where might have a need for them.
Put another way I agree that getting explicit about mandatory features for secure boot flows is useful.
However I also think that is remains valuable to define best practice for how firmware and OS interact on systems that have not implemented secure boot.
It's all about the target use:
- industrial (manufacturing, automotive, robotics, medical...) components
- telecom edge
- 96boards
- developer desktop
- server
As I just consider 1 and 2, I have no case without secure boot... Now the dev platform can come without the secureboot active and SElinx deactivated.... In what context you think this is usefull?
I would like it to be possible for dev boards and SoMs whose SoCs do not have a built-in root of trust to have some basic level of EBBR compliance.
I don't like to optics of saying "this standard cannot possibly apply to a Raspberry Pi"[1]. Taking the RPi Zero or CM3 as examples[2], I can't see any value added by secure boot since the root-of-trust would have to start on the same media as the operating system anyway.
Daniel.
[1] I'd also worried about some of the open-market Arm SoMs as well, but since 96Boards has skin in the game there I've adopted a less partisan example above.
[2] There are problems with RPi4 too but they are different (and hopefully less severe).
On 3/11/20 12:10 PM, Daniel Thompson wrote:
On Tue, Mar 10, 2020 at 06:34:35PM +0100, Francois Ozog wrote:
On Tue, 10 Mar 2020 at 18:19, Daniel Thompson daniel.thompson@linaro.org wrote:
On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote:
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
We have resisted levels in EBBR until now but this might be where might have a need for them.
Put another way I agree that getting explicit about mandatory features for secure boot flows is useful.
However I also think that is remains valuable to define best practice for how firmware and OS interact on systems that have not implemented secure boot.
It's all about the target use:
- industrial (manufacturing, automotive, robotics, medical...) components
- telecom edge
- 96boards
- developer desktop
- server
As I just consider 1 and 2, I have no case without secure boot... Now the dev platform can come without the secureboot active and SElinx deactivated.... In what context you think this is usefull?
I would like it to be possible for dev boards and SoMs whose SoCs do not have a built-in root of trust to have some basic level of EBBR compliance.
I don't like to optics of saying "this standard cannot possibly apply to a Raspberry Pi"[1]. Taking the RPi Zero or CM3 as examples[2], I can't see any value added by secure boot since the root-of-trust would have to start on the same media as the operating system anyway.
There is a TPMv2 module available for Raspberries.
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module?v...
Would we be able to use this as root of trust?
Would we recommend the EFI TPM2 Protocol to be implemented in the EBBR as a possible source of trust? Daniel Kiper, one of the maintainers of GRUB, expressed interest in this feature.
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specificat...
Best regards
Heinrich
Daniel.
[1] I'd also worried about some of the open-market Arm SoMs as well, but since 96Boards has skin in the game there I've adopted a less partisan example above.
[2] There are problems with RPi4 too but they are different (and hopefully less severe).
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Le mer. 11 mars 2020 à 22:22, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
On 3/11/20 12:10 PM, Daniel Thompson wrote:
On Tue, Mar 10, 2020 at 06:34:35PM +0100, Francois Ozog wrote:
On Tue, 10 Mar 2020 at 18:19, Daniel Thompson <
daniel.thompson@linaro.org>
wrote:
On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote:
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
We have resisted levels in EBBR until now but this might be where might have a need for them.
Put another way I agree that getting explicit about mandatory features for secure boot flows is useful.
However I also think that is remains valuable to define best practice for how firmware and OS interact on systems that have not implemented secure boot.
It's all about the target use:
- industrial (manufacturing, automotive, robotics, medical...)
components
- telecom edge
- 96boards
- developer desktop
- server
As I just consider 1 and 2, I have no case without secure boot... Now the dev platform can come without the secureboot active and SElinx deactivated.... In what context you think this is usefull?
I would like it to be possible for dev boards and SoMs whose SoCs do not have a built-in root of trust to have some basic level of EBBR compliance.
I don't like to optics of saying "this standard cannot possibly apply to a Raspberry Pi"[1]. Taking the RPi Zero or CM3 as examples[2], I can't
see any
value added by secure boot since the root-of-trust would have to start on the same media as the operating system anyway.
There is a TPMv2 module available for Raspberries.
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module?v...
Would we be able to use this as root of trust?
Would we recommend the EFI TPM2 Protocol to be implemented in the EBBR as a possible source of trust? Daniel Kiper, one of the maintainers of GRUB, expressed interest in this feature.
TPMv2 is definitely a big topic. We also implemented an OPTEE one. We will
star working on measured boot next cycle (staring April) tf-a team is ready for that.
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specificat...
Best regards
Heinrich
Daniel.
[1] I'd also worried about some of the open-market Arm SoMs as well, but since 96Boards has skin in the game there I've adopted a less partisan example above.
[2] There are problems with RPi4 too but they are different (and hopefully less severe).
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.ozog@linaro.org | Skype: ffozog
On Thu, 12 Mar 2020 at 03:11, Francois Ozog francois.ozog@linaro.org wrote:
Le mer. 11 mars 2020 à 22:22, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
On 3/11/20 12:10 PM, Daniel Thompson wrote:
On Tue, Mar 10, 2020 at 06:34:35PM +0100, Francois Ozog wrote:
On Tue, 10 Mar 2020 at 18:19, Daniel Thompson <
daniel.thompson@linaro.org>
wrote:
On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote:
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
We have resisted levels in EBBR until now but this might be where might have a need for them.
Put another way I agree that getting explicit about mandatory features for secure boot flows is useful.
However I also think that is remains valuable to define best practice for how firmware and OS interact on systems that have not implemented secure boot.
It's all about the target use:
- industrial (manufacturing, automotive, robotics, medical...)
components
- telecom edge
- 96boards
- developer desktop
- server
As I just consider 1 and 2, I have no case without secure boot... Now the dev platform can come without the secureboot active and SElinx deactivated.... In what context you think this is usefull?
I would like it to be possible for dev boards and SoMs whose SoCs do not have a built-in root of trust to have some basic level of EBBR compliance.
I don't like to optics of saying "this standard cannot possibly apply to a Raspberry Pi"[1]. Taking the RPi Zero or CM3 as examples[2], I can't
see any
value added by secure boot since the root-of-trust would have to start on the same media as the operating system anyway.
There is a TPMv2 module available for Raspberries.
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module?v...
Would we be able to use this as root of trust?
AFAIK, TPM in itself can't act as a root of trust. It is rather a passive device which can provide you with trusted/secure services. In general a root of trust is the first piece of *non-modifiable* code that runs on a platform which is BootROM that establishes the chain of trust via verifying the first stage boot-loader which in turn continues the chain of trust to next boot stages and so on.
Would we recommend the EFI TPM2 Protocol to be implemented in the EBBR as a possible source of trust? Daniel Kiper, one of the maintainers of GRUB, expressed interest in this feature.
TPMv2 is definitely a big topic. We also implemented an OPTEE one. We will
star working on measured boot next cycle (staring April) tf-a team is ready for that.
In case of measured boot too, either you need BootROM being root of trust or first stage boot-loader verified by BootROM to measure next boot stages and invoke TPM to store/update hash in PCR register. TPM doesn't do the measurements by itself.
-Sumit
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specificat...
Best regards
Heinrich
Daniel.
[1] I'd also worried about some of the open-market Arm SoMs as well, but since 96Boards has skin in the game there I've adopted a less partisan example above.
[2] There are problems with RPi4 too but they are different (and hopefully less severe).
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.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module?v...
Would we be able to use this as root of trust?
AFAIK, TPM in itself can't act as a root of trust. It is rather a passive device which can provide you with trusted/secure services. In general a root of trust is the first piece of *non-modifiable* code that runs on a platform which is BootROM that establishes the chain of trust via verifying the first stage boot-loader which in turn continues the chain of trust to next boot stages and so on.
You do need to take care with "root of trust" terminology.
A root of trust is something that is inherently trusted, and in which a compromise can't be detected. There are various terminology schemes proposed from GlobalPlatform, TCG, NIST-- e.g. roots of trust for: update, verification, measurement, storage, reporting, etc.
So a boot ROM is _a_ root of trust-- for example a root of trust for verification.
A TPM is a root of trust for storage (i.e. securely storing measurements) and for reporting (i.e. providing cryptographically signed attestation reports).
So, it depends what you mean.
Thanks, Stuart
On Thu, 12 Mar 2020 at 20:43, Stuart Yoder stuart.yoder@arm.com wrote:
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module?v...
Would we be able to use this as root of trust?
AFAIK, TPM in itself can't act as a root of trust. It is rather a passive device which can provide you with trusted/secure services. In general a root of trust is the first piece of *non-modifiable* code that runs on a platform which is BootROM that establishes the chain of trust via verifying the first stage boot-loader which in turn continues the chain of trust to next boot stages and so on.
You do need to take care with "root of trust" terminology.
A root of trust is something that is inherently trusted, and in which a compromise can't be detected. There are various terminology schemes proposed from GlobalPlatform, TCG, NIST-- e.g. roots of trust for: update, verification, measurement, storage, reporting, etc.
So a boot ROM is _a_ root of trust-- for example a root of trust for verification.
A TPM is a root of trust for storage (i.e. securely storing measurements) and for reporting (i.e. providing cryptographically signed attestation reports).
So, it depends what you mean.
I guess the context of discussion was pretty clear in this regard: "Secure boot for Raspberries", no?
BTW, in general I agree with you that one shouldn't confuse "root of trust for Secure boot" with "root of trust for storage or reporting".
-Sumit
Thanks, Stuart
On 12/03/2020 04:58, Sumit Garg wrote:
On Thu, 12 Mar 2020 at 03:11, Francois Ozog francois.ozog@linaro.org wrote:
Le mer. 11 mars 2020 à 22:22, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
On 3/11/20 12:10 PM, Daniel Thompson wrote:
On Tue, Mar 10, 2020 at 06:34:35PM +0100, Francois Ozog wrote:
On Tue, 10 Mar 2020 at 18:19, Daniel Thompson <
daniel.thompson@linaro.org>
wrote:
On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote: > 0.1 - EBBR goal > May be a reassessment on the "for what" the specification is built. > > Following all the discussions with prominent industry players, I start > to think that limiting the constraints to be EBBR compliant may become > counter productive. There will be both EBBR non compliant and EBBR > compliant systems. This is inevitable. But EBBR exist for a number of > use cases in a number of markets. The value of EBBR is consistent > behavior across those. > > Maximising number of EBBR compliant systems without stating use case > parameters ( "why" and "for what") may not be the best goal. > > Out of things to be more explicit are supported secure boot flows > (with/without shim+grub or direct). Some vendors require shim+grub > while industry players want the exact opposite: nothing but UEFI. This > drivers a number of requirements in terms of UEFI protocols needed
We have resisted levels in EBBR until now but this might be where might have a need for them.
Put another way I agree that getting explicit about mandatory features for secure boot flows is useful.
However I also think that is remains valuable to define best practice for how firmware and OS interact on systems that have not implemented secure boot.
It's all about the target use:
- industrial (manufacturing, automotive, robotics, medical...)
components
- telecom edge
- 96boards
- developer desktop
- server
As I just consider 1 and 2, I have no case without secure boot... Now the dev platform can come without the secureboot active and SElinx deactivated.... In what context you think this is usefull?
I would like it to be possible for dev boards and SoMs whose SoCs do not have a built-in root of trust to have some basic level of EBBR compliance.
I don't like to optics of saying "this standard cannot possibly apply to a Raspberry Pi"[1]. Taking the RPi Zero or CM3 as examples[2], I can't
see any
value added by secure boot since the root-of-trust would have to start on the same media as the operating system anyway.
There is a TPMv2 module available for Raspberries.
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module?v...
Would we be able to use this as root of trust?
AFAIK, TPM in itself can't act as a root of trust. It is rather a passive device which can provide you with trusted/secure services. In general a root of trust is the first piece of *non-modifiable* code that runs on a platform which is BootROM that establishes the chain of trust via verifying the first stage boot-loader which in turn continues the chain of trust to next boot stages and so on.
I think there is a distinction to be made between useful platforms for development where most of the functionality required for secure boot should be usable, and actual secure platforms that have the needed hardware characteristics.
EBBR should account for RPi and similar because it is a very convenient development platform, but there are very few security requirements that can be guaranteed.
What do you think of a security addendum or checklist that goes alongside EBBR to detail what is required to make the platform actually secure? EBBR proper can specify the functional interfaces, but security certification is outside EBBR scope.
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 Tue, May 19, 2020 at 05:51:41PM +0100, Grant Likely wrote:
On 12/03/2020 04:58, Sumit Garg wrote:
On Thu, 12 Mar 2020 at 03:11, Francois Ozog francois.ozog@linaro.org wrote:
Le mer. 11 mars 2020 à 22:22, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
On 3/11/20 12:10 PM, Daniel Thompson wrote:
On Tue, Mar 10, 2020 at 06:34:35PM +0100, Francois Ozog wrote:
On Tue, 10 Mar 2020 at 18:19, Daniel Thompson <
daniel.thompson@linaro.org>
wrote:
> On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote: > > 0.1 - EBBR goal > > May be a reassessment on the "for what" the specification is built. > > > > Following all the discussions with prominent industry players, I start > > to think that limiting the constraints to be EBBR compliant may become > > counter productive. There will be both EBBR non compliant and EBBR > > compliant systems. This is inevitable. But EBBR exist for a number of > > use cases in a number of markets. The value of EBBR is consistent > > behavior across those. > > > > Maximising number of EBBR compliant systems without stating use case > > parameters ( "why" and "for what") may not be the best goal. > > > > Out of things to be more explicit are supported secure boot flows > > (with/without shim+grub or direct). Some vendors require shim+grub > > while industry players want the exact opposite: nothing but UEFI. This > > drivers a number of requirements in terms of UEFI protocols needed > > We have resisted levels in EBBR until now but this might be where might > have a need for them. > > Put another way I agree that getting explicit about mandatory features > for secure boot flows is useful. > > However I also think that is remains valuable to define best practice > for how firmware and OS interact on systems that have not implemented > secure boot. > > It's all about the target use:
- industrial (manufacturing, automotive, robotics, medical...)
components
- telecom edge
- 96boards
- developer desktop
- server
As I just consider 1 and 2, I have no case without secure boot... Now the dev platform can come without the secureboot active and SElinx deactivated.... In what context you think this is usefull?
I would like it to be possible for dev boards and SoMs whose SoCs do not have a built-in root of trust to have some basic level of EBBR compliance.
I don't like to optics of saying "this standard cannot possibly apply to a Raspberry Pi"[1]. Taking the RPi Zero or CM3 as examples[2], I can't
see any
value added by secure boot since the root-of-trust would have to start on the same media as the operating system anyway.
There is a TPMv2 module available for Raspberries.
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module?v...
Would we be able to use this as root of trust?
AFAIK, TPM in itself can't act as a root of trust. It is rather a passive device which can provide you with trusted/secure services. In general a root of trust is the first piece of *non-modifiable* code that runs on a platform which is BootROM that establishes the chain of trust via verifying the first stage boot-loader which in turn continues the chain of trust to next boot stages and so on.
I think there is a distinction to be made between useful platforms for development where most of the functionality required for secure boot should be usable, and actual secure platforms that have the needed hardware characteristics.
EBBR should account for RPi and similar because it is a very convenient development platform, but there are very few security requirements that can be guaranteed.
What do you think of a security addendum or checklist that goes alongside EBBR to detail what is required to make the platform actually secure? EBBR proper can specify the functional interfaces, but security certification is outside EBBR scope.
I like the addendum approach.
I'm also happy for conditional dependancies on the security features to become part of the requirements: if platform provides XXX then it must implement YYY.
It is only mandatory requirements that are hard to met on common dev boards that are a problem for me.
Daniel.
On Tue, 19 May 2020 at 22:21, Grant Likely grant.likely@arm.com wrote:
On 12/03/2020 04:58, Sumit Garg wrote:
On Thu, 12 Mar 2020 at 03:11, Francois Ozog francois.ozog@linaro.org wrote:
Le mer. 11 mars 2020 à 22:22, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
On 3/11/20 12:10 PM, Daniel Thompson wrote:
On Tue, Mar 10, 2020 at 06:34:35PM +0100, Francois Ozog wrote:
On Tue, 10 Mar 2020 at 18:19, Daniel Thompson <
daniel.thompson@linaro.org>
wrote:
> On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote: >> 0.1 - EBBR goal >> May be a reassessment on the "for what" the specification is built. >> >> Following all the discussions with prominent industry players, I start >> to think that limiting the constraints to be EBBR compliant may become >> counter productive. There will be both EBBR non compliant and EBBR >> compliant systems. This is inevitable. But EBBR exist for a number of >> use cases in a number of markets. The value of EBBR is consistent >> behavior across those. >> >> Maximising number of EBBR compliant systems without stating use case >> parameters ( "why" and "for what") may not be the best goal. >> >> Out of things to be more explicit are supported secure boot flows >> (with/without shim+grub or direct). Some vendors require shim+grub >> while industry players want the exact opposite: nothing but UEFI. This >> drivers a number of requirements in terms of UEFI protocols needed > > We have resisted levels in EBBR until now but this might be where might > have a need for them. > > Put another way I agree that getting explicit about mandatory features > for secure boot flows is useful. > > However I also think that is remains valuable to define best practice > for how firmware and OS interact on systems that have not implemented > secure boot. > > It's all about the target use:
- industrial (manufacturing, automotive, robotics, medical...)
components
- telecom edge
- 96boards
- developer desktop
- server
As I just consider 1 and 2, I have no case without secure boot... Now the dev platform can come without the secureboot active and SElinx deactivated.... In what context you think this is usefull?
I would like it to be possible for dev boards and SoMs whose SoCs do not have a built-in root of trust to have some basic level of EBBR compliance.
I don't like to optics of saying "this standard cannot possibly apply to a Raspberry Pi"[1]. Taking the RPi Zero or CM3 as examples[2], I can't
see any
value added by secure boot since the root-of-trust would have to start on the same media as the operating system anyway.
There is a TPMv2 module available for Raspberries.
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module?v...
Would we be able to use this as root of trust?
AFAIK, TPM in itself can't act as a root of trust. It is rather a passive device which can provide you with trusted/secure services. In general a root of trust is the first piece of *non-modifiable* code that runs on a platform which is BootROM that establishes the chain of trust via verifying the first stage boot-loader which in turn continues the chain of trust to next boot stages and so on.
I think there is a distinction to be made between useful platforms for development where most of the functionality required for secure boot should be usable, and actual secure platforms that have the needed hardware characteristics.
EBBR should account for RPi and similar because it is a very convenient development platform, but there are very few security requirements that can be guaranteed.
What do you think of a security addendum or checklist that goes alongside EBBR to detail what is required to make the platform actually secure?
I would be in favour of such a security addendum.
IMO, "make the platform actually secure" has a bit wider scope than just secure boot. And the scope may vary depending on the threat model which may be specific to a particular use-case. So I will try to list down security features along with their requirements as follows. Please feel free to extend this list in case I missed any relevant security feature:
Feature: Secure boot Platform requirements: - BootROM being the Root of Trust for Secure boot shall initiate the chain of trust via verifying the first stage boot-loader. - Provide platform binding of the root public key used for verification.
Feature: Anti-rollback protection Platform requirements: - BootROM shall provide anti-rollback protection for first stage boot-loader updates.
Feature: Unbrickable firmware updates Platform requirements: - BootROM shall support A/B partition scheme to load first stage boot-loader from alternate locations.
Feature: Secure storage Platform requirements: - Either provide a dedicated non-volatile memory accessible to secure world only or provide a RPMB based secure storage. - Provide a Hardware Unique Key (HUK) which is accessible to the secure world only.
Feature: Secure entropy source Platform requirements: - Provide a hardware entropy source which is accessible to secure world only.
Feature: Memory firewalls / TZASC Platform requirements: - Provide a way to carve out DRAM so that it's accessible to the secure world only.
Feature: Secure peripherals / TZPC Platform requirements: - Provide a way to partition peripherals so that secure peripherals are accessible to secure world only.
-Sumit
EBBR proper can specify the functional interfaces, but security certification is outside EBBR scope.
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 21/05/2020 07:58, Sumit Garg wrote:
On Tue, 19 May 2020 at 22:21, Grant Likely grant.likely@arm.com wrote:
On 12/03/2020 04:58, Sumit Garg wrote:
On Thu, 12 Mar 2020 at 03:11, Francois Ozog francois.ozog@linaro.org wrote:
Le mer. 11 mars 2020 à 22:22, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
On 3/11/20 12:10 PM, Daniel Thompson wrote:
On Tue, Mar 10, 2020 at 06:34:35PM +0100, Francois Ozog wrote: > On Tue, 10 Mar 2020 at 18:19, Daniel Thompson <
daniel.thompson@linaro.org>
> wrote: > >> On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote: >>> 0.1 - EBBR goal >>> May be a reassessment on the "for what" the specification is built. >>> >>> Following all the discussions with prominent industry players, I start >>> to think that limiting the constraints to be EBBR compliant may become >>> counter productive. There will be both EBBR non compliant and EBBR >>> compliant systems. This is inevitable. But EBBR exist for a number of >>> use cases in a number of markets. The value of EBBR is consistent >>> behavior across those. >>> >>> Maximising number of EBBR compliant systems without stating use case >>> parameters ( "why" and "for what") may not be the best goal. >>> >>> Out of things to be more explicit are supported secure boot flows >>> (with/without shim+grub or direct). Some vendors require shim+grub >>> while industry players want the exact opposite: nothing but UEFI. This >>> drivers a number of requirements in terms of UEFI protocols needed >> >> We have resisted levels in EBBR until now but this might be where might >> have a need for them. >> >> Put another way I agree that getting explicit about mandatory features >> for secure boot flows is useful. >> >> However I also think that is remains valuable to define best practice >> for how firmware and OS interact on systems that have not implemented >> secure boot. >> >> It's all about the target use: > 1) industrial (manufacturing, automotive, robotics, medical...)
components
> 2) telecom edge > 3) 96boards > 4) developer desktop > 5) server > > As I just consider 1 and 2, I have no case without secure boot... > Now the dev platform can come without the secureboot active and > SElinx deactivated.... > In what context you think this is usefull?
I would like it to be possible for dev boards and SoMs whose SoCs do not have a built-in root of trust to have some basic level of EBBR compliance.
I don't like to optics of saying "this standard cannot possibly apply to a Raspberry Pi"[1]. Taking the RPi Zero or CM3 as examples[2], I can't
see any
value added by secure boot since the root-of-trust would have to start on the same media as the operating system anyway.
There is a TPMv2 module available for Raspberries.
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module?v...
Would we be able to use this as root of trust?
AFAIK, TPM in itself can't act as a root of trust. It is rather a passive device which can provide you with trusted/secure services. In general a root of trust is the first piece of *non-modifiable* code that runs on a platform which is BootROM that establishes the chain of trust via verifying the first stage boot-loader which in turn continues the chain of trust to next boot stages and so on.
I think there is a distinction to be made between useful platforms for development where most of the functionality required for secure boot should be usable, and actual secure platforms that have the needed hardware characteristics.
EBBR should account for RPi and similar because it is a very convenient development platform, but there are very few security requirements that can be guaranteed.
What do you think of a security addendum or checklist that goes alongside EBBR to detail what is required to make the platform actually secure?
I would be in favour of such a security addendum.
IMO, "make the platform actually secure" has a bit wider scope than just secure boot. And the scope may vary depending on the threat model which may be specific to a particular use-case. So I will try to list down security features along with their requirements as follows. Please feel free to extend this list in case I missed any relevant security feature:
Feature: Secure boot Platform requirements:
- BootROM being the Root of Trust for Secure boot shall initiate the
chain of trust via verifying the first stage boot-loader.
- Provide platform binding of the root public key used for verification.
Feature: Anti-rollback protection Platform requirements:
- BootROM shall provide anti-rollback protection for first stage
boot-loader updates.
Feature: Unbrickable firmware updates Platform requirements:
- BootROM shall support A/B partition scheme to load first stage
boot-loader from alternate locations.
Feature: Secure storage Platform requirements:
- Either provide a dedicated non-volatile memory accessible to secure
world only or provide a RPMB based secure storage.
- Provide a Hardware Unique Key (HUK) which is accessible to the
secure world only.
Feature: Secure entropy source Platform requirements:
- Provide a hardware entropy source which is accessible to secure world only.
Feature: Memory firewalls / TZASC Platform requirements:
- Provide a way to carve out DRAM so that it's accessible to the
secure world only.
Feature: Secure peripherals / TZPC Platform requirements:
- Provide a way to partition peripherals so that secure peripherals
are accessible to secure world only.
-Sumit
Added as issue on github:
https://github.com/ARM-software/ebbr/issues/47
g.
On 3/10/20 5:02 PM, Francois Ozog wrote:
Hi,
Following implementation (or work towards) of EBBR 1.0 + UEFI Secure boot + UEFI update capsule we learnt a lot.
Here are some topics that may need some clarification on the EBBR specs and It looks timely to start working on EBBR evolution.
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
EBBR 1.0 is quite vague about this point.
Implementing the requirements of version 1.0 was enough to allow systems to be booted in a common way. Secure boot is not supported by what is required.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
Shim and GRUB are optional tools which operating systems like BSD, Linux or Windows do not need for booting. I think the EBBR should be operating system agnostic.
This does not deny the usefulness of some of these tools. My personal favorite is booting via U-Boot -> iPXE -> GRUB -> Linux from an iSCSI drive ;)
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The language need to be explicit.
A reference to RFC 2119 should be added to the EBBR.
I - protective offsets EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that "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."
StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without the variable rework done and update capsules. 4MB seems the minimum. 8MB to get margin and 16MB for A/B scheme.
EBBR same paragraph also states: "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. Manual partitioning tools should provide warnings when modifying protective partitions or creating partitions within the first 1MiB."
is it expected that Linaro upstreams changes in installation tools, partition tools to conform to this (with updated to be agreed minimum)?
Obviously the minimum required space depends on the firmware and the maximum depends on the hardware (some devices like routers simply only have 16MiB flash for firmware and operating system in total).
Shouldn't the firmware have a way to tell the OS how much space it wants instead of prescribing a fixed quantity?
II - identifying partitions Having two EFI partitions defined with EFI_GUID need a precise behaviour defined: boot with first or boot with second.
This is only relevant when relying on the \EFI\BOOT directory. If Bootxxxx variables are defined, these specify the relevant partition.
Shall we have a EFI_GUID_ALT defined for A/B partition schemes? If not, the BootXXX variables should be used as selector? We lean towards BootXXX variables and not defining a new GUID. But this would mean explicit behavior to be stated in case of lack of BootXXX.
I think GPT volume mirroring should be used in conjunction with A/B: A/B to recover version failures with current hardware, surrounding software; mirroring to protect against storage failures.
Is there any recommendation on mirrored EFI volumes handling ?
Isn't the availability of Bootxxxx variables enough?
III - 32 bits are there any 32 bits specific considerations to be added?
The only thing 32bit specific that comes to my mind is clearing architecture specific caches as defined in the UEFI spec.
For RISC-V there is a development ongoing for communicating the boot hart ID form the firmware to the operating system.
IV - UEFI_RNG_PROTOCOL Following my view in 0) I think this shall be made mandatory
EBBR v1.0 has as design goal: 'Design for common embedded target'. "Generally anything that has a near near-upstream U-Boot implementation should be able to implement the EBBR requirements."
Not all common SoCs have a hardware RNG, e.g. Allwinner (cf. https://linux-sunxi.org/Cryptographic_Hardware_Accelerators).
I would not assume that enough entropy can be gathered by the firmware on a standalone device without a hardware RNG to drive the EFI_RNG_PROTOCOL.
A high entropy RNG is needed for secure network communication. It can be used for randomizing kernel memory layout. But why should it be made mandatory for devices that do not need network communication before the operating system is started?
Linaro has upstreamed this in U-Boot and started to implement additional hardware drivers. KASLR is thus functional in 64 bits and will be in 32bits.
V - UEFI SecureBoot Following my view in 0) I think this shall be made mandatory
UEFI SecureBoot is not mentioned in section 2.6 so we need to clarify what needs to be implemented. In particular, we need to implement EFI_LOAD_FILE2_PROTOCOL for initrd signature checking.
The protocol (without checking) is implemented in U-Boot 2020.04. But we should also consider the device-tree and the command line.
VI - UEFI update capsules Following my view in 0) I think this shall be made mandatory
The UEFI specification provides multiple possibilities to update:
UpdateCapsule() runtime service - This runtime service is quite hard to implement if there is no storage that is off limits for the operating system.
Directory \EFI\UpdateCapsule - A file placed on this directory on the boot device is considered a capsule. This is much easier to implement.
Essentially you could also use BootNext to run any binary for updating.
I suggest to go for the directory method of capsule updating.
Section 2.6 of UEFI spec 2.7 mentions At some point in time we will need to propose UEFI specification update for:
- anti-bricking anti rollback expected behavior
- abstract capsules for "start transaction", "commit", "rollback" when
we will be dealing with system wide transactional updates. There is probably a lot to state here but I am just starting the discussion.
VII - UEFI watchdog Following my view in 0) I think this shall be made mandatory
I could imagine the following scenarios where a watchdog is helpful:
* A/B scenario: this would require a variable to be updated that switches between A and B * booting via network (retry)
Watchdogs are available both in EDK II and U-Boot.
Best regards
Heinrich
In addition to its definition, it should also integrate consistent parameters to define total duration covered as well as number of failed consecutive updates to be triggered as well as how it is delivered (powercycle, NMI, secureIRQ...)
Cheers
Le mar. 10 mars 2020 à 21:15, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
On 3/10/20 5:02 PM, Francois Ozog wrote:
Hi,
Following implementation (or work towards) of EBBR 1.0 + UEFI Secure boot + UEFI update capsule we learnt a lot.
Here are some topics that may need some clarification on the EBBR specs and It looks timely to start working on EBBR evolution.
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
EBBR 1.0 is quite vague about this point.
Implementing the requirements of version 1.0 was enough to allow systems to be booted in a common way. Secure boot is not supported by what is required.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
Shim and GRUB are optional tools which operating systems like BSD, Linux or Windows do not need for booting. I think the EBBR should be operating system agnostic.
Absolutely.
This does not deny the usefulness of some of these tools. My personal favorite is booting via U-Boot -> iPXE -> GRUB -> Linux from an iSCSI drive ;)
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The language need to be explicit.
A reference to RFC 2119 should be added to the EBBR.
I - protective offsets EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that "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."
StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without the variable rework done and update capsules. 4MB seems the minimum. 8MB to get margin and 16MB for A/B scheme.
EBBR same paragraph also states: "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. Manual partitioning tools should provide warnings when modifying protective partitions or creating partitions within the first 1MiB."
is it expected that Linaro upstreams changes in installation tools, partition tools to conform to this (with updated to be agreed minimum)?
Obviously the minimum required space depends on the firmware and the maximum depends on the hardware (some devices like routers simply only have 16MiB flash for firmware and operating system in total).
Shouldn't the firmware have a way to tell the OS how much space it wants instead of prescribing a fixed quantity?
probably a good idea. It’s never good to take margin of margin (16MB) to end up being cornered a few years later.
II - identifying partitions Having two EFI partitions defined with EFI_GUID need a precise behaviour defined: boot with first or boot with second.
This is only relevant when relying on the \EFI\BOOT directory. If Bootxxxx variables are defined, these specify the relevant partition.
Shall we have a EFI_GUID_ALT defined for A/B partition schemes? If not, the BootXXX variables should be used as selector? We lean towards BootXXX variables and not defining a new GUID. But this would mean explicit behavior to be stated in case of lack of BootXXX.
I think GPT volume mirroring should be used in conjunction with A/B: A/B to recover version failures with current hardware, surrounding software; mirroring to protect against storage failures.
Is there any recommendation on mirrored EFI volumes handling ?
Isn't the availability of Bootxxxx variables enough?
I think so. There is a forming thinking that when we commit a partition for successful update the other is “synchronized”.
That said mirroring in UEFI is a block mirroring between two physical disk (is it software RAID1?) so both A/B and RAID1 can be combined . But I don’t know what shall be uboot behavior here.
III - 32 bits are there any 32 bits specific considerations to be added?
The only thing 32bit specific that comes to my mind is clearing architecture specific caches as defined in the UEFI spec.
For RISC-V there is a development ongoing for communicating the boot hart ID form the firmware to the operating system.
Just thought of: we also bumped into lpae support problem. We ended up experimenting a “standard” variable set by the platform so that distro_bootcmd just use the right image. May be something to clarify at least at Uboot but I wonder how to properly phrase a requirement around the topic.
IV - UEFI_RNG_PROTOCOL Following my view in 0) I think this shall be made mandatory
EBBR v1.0 has as design goal: 'Design for common embedded target'. "Generally anything that has a near near-upstream U-Boot implementation should be able to implement the EBBR requirements."
Not all common SoCs have a hardware RNG, e.g. Allwinner (cf. https://linux-sunxi.org/Cryptographic_Hardware_Accelerators).
I would not assume that enough entropy can be gathered by the firmware on a standalone device without a hardware RNG to drive the EFI_RNG_PROTOCOL.
A high entropy RNG is needed for secure network communication. It can be used for randomizing kernel memory layout. But why should it be made mandatory for devices that do not need network communication before the operating system is started?
Good point. I am too focused on connected edge devices. The good thing is the lack of support does not influence the distro content. So probably not a candidate for being in EBBR.
Linaro has upstreamed this in U-Boot and started to implement additional hardware drivers. KASLR is thus functional in 64 bits and will be in 32bits.
V - UEFI SecureBoot Following my view in 0) I think this shall be made mandatory
UEFI SecureBoot is not mentioned in section 2.6 so we need to clarify what needs to be implemented. In particular, we need to implement EFI_LOAD_FILE2_PROTOCOL for initrd signature checking.
The protocol (without checking) is implemented in U-Boot 2020.04. But we should also consider the device-tree and the command line.
VI - UEFI update capsules Following my view in 0) I think this shall be made mandatory
The UEFI specification provides multiple possibilities to update:
UpdateCapsule() runtime service - This runtime service is quite hard to implement if there is no storage that is off limits for the operating system.
We do not favor that. There is no way to trust code that could have been compromised in memory. It would mean doing an update of uboot from OPTEE so it does not look good as only uboot of a platform knows how to update itself.
Directory \EFI\UpdateCapsule - A file placed on this directory on the boot device is considered a capsule. This is much easier to implement.
Essentially you could also use BootNext to run any binary for updating.
I suggest to go for the directory method of capsule updating.
That’s the goal for the moment. Yet a whole bunch new to be clarified. We are working on a document to be commented.
Section 2.6 of UEFI spec 2.7 mentions At some point in time we will need to propose UEFI specification update
for:
- anti-bricking anti rollback expected behavior
- abstract capsules for "start transaction", "commit", "rollback" when
we will be dealing with system wide transactional updates. There is probably a lot to state here but I am just starting the
discussion.
VII - UEFI watchdog Following my view in 0) I think this shall be made mandatory
I could imagine the following scenarios where a watchdog is helpful:
- A/B scenario: this would require a variable to be updated that switches between A and B
- booting via network (retry)
Yes: would you consider HTTP booting as an option (not in EBBR though but in Uboot)?
Watchdogs are available both in EDK II and U-Boot.
Problem is that a leading industrial OEM reported inconsistency in implementation and too small (5 minutes) delay . The exact problem yet need to be fully described by the vendor so that it be solved.
Best regards
Heinrich
In addition to its definition, it should also integrate consistent parameters to define total duration covered as well as number of failed consecutive updates to be triggered as well as how it is delivered (powercycle, NMI, secureIRQ...)
Cheers
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 3/10/20 9:45 PM, Francois Ozog wrote:
Le mar. 10 mars 2020 à 21:15, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
On 3/10/20 5:02 PM, Francois Ozog wrote:
Hi,
Following implementation (or work towards) of EBBR 1.0 + UEFI Secure boot + UEFI update capsule we learnt a lot.
Here are some topics that may need some clarification on the EBBR specs and It looks timely to start working on EBBR evolution.
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
EBBR 1.0 is quite vague about this point.
Implementing the requirements of version 1.0 was enough to allow systems to be booted in a common way. Secure boot is not supported by what is required.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
Shim and GRUB are optional tools which operating systems like BSD, Linux or Windows do not need for booting. I think the EBBR should be operating system agnostic.
Absolutely.
This does not deny the usefulness of some of these tools. My personal favorite is booting via U-Boot -> iPXE -> GRUB -> Linux from an iSCSI drive ;)
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The language need to be explicit.
A reference to RFC 2119 should be added to the EBBR.
I - protective offsets EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that "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."
StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without the variable rework done and update capsules. 4MB seems the minimum. 8MB to get margin and 16MB for A/B scheme.
EBBR same paragraph also states: "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. Manual partitioning tools should provide warnings when modifying protective partitions or creating partitions within the first 1MiB."
is it expected that Linaro upstreams changes in installation tools, partition tools to conform to this (with updated to be agreed minimum)?
Obviously the minimum required space depends on the firmware and the maximum depends on the hardware (some devices like routers simply only have 16MiB flash for firmware and operating system in total).
Shouldn't the firmware have a way to tell the OS how much space it wants instead of prescribing a fixed quantity?
probably a good idea. It’s never good to take margin of margin (16MB) to end up being cornered a few years later.
II - identifying partitions Having two EFI partitions defined with EFI_GUID need a precise behaviour defined: boot with first or boot with second.
This is only relevant when relying on the \EFI\BOOT directory. If Bootxxxx variables are defined, these specify the relevant partition.
Shall we have a EFI_GUID_ALT defined for A/B partition schemes? If not, the BootXXX variables should be used as selector? We lean towards BootXXX variables and not defining a new GUID. But this would mean explicit behavior to be stated in case of lack of BootXXX.
I think GPT volume mirroring should be used in conjunction with A/B: A/B to recover version failures with current hardware, surrounding software; mirroring to protect against storage failures.
Is there any recommendation on mirrored EFI volumes handling ?
Isn't the availability of Bootxxxx variables enough?
I think so. There is a forming thinking that when we commit a partition for successful update the other is “synchronized”.
That said mirroring in UEFI is a block mirroring between two physical disk (is it software RAID1?) so both A/B and RAID1 can be combined . But I don’t know what shall be uboot behavior here.
III - 32 bits are there any 32 bits specific considerations to be added?
The only thing 32bit specific that comes to my mind is clearing architecture specific caches as defined in the UEFI spec.
For RISC-V there is a development ongoing for communicating the boot hart ID form the firmware to the operating system.
Just thought of: we also bumped into lpae support problem. We ended up experimenting a “standard” variable set by the platform so that distro_bootcmd just use the right image. May be something to clarify at least at Uboot but I wonder how to properly phrase a requirement around the topic.
U-Boot's current distro boot command is not meant to make an image choice.
In U-Boot we have CONFIG_ARMV7_LPAE. That value could be copied to an environment variable for usage in a script.
An installer could use the device tree to determine the CPU's compatible string to decide which image is supported, e.g.
compatible = "arm,arm1176jzf-s" - no LPAE support compatible = "arm,cortex-a7" - LPAE support
As we are talking about device-tree. The configuration table GUID for the device-tree should be put into either the EBBR or the UEFI spec.
IV - UEFI_RNG_PROTOCOL Following my view in 0) I think this shall be made mandatory
EBBR v1.0 has as design goal: 'Design for common embedded target'. "Generally anything that has a near near-upstream U-Boot implementation should be able to implement the EBBR requirements."
Not all common SoCs have a hardware RNG, e.g. Allwinner (cf. https://linux-sunxi.org/Cryptographic_Hardware_Accelerators).
I would not assume that enough entropy can be gathered by the firmware on a standalone device without a hardware RNG to drive the EFI_RNG_PROTOCOL.
A high entropy RNG is needed for secure network communication. It can be used for randomizing kernel memory layout. But why should it be made mandatory for devices that do not need network communication before the operating system is started?
Good point. I am too focused on connected edge devices. The good thing is the lack of support does not influence the distro content. So probably not a candidate for being in EBBR.
Linaro has upstreamed this in U-Boot and started to implement additional hardware drivers. KASLR is thus functional in 64 bits and will be in 32bits.
V - UEFI SecureBoot Following my view in 0) I think this shall be made mandatory
UEFI SecureBoot is not mentioned in section 2.6 so we need to clarify what needs to be implemented. In particular, we need to implement EFI_LOAD_FILE2_PROTOCOL for initrd signature checking.
The protocol (without checking) is implemented in U-Boot 2020.04. But we should also consider the device-tree and the command line.
VI - UEFI update capsules Following my view in 0) I think this shall be made mandatory
The UEFI specification provides multiple possibilities to update:
UpdateCapsule() runtime service - This runtime service is quite hard to implement if there is no storage that is off limits for the operating system.
We do not favor that. There is no way to trust code that could have been compromised in memory. It would mean doing an update of uboot from OPTEE so it does not look good as only uboot of a platform knows how to update itself.
Directory \EFI\UpdateCapsule - A file placed on this directory on the boot device is considered a capsule. This is much easier to implement.
Essentially you could also use BootNext to run any binary for updating.
I suggest to go for the directory method of capsule updating.
That’s the goal for the moment. Yet a whole bunch new to be clarified. We are working on a document to be commented.
Section 2.6 of UEFI spec 2.7 mentions At some point in time we will need to propose UEFI specification update
for:
- anti-bricking anti rollback expected behavior
- abstract capsules for "start transaction", "commit", "rollback" when
we will be dealing with system wide transactional updates. There is probably a lot to state here but I am just starting the
discussion.
VII - UEFI watchdog Following my view in 0) I think this shall be made mandatory
I could imagine the following scenarios where a watchdog is helpful:
- A/B scenario: this would require a variable to be updated that switches between A and B
- booting via network (retry)
Yes: would you consider HTTP booting as an option (not in EBBR though but in Uboot)?
U-Boot does not have a TCP stack. But you can load iPXE to boot via HTTP(S).
Watchdogs are available both in EDK II and U-Boot.
Problem is that a leading industrial OEM reported inconsistency in implementation and too small (5 minutes) delay . The exact problem yet need to be fully described by the vendor so that it be solved.
Five minutes is a default. SetWatchdogTimer() can be used to modify the interval. A timer event can be used to reset the watchdog timer periodically by calling SetWatchdogTimer().
I could imagine that flashing a new image might take more than five minutes. So maybe you want to reset the watchdog timer whenever a block has been written to flash.
In U-Boot we have two watchdogs. The hardware one is reset at boot time whenever an event is handled (see efi_timer_check()). The UEFI one starts with a five minute default but considers changes by SetWatchdogTimer().
Best regards
Heinrich
In addition to its definition, it should also integrate consistent parameters to define total duration covered as well as number of failed consecutive updates to be triggered as well as how it is delivered (powercycle, NMI, secureIRQ...)
Cheers
On 10/03/2020 22:19, Heinrich Schuchardt wrote:
On 3/10/20 9:45 PM, Francois Ozog wrote:
Le mar. 10 mars 2020 à 21:15, Heinrich Schuchardt xypron.glpk@gmx.de a
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The language need to be explicit.
A reference to RFC 2119 should be added to the EBBR.
https://github.com/ARM-software/ebbr/issues/46
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.
Regarding capsule update,
On Tue, Mar 10, 2020 at 09:45:28PM +0100, Francois Ozog wrote:
Le mar. 10 mars 2020 à 21:15, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
On 3/10/20 5:02 PM, Francois Ozog wrote:
(snip)
VI - UEFI update capsules Following my view in 0) I think this shall be made mandatory
The UEFI specification provides multiple possibilities to update:
UpdateCapsule() runtime service - This runtime service is quite hard to implement if there is no storage that is off limits for the operating system.
We do not favor that. There is no way to trust code that could have been compromised in memory.
I'm not sure of the point here, but UpdateCapsule has ability of verifying a capsule file, and so as long as the system is securely booted, UpdateCapsule should work as expected. The issue is, as Heinrich suggested, that we can't assume an "exclusive" access to the device on which firmware resides akin to a problem in SetVariable at runtime.
It would mean doing an update of uboot from OPTEE so it does not look good as only uboot of a platform knows how to update itself.
Directory \EFI\UpdateCapsule - A file placed on this directory on the boot device is considered a capsule. This is much easier to implement.
Essentially you could also use BootNext to run any binary for updating.
I suggest to go for the directory method of capsule updating.
That’s the goal for the moment. Yet a whole bunch new to be clarified. We are working on a document to be commented.
As some of you may know, I'm going to submit a RFC patch series for UEFI capsule support on U-Boot in a week or so (maybe). With this patch, we will support "Capsule-on-Disk" only (but without authentication implemented).
One of my concerns here is about "variable update via a capsule" as an alternative of "SetVariable at runtime," where values to be set for variables will be exported as a capsule file and all the updates will take place after rebooting. This is very useful on systems where SetVariable is not available at runtime for some reasons. Some idea has been proposed by Peter[1], but the discussion has been stalled for a long time.
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.htm...
Thanks, -Takahiro Akashi
Section 2.6 of UEFI spec 2.7 mentions At some point in time we will need to propose UEFI specification update
for:
- anti-bricking anti rollback expected behavior
- abstract capsules for "start transaction", "commit", "rollback" when
we will be dealing with system wide transactional updates. There is probably a lot to state here but I am just starting the
discussion.
VII - UEFI watchdog Following my view in 0) I think this shall be made mandatory
I could imagine the following scenarios where a watchdog is helpful:
- A/B scenario: this would require a variable to be updated that switches between A and B
- booting via network (retry)
Yes: would you consider HTTP booting as an option (not in EBBR though but in Uboot)?
Watchdogs are available both in EDK II and U-Boot.
Problem is that a leading industrial OEM reported inconsistency in implementation and too small (5 minutes) delay . The exact problem yet need to be fully described by the vendor so that it be solved.
Best regards
Heinrich
In addition to its definition, it should also integrate consistent parameters to define total duration covered as well as number of failed consecutive updates to be triggered as well as how it is delivered (powercycle, NMI, secureIRQ...)
Cheers
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.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Wed, 11 Mar 2020 at 07:55, AKASHI Takahiro takahiro.akashi@linaro.org wrote:
Regarding capsule update,
On Tue, Mar 10, 2020 at 09:45:28PM +0100, Francois Ozog wrote:
Le mar. 10 mars 2020 à 21:15, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
On 3/10/20 5:02 PM, Francois Ozog wrote:
(snip)
VI - UEFI update capsules Following my view in 0) I think this shall be made mandatory
The UEFI specification provides multiple possibilities to update:
UpdateCapsule() runtime service - This runtime service is quite hard to implement if there is no storage that is off limits for the operating system.
We do not favor that. There is no way to trust code that could have been compromised in memory.
I'm not sure of the point here, but UpdateCapsule has ability of verifying a capsule file, and so as long as the system is securely booted, UpdateCapsule should work as expected. The issue is, as Heinrich suggested, that we can't assume an "exclusive" access to the device on which firmware resides akin to a problem in SetVariable at runtime.
Sorry, my point was not valid. Let's check all cases.
If the storage is accessible from untrusted world: - single storage for firmware and the OS: we can't orchestrate access to storage between OS and Firmware. - dedicated storage for firmware (eMMC for firmware, SSD for OS): exclusive access can be achieved (not mounted by LInux and no common controller), we may be able to avoid one boot cycle and do the update directly.
If the storage is only accessible from TrustZone, the update is conducted
by TrustZone code which has exclusive access to device, so update can happen at runtime. We don't want to work on this at this stage. And may be not in the long term: I think this is a vendor opportunity to differentiate and it feels way too complex to make it generic.
It would mean doing an update of uboot from OPTEE so it does not look good as only uboot of a platform knows how to update itself.
Directory \EFI\UpdateCapsule - A file placed on this directory on the boot device is considered a capsule. This is much easier to implement.
Essentially you could also use BootNext to run any binary for updating.
I suggest to go for the directory method of capsule updating.
That’s the goal for the moment. Yet a whole bunch new to be clarified. We are working on a document to be commented.
As some of you may know, I'm going to submit a RFC patch series for UEFI capsule support on U-Boot in a week or so (maybe). With this patch, we will support "Capsule-on-Disk" only (but without authentication implemented).
One of my concerns here is about "variable update via a capsule" as an alternative of "SetVariable at runtime," where values to be set for variables will be exported as a capsule file and all the updates will take place after rebooting. This is very useful on systems where SetVariable is not available at runtime for some reasons. Some idea has been proposed by Peter[1], but the discussion has been stalled for a long time.
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.htm...
Thanks, -Takahiro Akashi
Section 2.6 of UEFI spec 2.7 mentions At some point in time we will need to propose UEFI specification
update
for:
- anti-bricking anti rollback expected behavior
- abstract capsules for "start transaction", "commit", "rollback"
when
we will be dealing with system wide transactional updates. There is probably a lot to state here but I am just starting the
discussion.
VII - UEFI watchdog Following my view in 0) I think this shall be made mandatory
I could imagine the following scenarios where a watchdog is helpful:
- A/B scenario: this would require a variable to be updated that switches between A and B
- booting via network (retry)
Yes: would you consider HTTP booting as an option (not in EBBR though but in Uboot)?
Watchdogs are available both in EDK II and U-Boot.
Problem is that a leading industrial OEM reported inconsistency in implementation and too small (5 minutes) delay . The exact problem yet
need
to be fully described by the vendor so that it be solved.
Best regards
Heinrich
In addition to its definition, it should also integrate consistent parameters to define total duration covered as well as number of failed consecutive updates to be triggered as well as how it is delivered (powercycle, NMI, secureIRQ...)
Cheers
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.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Akashi-san
On Wed, Mar 11, 2020 at 03:56:53PM +0900, AKASHI Takahiro wrote:
Regarding capsule update,
[...]
As some of you may know, I'm going to submit a RFC patch series for UEFI capsule support on U-Boot in a week or so (maybe). With this patch, we will support "Capsule-on-Disk" only (but without authentication implemented).
One of my concerns here is about "variable update via a capsule" as an alternative of "SetVariable at runtime," where values to be set for variables will be exported as a capsule file and all the updates will take place after rebooting. This is very useful on systems where SetVariable is not available at runtime for some reasons.
Sure that's really useful and that's the direction we decided to follow.
Some idea has been proposed by Peter[1], but the discussion has been stalled for a long time.
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.htm...
We hope to allocate some resources and work on it in the following months, so we'll revive this thread once we do. Thanks for the pointers.
Regards /Ilias
Akashi-san,
On Wed, Mar 11, 2020 at 03:56:53PM +0900, AKASHI Takahiro wrote:
Regarding capsule update,
On Tue, Mar 10, 2020 at 09:45:28PM +0100, Francois Ozog wrote:
[...]
Directory \EFI\UpdateCapsule - A file placed on this directory on the boot device is considered a capsule. This is much easier to implement.
Essentially you could also use BootNext to run any binary for updating.
I suggest to go for the directory method of capsule updating.
That’s the goal for the moment. Yet a whole bunch new to be clarified. We are working on a document to be commented.
As some of you may know, I'm going to submit a RFC patch series for UEFI capsule support on U-Boot in a week or so (maybe). With this patch, we will support "Capsule-on-Disk" only (but without authentication implemented).
One of my concerns here is about "variable update via a capsule" as an alternative of "SetVariable at runtime," where values to be set for variables will be exported as a capsule file and all the updates will take place after rebooting. This is very useful on systems where SetVariable is not available at runtime for some reasons. Some idea has been proposed by Peter[1], but the discussion has been stalled for a long time.
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.htm...
So the way i understand it we got two paths we can follow: 1. Use a configuration table for those variables 2. Shadow the variables on a kernel accessible memory in order to have access to them
How is this going to affect the existing tools (i.e efivar --list) for reading variables?
Regards /Ilias
On 3/19/20 10:33 AM, Ilias Apalodimas wrote:
Akashi-san,
On Wed, Mar 11, 2020 at 03:56:53PM +0900, AKASHI Takahiro wrote:
Regarding capsule update,
On Tue, Mar 10, 2020 at 09:45:28PM +0100, Francois Ozog wrote:
[...]
Directory \EFI\UpdateCapsule - A file placed on this directory on the boot device is considered a capsule. This is much easier to implement.
Essentially you could also use BootNext to run any binary for updating.
I suggest to go for the directory method of capsule updating.
That’s the goal for the moment. Yet a whole bunch new to be clarified. We are working on a document to be commented.
As some of you may know, I'm going to submit a RFC patch series for UEFI capsule support on U-Boot in a week or so (maybe). With this patch, we will support "Capsule-on-Disk" only (but without authentication implemented).
One of my concerns here is about "variable update via a capsule" as an alternative of "SetVariable at runtime," where values to be set for variables will be exported as a capsule file and all the updates will take place after rebooting. This is very useful on systems where SetVariable is not available at runtime for some reasons. Some idea has been proposed by Peter[1], but the discussion has been stalled for a long time.
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.htm...
So the way i understand it we got two paths we can follow:
- Use a configuration table for those variables
- Shadow the variables on a kernel accessible memory in order to have access to
them
It is unclear to me why it would be advantageous to follow any of these ideas compared to using GetVariable and SetVariable and letting the firmware runtime manage the memory area.
Best regards
Heinrich
How is this going to affect the existing tools (i.e efivar --list) for reading variables?
Regards /Ilias _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Thu, Mar 19, 2020 at 10:45:31AM +0100, Heinrich Schuchardt wrote:
On 3/19/20 10:33 AM, Ilias Apalodimas wrote:
Akashi-san,
On Wed, Mar 11, 2020 at 03:56:53PM +0900, AKASHI Takahiro wrote:
Regarding capsule update,
On Tue, Mar 10, 2020 at 09:45:28PM +0100, Francois Ozog wrote:
[...]
Directory \EFI\UpdateCapsule - A file placed on this directory on the boot device is considered a capsule. This is much easier to implement.
Essentially you could also use BootNext to run any binary for updating.
I suggest to go for the directory method of capsule updating.
That’s the goal for the moment. Yet a whole bunch new to be clarified. We are working on a document to be commented.
As some of you may know, I'm going to submit a RFC patch series for UEFI capsule support on U-Boot in a week or so (maybe). With this patch, we will support "Capsule-on-Disk" only (but without authentication implemented).
One of my concerns here is about "variable update via a capsule" as an alternative of "SetVariable at runtime," where values to be set for variables will be exported as a capsule file and all the updates will take place after rebooting. This is very useful on systems where SetVariable is not available at runtime for some reasons. Some idea has been proposed by Peter[1], but the discussion has been stalled for a long time.
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.htm...
So the way i understand it we got two paths we can follow:
- Use a configuration table for those variables
- Shadow the variables on a kernel accessible memory in order to have access to
them
It is unclear to me why it would be advantageous to follow any of these ideas compared to using GetVariable and SetVariable and letting the firmware runtime manage the memory area.
This describes some of the reasoning behind the idea. https://lists.linaro.org/pipermail/boot-architecture/2018-September/000841.h... The short version is that we should be able to provide GetVariable() even if SetVariable() is not implemented.
Regards /Ilias
On 3/19/20 11:33 AM, Ilias Apalodimas wrote:
On Thu, Mar 19, 2020 at 10:45:31AM +0100, Heinrich Schuchardt wrote:
On 3/19/20 10:33 AM, Ilias Apalodimas wrote:
Akashi-san,
On Wed, Mar 11, 2020 at 03:56:53PM +0900, AKASHI Takahiro wrote:
Regarding capsule update,
On Tue, Mar 10, 2020 at 09:45:28PM +0100, Francois Ozog wrote:
[...]
Directory \EFI\UpdateCapsule - A file placed on this directory on the boot device is considered a capsule. This is much easier to implement.
Essentially you could also use BootNext to run any binary for updating.
I suggest to go for the directory method of capsule updating.
That’s the goal for the moment. Yet a whole bunch new to be clarified. We are working on a document to be commented.
As some of you may know, I'm going to submit a RFC patch series for UEFI capsule support on U-Boot in a week or so (maybe). With this patch, we will support "Capsule-on-Disk" only (but without authentication implemented).
One of my concerns here is about "variable update via a capsule" as an alternative of "SetVariable at runtime," where values to be set for variables will be exported as a capsule file and all the updates will take place after rebooting. This is very useful on systems where SetVariable is not available at runtime for some reasons. Some idea has been proposed by Peter[1], but the discussion has been stalled for a long time.
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.htm...
So the way i understand it we got two paths we can follow:
- Use a configuration table for those variables
- Shadow the variables on a kernel accessible memory in order to have access to
them
It is unclear to me why it would be advantageous to follow any of these ideas compared to using GetVariable and SetVariable and letting the firmware runtime manage the memory area.
This describes some of the reasoning behind the idea. https://lists.linaro.org/pipermail/boot-architecture/2018-September/000841.h... The short version is that we should be able to provide GetVariable() even if SetVariable() is not implemented.
Thanks for the link. Unfortunately it does not answer my question. Why do we need a configuration table and cannot use GetVariable() and SetVariable() for abstracting the memory store?
For telling the kernel that the firmware cannot persist non-volatile variables on its own you could use a variable or a bit in the RuntimeServicesSupported variable.
Best regards
Heinrich
Hi Ilias,
On Thu, Mar 19, 2020 at 12:33:30 +0200, Ilias Apalodimas wrote:
On Thu, Mar 19, 2020 at 10:45:31AM +0100, Heinrich Schuchardt wrote:
As some of you may know, I'm going to submit a RFC patch series for UEFI capsule support on U-Boot in a week or so (maybe). With this patch, we will support "Capsule-on-Disk" only (but without authentication implemented).
One of my concerns here is about "variable update via a capsule" as an alternative of "SetVariable at runtime," where values to be set for variables will be exported as a capsule file and all the updates will take place after rebooting. This is very useful on systems where SetVariable is not available at runtime for some reasons. Some idea has been proposed by Peter[1], but the discussion has been stalled for a long time.
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.htm...
So the way i understand it we got two paths we can follow:
- Use a configuration table for those variables
- Shadow the variables on a kernel accessible memory in order to have access to
them
It is unclear to me why it would be advantageous to follow any of these ideas compared to using GetVariable and SetVariable and letting the firmware runtime manage the memory area.
This describes some of the reasoning behind the idea. https://lists.linaro.org/pipermail/boot-architecture/2018-September/000841.h... The short version is that we should be able to provide GetVariable() even if SetVariable() is not implemented.
I'm pretty sure Heinrich's concerns with this description are similar to my own, and boil down to one thing: this sounds like inventing new interfaces for doing these operations on these systems.
Systems that support GetVariable need to support that without any special handling added to the kernel.
For systems that have the flash sharing issue, this will mean that U-Boot needs to copy the flash variable region into RAM at ExitBootServices() time, and have the runtime service use this area.
Similarly, for such systems to support SetVariable they will need to either: - allocate some spare space for the GetVariable buffer and rewrite the whole thing on each write. - allocate a separate memory region to accept write transactions into, and hook those transactions into the GetVariable lookup to remain consistent.
(The former isn't necessarily going to be less effort, and the latter is almost certainly going to be required at some point.)
How and when any transactions become persisted in flash are separate questions.
/ Leif
On Thu, 19 Mar 2020 at 12:05, Leif Lindholm leif@nuviainc.com wrote:
Hi Ilias,
On Thu, Mar 19, 2020 at 12:33:30 +0200, Ilias Apalodimas wrote:
On Thu, Mar 19, 2020 at 10:45:31AM +0100, Heinrich Schuchardt wrote:
As some of you may know, I'm going to submit a RFC patch series
for UEFI
capsule support on U-Boot in a week or so (maybe). With this patch, we will support "Capsule-on-Disk" only (but without authentication implemented).
One of my concerns here is about "variable update via a capsule" as an alternative of "SetVariable at runtime," where values to be set for variables will be exported as a capsule file and all the
updates
will take place after rebooting. This is very useful on systems where SetVariable is not available at runtime for some reasons. Some idea has been proposed by Peter[1], but the discussion has
been
stalled for a long time.
[1]
https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.htm...
So the way i understand it we got two paths we can follow:
- Use a configuration table for those variables
- Shadow the variables on a kernel accessible memory in order to
have access to
them
It is unclear to me why it would be advantageous to follow any of these ideas compared to using GetVariable and SetVariable and letting the firmware runtime manage the memory area.
This describes some of the reasoning behind the idea.
https://lists.linaro.org/pipermail/boot-architecture/2018-September/000841.h...
The short version is that we should be able to provide GetVariable()
even if
SetVariable() is not implemented.
I'm pretty sure Heinrich's concerns with this description are similar to my own, and boil down to one thing: this sounds like inventing new interfaces for doing these operations on these systems.
Systems that support GetVariable need to support that without any special handling added to the kernel.
For systems that have the flash sharing issue, this will mean that U-Boot needs to copy the flash variable region into RAM at ExitBootServices() time, and have the runtime service use this area.
Similarly, for such systems to support SetVariable they will need to either:
- allocate some spare space for the GetVariable buffer and rewrite the whole thing on each write.
- allocate a separate memory region to accept write transactions into, and hook those transactions into the GetVariable lookup to remain consistent.
(The former isn't necessarily going to be less effort, and the latter is almost certainly going to be required at some point.)
How and when any transactions become persisted in flash are separate questions.
I haven't followed the technical discussion. following is the original
intent behind the changes requested for variable handling: - runtime services are not the best things and even EDK2 are probably moving away from this (Grant told us that at a design sprint a year ago) - "system administrator" is not the trusted party that has authority to change a variable, a "platform administrator" has the authority and is the signing party of variable updates. - UEFI variables interface for tools/kernel must not change: get/set variable - implementation of getVariable accesses a copy/shadow version of the UEFI variable - implementation of setVariable actually generates an update capsule so that the variable update is seen at next reboot
/ Leif
On 3/19/20 12:31 PM, François Ozog wrote:
On Thu, 19 Mar 2020 at 12:05, Leif Lindholm <leif@nuviainc.com mailto:leif@nuviainc.com> wrote:
Hi Ilias, On Thu, Mar 19, 2020 at 12:33:30 +0200, Ilias Apalodimas wrote: > On Thu, Mar 19, 2020 at 10:45:31AM +0100, Heinrich Schuchardt wrote: > > > > As some of you may know, I'm going to submit a RFC patch series for UEFI > > > > capsule support on U-Boot in a week or so (maybe). With this patch, > > > > we will support "Capsule-on-Disk" only (but without authentication > > > > implemented). > > > > > > > > One of my concerns here is about "variable update via a capsule" as > > > > an alternative of "SetVariable at runtime," where values to be set > > > > for variables will be exported as a capsule file and all the updates > > > > will take place after rebooting. This is very useful on systems > > > > where SetVariable is not available at runtime for some reasons. > > > > Some idea has been proposed by Peter[1], but the discussion has been > > > > stalled for a long time. > > > > > > > > [1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.html > > > > > > So the way i understand it we got two paths we can follow: > > > 1. Use a configuration table for those variables > > > 2. Shadow the variables on a kernel accessible memory in order to have access to > > > them > > > > It is unclear to me why it would be advantageous to follow any of these > > ideas compared to using GetVariable and SetVariable and letting the > > firmware runtime manage the memory area. > > This describes some of the reasoning behind the idea. > https://lists.linaro.org/pipermail/boot-architecture/2018-September/000841.html > The short version is that we should be able to provide GetVariable() even if > SetVariable() is not implemented. I'm pretty sure Heinrich's concerns with this description are similar to my own, and boil down to one thing: this sounds like inventing new interfaces for doing these operations on these systems. Systems that support GetVariable need to support that without any special handling added to the kernel. For systems that have the flash sharing issue, this will mean that U-Boot needs to copy the flash variable region into RAM at ExitBootServices() time, and have the runtime service use this area. Similarly, for such systems to support SetVariable they will need to either: - allocate some spare space for the GetVariable buffer and rewrite the whole thing on each write. - allocate a separate memory region to accept write transactions into, and hook those transactions into the GetVariable lookup to remain consistent. (The former isn't necessarily going to be less effort, and the latter is almost certainly going to be required at some point.) How and when any transactions become persisted in flash are separate questions.I haven't followed the technical discussion. following is the original intent behind the changes requested for variable handling:
- runtime services are not the best things and even EDK2 are probably
moving away from this (Grant told us that at a design sprint a year ago)
Operating systems like Windows rely on setting Boot* variables. Do you plan to break them?
- "system administrator" is not the trusted party that has authority to
change a variable, a "platform administrator" has the authority and is the signing party of variable updates.
Not all variables are signed. Especially Boot* variables are managed by users with access to efibootmgr.
- UEFI variables interface for tools/kernel must not change: get/set
variable
- implementation of getVariable accesses a copy/shadow version of the
UEFI variable
- implementation of setVariable actually generates an update capsule so
that the variable update is seen at next reboot
The discussion as far as I understood it centered on the question how a firmware that has no access to persistent memory at runtime can handle non-volatile variable updates.
A capsule is only a possible encoding of information but does not answer the question in which medium the information from before the reboot shall be conveyed to after the reboot.
Putting the information into RAM and hoping it survives a reboot is feasible but will not work during a system shutdown. Letting the operating system write the information to disk seems to be the easiest thing to do.
Best regards
Heinrich
On 19/03/2020 12:03, Heinrich Schuchardt wrote:
On 3/19/20 12:31 PM, François Ozog wrote:
I haven't followed the technical discussion. following is the original intent behind the changes requested for variable handling:
- runtime services are not the best things and even EDK2 are probably
moving away from this (Grant told us that at a design sprint a year ago)
Operating systems like Windows rely on setting Boot* variables. Do you plan to break them?
If Windows is the goal, then SBSA/SBBR/ServerReady is the interface. I don't think it is valuable to touch this use case with EBBR. Rather, the primary use case for EBBR is embedded and community Linux distros on embedded devices. Boot* variables are important, but hard to set at runtime; therefore the question is "is setting Boot* variables only at boot time suitable for EBBR use cases?"
(U-Boot could theoretically implement full SBBR on some platforms, but that is different than what the EBBR requirements are)
- "system administrator" is not the trusted party that has authority to
change a variable, a "platform administrator" has the authority and is the signing party of variable updates.
Not all variables are signed. Especially Boot* variables are managed by users with access to efibootmgr.
- UEFI variables interface for tools/kernel must not change: get/set
variable
- implementation of getVariable accesses a copy/shadow version of the
UEFI variable
- implementation of setVariable actually generates an update capsule so
that the variable update is seen at next reboot
The discussion as far as I understood it centered on the question how a firmware that has no access to persistent memory at runtime can handle non-volatile variable updates.
A capsule is only a possible encoding of information but does not answer the question in which medium the information from before the reboot shall be conveyed to after the reboot.
Putting the information into RAM and hoping it survives a reboot is feasible but will not work during a system shutdown. Letting the operating system write the information to disk seems to be the easiest thing to do.
Indeed, this debate always cycles back to this point. How does firmware reliably persist a SetVariable() operation when it doesn't control the storage, and the OS might not have a suitable storage proxy
g.
On 3/19/20 1:21 PM, Grant Likely wrote:
On 19/03/2020 12:03, Heinrich Schuchardt wrote:
On 3/19/20 12:31 PM, François Ozog wrote:
I haven't followed the technical discussion. following is the original intent behind the changes requested for variable handling:
- runtime services are not the best things and even EDK2 are probably
moving away from this (Grant told us that at a design sprint a year ago)
Operating systems like Windows rely on setting Boot* variables. Do you plan to break them?
If Windows is the goal, then SBSA/SBBR/ServerReady is the interface. I don't think it is valuable to touch this use case with EBBR. Rather, the primary use case for EBBR is embedded and community Linux distros on embedded devices. Boot* variables are important, but hard to set at runtime; therefore the question is "is setting Boot* variables only at boot time suitable for EBBR use cases?"
Windows IoT Core is addressing the same class of boards as EBBR and relies on UEFI:
https://docs.microsoft.com/en-us/windows/iot-core/tutorials/quickstarter/Pro... https://docs.microsoft.com/en-us/windows/iot-core/commercialize-your-device/...
Best regards
Heinrich
(U-Boot could theoretically implement full SBBR on some platforms, but that is different than what the EBBR requirements are)
- "system administrator" is not the trusted party that has authority to
change a variable, a "platform administrator" has the authority and is the signing party of variable updates.
Not all variables are signed. Especially Boot* variables are managed by users with access to efibootmgr.
- UEFI variables interface for tools/kernel must not change: get/set
variable
- implementation of getVariable accesses a copy/shadow version of the
UEFI variable
- implementation of setVariable actually generates an update capsule so
that the variable update is seen at next reboot
The discussion as far as I understood it centered on the question how a firmware that has no access to persistent memory at runtime can handle non-volatile variable updates.
A capsule is only a possible encoding of information but does not answer the question in which medium the information from before the reboot shall be conveyed to after the reboot.
Putting the information into RAM and hoping it survives a reboot is feasible but will not work during a system shutdown. Letting the operating system write the information to disk seems to be the easiest thing to do.
Indeed, this debate always cycles back to this point. How does firmware reliably persist a SetVariable() operation when it doesn't control the storage, and the OS might not have a suitable storage proxy
g.
+Poonam Aggrwal poonam.aggrwal@nxp.com
On Thu, 19 Mar 2020 at 17:42, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 3/19/20 1:21 PM, Grant Likely wrote:
On 19/03/2020 12:03, Heinrich Schuchardt wrote:
On 3/19/20 12:31 PM, François Ozog wrote:
I haven't followed the technical discussion. following is the original intent behind the changes requested for variable handling:
- runtime services are not the best things and even EDK2 are probably
moving away from this (Grant told us that at a design sprint a year
ago)
Operating systems like Windows rely on setting Boot* variables. Do you plan to break them?
If Windows is the goal, then SBSA/SBBR/ServerReady is the interface. I don't think it is valuable to touch this use case with EBBR. Rather, the primary use case for EBBR is embedded and community Linux distros on embedded devices. Boot* variables are important, but hard to set at runtime; therefore the question is "is setting Boot* variables only at boot time suitable for EBBR use cases?"
Windows IoT Core is addressing the same class of boards as EBBR and relies on UEFI:
https://docs.microsoft.com/en-us/windows/iot-core/tutorials/quickstarter/Pro...
https://docs.microsoft.com/en-us/windows/iot-core/commercialize-your-device/...
Best regards
Heinrich
(U-Boot could theoretically implement full SBBR on some platforms, but that is different than what the EBBR requirements are)
- "system administrator" is not the trusted party that has authority to
change a variable, a "platform administrator" has the authority and is the signing party of variable updates.
Not all variables are signed. Especially Boot* variables are managed by users with access to efibootmgr.
- UEFI variables interface for tools/kernel must not change: get/set
variable
- implementation of getVariable accesses a copy/shadow version of the
UEFI variable
- implementation of setVariable actually generates an update capsule so
that the variable update is seen at next reboot
The discussion as far as I understood it centered on the question how a firmware that has no access to persistent memory at runtime can handle non-volatile variable updates.
A capsule is only a possible encoding of information but does not answer the question in which medium the information from before the reboot shall be conveyed to after the reboot.
Putting the information into RAM and hoping it survives a reboot is feasible but will not work during a system shutdown. Letting the operating system write the information to disk seems to be the easiest thing to do.
Indeed, this debate always cycles back to this point. How does firmware reliably persist a SetVariable() operation when it doesn't control the storage, and the OS might not have a suitable storage proxy
g.
On Thu, Mar 19, 2020 at 12:31:37 +0100, François Ozog wrote:
On Thu, 19 Mar 2020 at 12:05, Leif Lindholm leif@nuviainc.com wrote:
I'm pretty sure Heinrich's concerns with this description are similar to my own, and boil down to one thing: this sounds like inventing new interfaces for doing these operations on these systems.
Systems that support GetVariable need to support that without any special handling added to the kernel.
For systems that have the flash sharing issue, this will mean that U-Boot needs to copy the flash variable region into RAM at ExitBootServices() time, and have the runtime service use this area.
Similarly, for such systems to support SetVariable they will need to either:
- allocate some spare space for the GetVariable buffer and rewrite the whole thing on each write.
- allocate a separate memory region to accept write transactions into, and hook those transactions into the GetVariable lookup to remain consistent.
(The former isn't necessarily going to be less effort, and the latter is almost certainly going to be required at some point.)
How and when any transactions become persisted in flash are separate questions.
I haven't followed the technical discussion. following is the original intent behind the changes requested for variable handling:
- runtime services are not the best things and even EDK2 are probably moving away from this (Grant told us that at a design sprint a year ago)
I'm pretty sure Grant said *UEFI*[0] might move away from them (if not, bad Grant!). I think a more accurate description would be that UEFI *wants* to move away from them. Even so, that's a push, and runtime services are certainly going to remain relevant for the next decade or two.
Discussing what may or may not happen is not an argument for diverging from the existing specification, nor is it constructive to discuss bolt-ons onto the side of the spec other than in the context of proposing specific changes to the UEFI specification.
- "system administrator" is not the trusted party that has authority to change a variable, a "platform administrator" has the authority and is the signing party of variable updates.
- UEFI variables interface for tools/kernel must not change: get/set variable
Yes, this is the sticking point. GetVariable/SetVariable (where supported) must be implemented as runtime services accessed through pointers in the EFI System Table. No alternative mechanisms for getting/setting UEFI variables must be implemented unless supported by a future UEFI specification.
- implementation of getVariable accesses a copy/shadow version of the UEFI variable
Yep. Without any knowledge on behalf of the operating system beyond the addresses of the runtime service functions.
- implementation of setVariable actually generates an update capsule so that the variable update is seen at next reboot
I don't really have an opinion[1] - my statement was intended to separate the discussion of the interfaces for accessing variables at runtime from the discussion of mechanisms used to persist said variables in a single-storage system.
/ Leif
[0] EDK2 is the reference implementation of UEFI, it isn't going to go off and invent interfaces that aren't already resolved in the spec.
[1] This is obviously a lie.
On 19/03/2020 11:31, François Ozog wrote:
On Thu, 19 Mar 2020 at 12:05, Leif Lindholm <leif@nuviainc.com mailto:leif@nuviainc.com> wrote:
Hi Ilias, On Thu, Mar 19, 2020 at 12:33:30 +0200, Ilias Apalodimas wrote: > On Thu, Mar 19, 2020 at 10:45:31AM +0100, Heinrich Schuchardt wrote: > > > > As some of you may know, I'm going to submit a RFC patch series for UEFI > > > > capsule support on U-Boot in a week or so (maybe). With this patch, > > > > we will support "Capsule-on-Disk" only (but without authentication > > > > implemented). > > > > > > > > One of my concerns here is about "variable update via a capsule" as > > > > an alternative of "SetVariable at runtime," where values to be set > > > > for variables will be exported as a capsule file and all the updates > > > > will take place after rebooting. This is very useful on systems > > > > where SetVariable is not available at runtime for some reasons. > > > > Some idea has been proposed by Peter[1], but the discussion has been > > > > stalled for a long time. > > > > > > > > [1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.html > > > > > > So the way i understand it we got two paths we can follow: > > > 1. Use a configuration table for those variables > > > 2. Shadow the variables on a kernel accessible memory in order to have access to > > > them > > > > It is unclear to me why it would be advantageous to follow any of these > > ideas compared to using GetVariable and SetVariable and letting the > > firmware runtime manage the memory area. > > This describes some of the reasoning behind the idea. > https://lists.linaro.org/pipermail/boot-architecture/2018-September/000841.html > The short version is that we should be able to provide GetVariable() even if > SetVariable() is not implemented. I'm pretty sure Heinrich's concerns with this description are similar to my own, and boil down to one thing: this sounds like inventing new interfaces for doing these operations on these systems. Systems that support GetVariable need to support that without any special handling added to the kernel. For systems that have the flash sharing issue, this will mean that U-Boot needs to copy the flash variable region into RAM at ExitBootServices() time, and have the runtime service use this area. Similarly, for such systems to support SetVariable they will need to either: - allocate some spare space for the GetVariable buffer and rewrite the whole thing on each write. - allocate a separate memory region to accept write transactions into, and hook those transactions into the GetVariable lookup to remain consistent. (The former isn't necessarily going to be less effort, and the latter is almost certainly going to be required at some point.) How and when any transactions become persisted in flash are separate questions.I haven't followed the technical discussion. following is the original intent behind the changes requested for variable handling:
- runtime services are not the best things and even EDK2 are probably
moving away from this (Grant told us that at a design sprint a year ago)
As always, this is a matter of intense debate. Don't expect Runtime Services to disappear anytime soon. The real question is what level of service must be provided by EBBR platforms. I thing GetVariable() should be required. SetVariable() I'm still undecided on, but I'm less and less keen on inviting new mechanisms to replace it. I'd rather flag it as unsupported and require the system operator to do their variable manipulation at boot time for those specific systems.
- "system administrator" is not the trusted party that has authority to
change a variable, a "platform administrator" has the authority and is the signing party of variable updates.
The moment we're talking about secure boot, a suitable design pretty much requires moving all the variable management code out of normal world and into a trusted application. In this case the runtime serivces calls can become wrappers around SMC calls and we've got a lot more capability to make changes. I think going forward, our focus for complete functionality should be on the platforms that can implement the back end as a trusted application and not get too hung up on the complications of the non-secure platforms.
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 3/19/20 12:05 PM, Leif Lindholm wrote:
Hi Ilias,
On Thu, Mar 19, 2020 at 12:33:30 +0200, Ilias Apalodimas wrote:
On Thu, Mar 19, 2020 at 10:45:31AM +0100, Heinrich Schuchardt wrote:
As some of you may know, I'm going to submit a RFC patch series for UEFI capsule support on U-Boot in a week or so (maybe). With this patch, we will support "Capsule-on-Disk" only (but without authentication implemented).
One of my concerns here is about "variable update via a capsule" as an alternative of "SetVariable at runtime," where values to be set for variables will be exported as a capsule file and all the updates will take place after rebooting. This is very useful on systems where SetVariable is not available at runtime for some reasons. Some idea has been proposed by Peter[1], but the discussion has been stalled for a long time.
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.htm...
So the way i understand it we got two paths we can follow:
- Use a configuration table for those variables
- Shadow the variables on a kernel accessible memory in order to have access to
them
It is unclear to me why it would be advantageous to follow any of these ideas compared to using GetVariable and SetVariable and letting the firmware runtime manage the memory area.
This describes some of the reasoning behind the idea. https://lists.linaro.org/pipermail/boot-architecture/2018-September/000841.h... The short version is that we should be able to provide GetVariable() even if SetVariable() is not implemented.
I'm pretty sure Heinrich's concerns with this description are similar to my own, and boil down to one thing: this sounds like inventing new interfaces for doing these operations on these systems.
Systems that support GetVariable need to support that without any special handling added to the kernel.
For systems that have the flash sharing issue, this will mean that U-Boot needs to copy the flash variable region into RAM at ExitBootServices() time, and have the runtime service use this area.
Similarly, for such systems to support SetVariable they will need to either:
- allocate some spare space for the GetVariable buffer and rewrite the whole thing on each write.
- allocate a separate memory region to accept write transactions into, and hook those transactions into the GetVariable lookup to remain consistent.
If the firmware that has no persistent storage but holds all variables in memory, an operating system shutdown service (e.g. a script in systemd's /usr/lib/systemd/system-shutdown/) could be used to persist the variables before reboot. The service would read all variable via Get(Next)Variable and write a file to the EFI boot partition. This could be an EFI update capsule or some system specific file format.
Best regards
Heinrich
(The former isn't necessarily going to be less effort, and the latter is almost certainly going to be required at some point.)
How and when any transactions become persisted in flash are separate questions.
/ Leif _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Just a general note on this entire thread; if there are specific things you want to clarify or add to EBBR, it would be helpful to add them as issues in GitHub here:
https://github.com/ARM-software/ebbr/issues
g.
On 10/03/2020 20:14, Heinrich Schuchardt wrote:
On 3/10/20 5:02 PM, Francois Ozog wrote:
Hi,
Following implementation (or work towards) of EBBR 1.0 + UEFI Secure boot + UEFI update capsule we learnt a lot.
Here are some topics that may need some clarification on the EBBR specs and It looks timely to start working on EBBR evolution.
0.1 - EBBR goal May be a reassessment on the "for what" the specification is built.
EBBR 1.0 is quite vague about this point.
Implementing the requirements of version 1.0 was enough to allow systems to be booted in a common way. Secure boot is not supported by what is required.
Following all the discussions with prominent industry players, I start to think that limiting the constraints to be EBBR compliant may become counter productive. There will be both EBBR non compliant and EBBR compliant systems. This is inevitable. But EBBR exist for a number of use cases in a number of markets. The value of EBBR is consistent behavior across those.
Maximising number of EBBR compliant systems without stating use case parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows (with/without shim+grub or direct). Some vendors require shim+grub while industry players want the exact opposite: nothing but UEFI. This drivers a number of requirements in terms of UEFI protocols needed
Shim and GRUB are optional tools which operating systems like BSD, Linux or Windows do not need for booting. I think the EBBR should be operating system agnostic.
This does not deny the usefulness of some of these tools. My personal favorite is booting via U-Boot -> iPXE -> GRUB -> Linux from an iSCSI drive ;)
0.2 - normative text The normative section shall be stated clearly: is " 1.2. Guiding Principles" normative?
IETF and ETSI have different language conventions to express absolutely mandated and various levels of optionality. This spec may be red by Telecom people or Linux people. Their interpretation may be erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The language need to be explicit.
A reference to RFC 2119 should be added to the EBBR.
I - protective offsets EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that "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."
StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without the variable rework done and update capsules. 4MB seems the minimum. 8MB to get margin and 16MB for A/B scheme.
EBBR same paragraph also states: "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. Manual partitioning tools should provide warnings when modifying protective partitions or creating partitions within the first 1MiB."
is it expected that Linaro upstreams changes in installation tools, partition tools to conform to this (with updated to be agreed minimum)?
Obviously the minimum required space depends on the firmware and the maximum depends on the hardware (some devices like routers simply only have 16MiB flash for firmware and operating system in total).
Shouldn't the firmware have a way to tell the OS how much space it wants instead of prescribing a fixed quantity?
II - identifying partitions Having two EFI partitions defined with EFI_GUID need a precise behaviour defined: boot with first or boot with second.
This is only relevant when relying on the \EFI\BOOT directory. If Bootxxxx variables are defined, these specify the relevant partition.
Shall we have a EFI_GUID_ALT defined for A/B partition schemes? If not, the BootXXX variables should be used as selector? We lean towards BootXXX variables and not defining a new GUID. But this would mean explicit behavior to be stated in case of lack of BootXXX.
I think GPT volume mirroring should be used in conjunction with A/B: A/B to recover version failures with current hardware, surrounding software; mirroring to protect against storage failures.
Is there any recommendation on mirrored EFI volumes handling ?
Isn't the availability of Bootxxxx variables enough?
III - 32 bits are there any 32 bits specific considerations to be added?
The only thing 32bit specific that comes to my mind is clearing architecture specific caches as defined in the UEFI spec.
For RISC-V there is a development ongoing for communicating the boot hart ID form the firmware to the operating system.
IV - UEFI_RNG_PROTOCOL Following my view in 0) I think this shall be made mandatory
EBBR v1.0 has as design goal: 'Design for common embedded target'. "Generally anything that has a near near-upstream U-Boot implementation should be able to implement the EBBR requirements."
Not all common SoCs have a hardware RNG, e.g. Allwinner (cf. https://linux-sunxi.org/Cryptographic_Hardware_Accelerators).
I would not assume that enough entropy can be gathered by the firmware on a standalone device without a hardware RNG to drive the EFI_RNG_PROTOCOL.
A high entropy RNG is needed for secure network communication. It can be used for randomizing kernel memory layout. But why should it be made mandatory for devices that do not need network communication before the operating system is started?
Linaro has upstreamed this in U-Boot and started to implement additional hardware drivers. KASLR is thus functional in 64 bits and will be in 32bits.
V - UEFI SecureBoot Following my view in 0) I think this shall be made mandatory
UEFI SecureBoot is not mentioned in section 2.6 so we need to clarify what needs to be implemented. In particular, we need to implement EFI_LOAD_FILE2_PROTOCOL for initrd signature checking.
The protocol (without checking) is implemented in U-Boot 2020.04. But we should also consider the device-tree and the command line.
VI - UEFI update capsules Following my view in 0) I think this shall be made mandatory
The UEFI specification provides multiple possibilities to update:
UpdateCapsule() runtime service - This runtime service is quite hard to implement if there is no storage that is off limits for the operating system.
Directory \EFI\UpdateCapsule - A file placed on this directory on the boot device is considered a capsule. This is much easier to implement.
Essentially you could also use BootNext to run any binary for updating.
I suggest to go for the directory method of capsule updating.
Section 2.6 of UEFI spec 2.7 mentions At some point in time we will need to propose UEFI specification update for:
- anti-bricking anti rollback expected behavior
- abstract capsules for "start transaction", "commit", "rollback" when
we will be dealing with system wide transactional updates. There is probably a lot to state here but I am just starting the discussion.
VII - UEFI watchdog Following my view in 0) I think this shall be made mandatory
I could imagine the following scenarios where a watchdog is helpful:
- A/B scenario: this would require a variable to be updated that switches between A and B
- booting via network (retry)
Watchdogs are available both in EDK II and U-Boot.
Best regards
Heinrich
In addition to its definition, it should also integrate consistent parameters to define total duration covered as well as number of failed consecutive updates to be triggered as well as how it is delivered (powercycle, NMI, secureIRQ...)
Cheers
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@lists.linaro.org
-
AKASHI Takahiro -
Daniel Thompson -
Francois Ozog -
François Ozog
-
Grant Likely -
Heinrich Schuchardt -
Ilias Apalodimas -
Leif Lindholm -
Stuart Yoder -
Sumit Garg