Fixes: #3 Fixed: #8 Signed-off-by: Daniel Thompson daniel.thompson@linaro.org ---
Notes: This patch tries to capture contributions from a long a varied discussion. I hope I haven't missed anything major.
Thanks to all the contributors to this topic so far!
source/ebbr.rst | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 40f03f173bd9..30a9c6ac2666 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -185,6 +185,53 @@ System Volume Format --------------------
The system firmware must support GPT partitioning. +It may optionally also support MBR partitioning. + +On systems where the system firmware binaries reside on the System Volume then +the System Volume must be pre-configured with a partition table and include +protective partitions to reduce risk of accidental destruction of the system +firmware. + +All pre-configured partition tables must use GPT partitioning unless +some immutable feature of the platform (such as a mask programmed boot ROM) +makes this impossible; on such platforms MBR partitioning may be +used as an alternative. + +GPT partitioning +^^^^^^^^^^^^^^^^ + +Protective partitions should have the Platform Required Attribute Flag set +unless some immutable feature of the platform makes this impossible. + +It is recommended that automatic system disk partitioning utilities +preserve Platform Required partitions as is, and that manual disk +partitioning utilities provide warnings and/or other safe guards to +reduce risk of accidental removal. + +It is recommended that an implementer on a platform where Platform Required +cannot be set contribute a list of Partition type GUIDs for protective +partitions to the table below. It is further recommended that disk partitioning +utilities treat such partitions in the same manner as those with the Platform +Required Attribute Flag set. + ++--------------------------------------+---------------------------------------+ +| Partition type GUID | Comment | ++======================================+=======================================+ +| 00000000-0000-0000-0000-000000000000 | Unused entry (example; do not honour) | ++--------------------------------------+---------------------------------------+ + +MBR partitioning +^^^^^^^^^^^^^^^^ + +Protective partitions should have a partition type of 0xF8 unless some +immutable feature of the platform makes this impossible. + +It is recommended that disk partitioning utilities treat such +partitions in the same manner as GPT partitions with the Platform +Required Attribute Flag set. + +It is strongly recommended that protective partitions with a type other +than 0xF8 be placed within 1MB of the start of the disk.
UEFI Boot Services ==================
Hi Daniel,
Thanks for writing this. Good job. Comments below.
On 22/05/2018 20:17, Daniel Thompson wrote:
Fixes: #3 Fixed: #8 Signed-off-by: Daniel Thompson daniel.thompson@linaro.org
Nit: I'd like to maintain good patch practice. Please include commit description in patches.
Notes: This patch tries to capture contributions from a long a varied discussion. I hope I haven't missed anything major.
Thanks to all the contributors to this topic so far!source/ebbr.rst | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 40f03f173bd9..30a9c6ac2666 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -185,6 +185,53 @@ System Volume Format
The system firmware must support GPT partitioning. +It may optionally also support MBR partitioning.
I think there are two sides of this; what the firmware supports, and what the OS supports. Should we specify this?
For the firmware: GPT required, MBR optional For the OS: GPT & MBR required
Should it also specify that GPT partitioning must strictly follow the UEFI specification, and must not use a hybrid-MBR?
+On systems where the system firmware binaries reside on the System Volume then +the System Volume must be pre-configured with a partition table and include +protective partitions to reduce risk of accidental destruction of the system +firmware.
+All pre-configured partition tables must use GPT partitioning unless +some immutable feature of the platform (such as a mask programmed boot ROM) +makes this impossible; on such platforms MBR partitioning may be +used as an alternative
Looks good. It would be useful to have some discussion about the possible scenarios, and how this plays out.
+GPT partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have the Platform Required Attribute Flag set +unless some immutable feature of the platform makes this impossible.
Do we know of any platforms where Platform Required cannot be set? If not, then I would drop the caveat.
+It is recommended that automatic system disk partitioning utilities > +preserve Platform Required partitions as is, and that manual disk +partitioning utilities provide warnings and/or other safe guards to +reduce risk of accidental removal
Suggested reword: Automatic system disk partitioning utilities shall preserve Platform Required partitions as is. Manual disk partitioning utilities should provide warnings and/or other safe guards to reduce the risk of accidental removal.
+It is recommended that an implementer on a platform where Platform Required +cannot be set contribute a list of Partition type GUIDs for protective +partitions to the table below. It is further recommended that disk partitioning +utilities treat such partitions in the same manner as those with the Platform +Required Attribute Flag set.
++--------------------------------------+---------------------------------------+ +| Partition type GUID | Comment | ++======================================+=======================================+ +| 00000000-0000-0000-0000-000000000000 | Unused entry (example; do not honour) | ++--------------------------------------+---------------------------------------+
+MBR partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have a partition type of 0xF8 unless some +immutable feature of the platform makes this impossible.
I'd like to be rid of the caveat here too, but there is a lot more legacy to support with MBR.
+It is recommended that disk partitioning utilities treat such +partitions in the same manner as GPT partitions with the Platform +Required Attribute Flag set.
+It is strongly recommended that protective partitions with a type other +than 0xF8 be placed within 1MB of the start of the disk.
... I was going to suggest "s/disk/system volume/", but then I went and looked at the UEFI spec and it uses the 'disk' terminology throughout. System Volume is only used by the SBBR/EBBR specs. It should probably be changed to "system disk" since the term Volume is more frequently associated with partitions instead of the whole disk.
"disk" may not be strictly accurate these days, but it is established language.
Need to also specify that partitioning tools will not use or modify the first 1MB of block storage.
Reading this, I think there also needs to be a discusson of how to handle the System Partition w.r.t. firmware (for a separate patch)
Cheers, g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Am 22.05.2018 um 21:17 schrieb Daniel Thompson daniel.thompson@linaro.org:
Fixes: #3 Fixed: #8 Signed-off-by: Daniel Thompson daniel.thompson@linaro.org
Notes: This patch tries to capture contributions from a long a varied discussion. I hope I haven't missed anything major.
Thanks to all the contributors to this topic so far!
source/ebbr.rst | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 40f03f173bd9..30a9c6ac2666 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -185,6 +185,53 @@ System Volume Format
The system firmware must support GPT partitioning. +It may optionally also support MBR partitioning.
Please make both mandatory.
+On systems where the system firmware binaries reside on the System Volume then +the System Volume must be pre-configured with a partition table and include +protective partitions to reduce risk of accidental destruction of the system +firmware.
+All pre-configured partition tables must use GPT partitioning unless +some immutable feature of the platform (such as a mask programmed boot ROM) +makes this impossible; on such platforms MBR partitioning may be +used as an alternative.
+GPT partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have the Platform Required Attribute Flag set +unless some immutable feature of the platform makes this impossible.
+It is recommended that automatic system disk partitioning utilities +preserve Platform Required partitions as is, and that manual disk +partitioning utilities provide warnings and/or other safe guards to +reduce risk of accidental removal.
+It is recommended that an implementer on a platform where Platform Required +cannot be set contribute a list of Partition type GUIDs for protective +partitions to the table below. It is further recommended that disk partitioning +utilities treat such partitions in the same manner as those with the Platform +Required Attribute Flag set.
++--------------------------------------+---------------------------------------+ +| Partition type GUID | Comment | ++======================================+=======================================+ +| 00000000-0000-0000-0000-000000000000 | Unused entry (example; do not honour) | ++--------------------------------------+---------------------------------------+
+MBR partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have a partition type of 0xF8 unless some +immutable feature of the platform makes this impossible.
+It is recommended that disk partitioning utilities treat such +partitions in the same manner as GPT partitions with the Platform +Required Attribute Flag set.
+It is strongly recommended that protective partitions with a type other +than 0xF8 be placed within 1MB of the start of the disk.
What does this sentence mean?
Alex
UEFI Boot Services
-- 2.17.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
On Tue, May 22, 2018 at 09:31:16PM +0100, Grant Likely wrote:
Hi Daniel,
Thanks for writing this. Good job. Comments below.
On 22/05/2018 20:17, Daniel Thompson wrote:
Fixes: #3 Fixed: #8 Signed-off-by: Daniel Thompson daniel.thompson@linaro.org
Nit: I'd like to maintain good patch practice. Please include commit description in patches.
Will do.
Notes: This patch tries to capture contributions from a long a varied discussion. I hope I haven't missed anything major.
Thanks to all the contributors to this topic so far!source/ebbr.rst | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 40f03f173bd9..30a9c6ac2666 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -185,6 +185,53 @@ System Volume Format
The system firmware must support GPT partitioning. +It may optionally also support MBR partitioning.
I think there are two sides of this; what the firmware supports, and what the OS supports. Should we specify this?
For the firmware: GPT required, MBR optional For the OS: GPT & MBR required
Looking at this fresh eyes, the UEFI spec requires GPT, MBR and el torito.
Is there any need to EBBR to say *anything* on this topic of what firmware and OS supports, except to require (where not impossible) that any pre-formatted media use GPT?
In other words maybe just delete this paragraph.
Should it also specify that GPT partitioning must strictly follow the UEFI specification, and must not use a hybrid-MBR?
Can do, although like the above, we would merely be restating part of the UEFI spec.
+On systems where the system firmware binaries reside on the System Volume then +the System Volume must be pre-configured with a partition table and include +protective partitions to reduce risk of accidental destruction of the system +firmware.
+All pre-configured partition tables must use GPT partitioning unless +some immutable feature of the platform (such as a mask programmed boot ROM) +makes this impossible; on such platforms MBR partitioning may be +used as an alternative
Looks good. It would be useful to have some discussion about the possible scenarios, and how this plays out.
In this patch or in examples in the informative sections of the doc?
+GPT partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have the Platform Required Attribute Flag set +unless some immutable feature of the platform makes this impossible.
Do we know of any platforms where Platform Required cannot be set? If not, then I would drop the caveat.
Nothing in the wiki, although there is the certainly evidence of ROMish parsing of GPT tables [and therefore potential for touble ;-) ].
+It is recommended that automatic system disk partitioning utilities > +preserve Platform Required partitions as is, and that manual disk +partitioning utilities provide warnings and/or other safe guards to +reduce risk of accidental removal
Suggested reword: Automatic system disk partitioning utilities shall preserve Platform Required partitions as is. Manual disk partitioning utilities should provide warnings and/or other safe guards to reduce the risk of accidental removal.
Looks good, but if we're upgrading from should to shall then I want to work in the "unless it recognizes this partition" language from UEFI spec (in case of spurious bad labelling).
Will do this in the next revision.
+It is recommended that an implementer on a platform where Platform Required +cannot be set contribute a list of Partition type GUIDs for protective +partitions to the table below. It is further recommended that disk partitioning +utilities treat such partitions in the same manner as those with the Platform +Required Attribute Flag set.
++--------------------------------------+---------------------------------------+ +| Partition type GUID | Comment | ++======================================+=======================================+ +| 00000000-0000-0000-0000-000000000000 | Unused entry (example; do not honour) | ++--------------------------------------+---------------------------------------+
+MBR partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have a partition type of 0xF8 unless some +immutable feature of the platform makes this impossible.
I'd like to be rid of the caveat here too, but there is a lot more legacy to support with MBR.
The known behaviour wiki mentions that RPi dictates 0x0C.
+It is recommended that disk partitioning utilities treat such +partitions in the same manner as GPT partitions with the Platform +Required Attribute Flag set.
+It is strongly recommended that protective partitions with a type other +than 0xF8 be placed within 1MB of the start of the disk.
... I was going to suggest "s/disk/system volume/", but then I went and looked at the UEFI spec and it uses the 'disk' terminology throughout. System Volume is only used by the SBBR/EBBR specs. It should probably be changed to "system disk" since the term Volume is more frequently associated with partitions instead of the whole disk.
"disk" may not be strictly accurate these days, but it is established language.
Agree. I've used System Volume fairly liberally in this patch only because it was already in use and we define no other terminology so I figured adding it could then be someone else's problem (or at least not my problem for this patch). Does this need to be tackled in this patch or elsewhere?
Need to also specify that partitioning tools will not use or modify the first 1MB of block storage.
Agree.
Reading this, I think there also needs to be a discusson of how to handle the System Partition w.r.t. firmware (for a separate patch)
+1 [especially about the "separate patch" bit :-) ]
Daniel.
On Tue, May 22, 2018 at 11:12:26PM +0200, Alexander Graf wrote:
Am 22.05.2018 um 21:17 schrieb Daniel Thompson daniel.thompson@linaro.org:
Fixes: #3 Fixed: #8 Signed-off-by: Daniel Thompson daniel.thompson@linaro.org
Notes: This patch tries to capture contributions from a long a varied discussion. I hope I haven't missed anything major.
Thanks to all the contributors to this topic so far!
source/ebbr.rst | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 40f03f173bd9..30a9c6ac2666 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -185,6 +185,53 @@ System Volume Format
The system firmware must support GPT partitioning. +It may optionally also support MBR partitioning.
Please make both mandatory.
Will do (or alternatively will just remove this entirely and rely on the underlying UEFI spec to mandate GPT, MBR and el torito).
+On systems where the system firmware binaries reside on the System Volume then +the System Volume must be pre-configured with a partition table and include +protective partitions to reduce risk of accidental destruction of the system +firmware.
+All pre-configured partition tables must use GPT partitioning unless +some immutable feature of the platform (such as a mask programmed boot ROM) +makes this impossible; on such platforms MBR partitioning may be +used as an alternative.
+GPT partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have the Platform Required Attribute Flag set +unless some immutable feature of the platform makes this impossible.
+It is recommended that automatic system disk partitioning utilities +preserve Platform Required partitions as is, and that manual disk +partitioning utilities provide warnings and/or other safe guards to +reduce risk of accidental removal.
+It is recommended that an implementer on a platform where Platform Required +cannot be set contribute a list of Partition type GUIDs for protective +partitions to the table below. It is further recommended that disk partitioning +utilities treat such partitions in the same manner as those with the Platform +Required Attribute Flag set.
++--------------------------------------+---------------------------------------+ +| Partition type GUID | Comment | ++======================================+=======================================+ +| 00000000-0000-0000-0000-000000000000 | Unused entry (example; do not honour) | ++--------------------------------------+---------------------------------------+
+MBR partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have a partition type of 0xF8 unless some +immutable feature of the platform makes this impossible.
+It is recommended that disk partitioning utilities treat such +partitions in the same manner as GPT partitions with the Platform +Required Attribute Flag set.
+It is strongly recommended that protective partitions with a type other +than 0xF8 be placed within 1MB of the start of the disk.
What does this sentence mean?
Which bit is unclear?
Based on your feedback and Grant's then how about:
It is recommended that pre-installed protective partitions that are not type 0xF8 be located wholly within 1MB of the start of the disk.
Automatic disk partitioning utilities shall not create partitions within 1MB of the start of the disk. Manual disk partitioning utilities should avoid recommending that partitions start within 1MB of the start of the disk.
Daniel.
On 05/23/2018 03:12 PM, Daniel Thompson wrote:
On Tue, May 22, 2018 at 09:31:16PM +0100, Grant Likely wrote:
Hi Daniel,
Thanks for writing this. Good job. Comments below.
On 22/05/2018 20:17, Daniel Thompson wrote:
Fixes: #3 Fixed: #8 Signed-off-by: Daniel Thompson daniel.thompson@linaro.org
Nit: I'd like to maintain good patch practice. Please include commit description in patches.
Will do.
Notes: This patch tries to capture contributions from a long a varied discussion. I hope I haven't missed anything major.
Thanks to all the contributors to this topic so far!source/ebbr.rst | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 40f03f173bd9..30a9c6ac2666 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -185,6 +185,53 @@ System Volume Format
The system firmware must support GPT partitioning. +It may optionally also support MBR partitioning.
I think there are two sides of this; what the firmware supports, and what the OS supports. Should we specify this?
For the firmware: GPT required, MBR optional For the OS: GPT & MBR required
Looking at this fresh eyes, the UEFI spec requires GPT, MBR and el torito.
Is there any need to EBBR to say *anything* on this topic of what firmware and OS supports, except to require (where not impossible) that any pre-formatted media use GPT?
In other words maybe just delete this paragraph.
Should it also specify that GPT partitioning must strictly follow the UEFI specification, and must not use a hybrid-MBR?
Can do, although like the above, we would merely be restating part of the UEFI spec.
+On systems where the system firmware binaries reside on the System Volume then +the System Volume must be pre-configured with a partition table and include +protective partitions to reduce risk of accidental destruction of the system +firmware.
+All pre-configured partition tables must use GPT partitioning unless +some immutable feature of the platform (such as a mask programmed boot ROM) +makes this impossible; on such platforms MBR partitioning may be +used as an alternative
Looks good. It would be useful to have some discussion about the possible scenarios, and how this plays out.
In this patch or in examples in the informative sections of the doc?
+GPT partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have the Platform Required Attribute Flag set +unless some immutable feature of the platform makes this impossible.
Do we know of any platforms where Platform Required cannot be set? If not, then I would drop the caveat.
Nothing in the wiki, although there is the certainly evidence of ROMish parsing of GPT tables [and therefore potential for touble ;-) ].
+It is recommended that automatic system disk partitioning utilities > +preserve Platform Required partitions as is, and that manual disk +partitioning utilities provide warnings and/or other safe guards to +reduce risk of accidental removal
Suggested reword: Automatic system disk partitioning utilities shall preserve Platform Required partitions as is. Manual disk partitioning utilities should provide warnings and/or other safe guards to reduce the risk of accidental removal.
Looks good, but if we're upgrading from should to shall then I want to work in the "unless it recognizes this partition" language from UEFI spec (in case of spurious bad labelling).
Will do this in the next revision.
+It is recommended that an implementer on a platform where Platform Required +cannot be set contribute a list of Partition type GUIDs for protective +partitions to the table below. It is further recommended that disk partitioning +utilities treat such partitions in the same manner as those with the Platform +Required Attribute Flag set.
++--------------------------------------+---------------------------------------+ +| Partition type GUID | Comment | ++======================================+=======================================+ +| 00000000-0000-0000-0000-000000000000 | Unused entry (example; do not honour) | ++--------------------------------------+---------------------------------------+
+MBR partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have a partition type of 0xF8 unless some +immutable feature of the platform makes this impossible.
I'd like to be rid of the caveat here too, but there is a lot more legacy to support with MBR.
The known behaviour wiki mentions that RPi dictates 0x0C.
On the RPI we simply use the ESP as firmware partition, so we don't have any need for a protective partition there.
So maybe we could just allow the ESP to have type 0xC instead of 0xEF if dictated by firmware? That should cover all cases except for Altera then which has its bootloader in a 0xAF or so partition.
Alex
On 05/23/2018 03:21 PM, Daniel Thompson wrote:
On Tue, May 22, 2018 at 11:12:26PM +0200, Alexander Graf wrote:
Am 22.05.2018 um 21:17 schrieb Daniel Thompson daniel.thompson@linaro.org:
Fixes: #3 Fixed: #8 Signed-off-by: Daniel Thompson daniel.thompson@linaro.org
Notes: This patch tries to capture contributions from a long a varied discussion. I hope I haven't missed anything major.
Thanks to all the contributors to this topic so far!source/ebbr.rst | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 40f03f173bd9..30a9c6ac2666 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -185,6 +185,53 @@ System Volume Format
The system firmware must support GPT partitioning. +It may optionally also support MBR partitioning.
Please make both mandatory.
Will do (or alternatively will just remove this entirely and rely on the underlying UEFI spec to mandate GPT, MBR and el torito).
+On systems where the system firmware binaries reside on the System Volume then +the System Volume must be pre-configured with a partition table and include +protective partitions to reduce risk of accidental destruction of the system +firmware.
+All pre-configured partition tables must use GPT partitioning unless +some immutable feature of the platform (such as a mask programmed boot ROM) +makes this impossible; on such platforms MBR partitioning may be +used as an alternative.
+GPT partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have the Platform Required Attribute Flag set +unless some immutable feature of the platform makes this impossible.
+It is recommended that automatic system disk partitioning utilities +preserve Platform Required partitions as is, and that manual disk +partitioning utilities provide warnings and/or other safe guards to +reduce risk of accidental removal.
+It is recommended that an implementer on a platform where Platform Required +cannot be set contribute a list of Partition type GUIDs for protective +partitions to the table below. It is further recommended that disk partitioning +utilities treat such partitions in the same manner as those with the Platform +Required Attribute Flag set.
++--------------------------------------+---------------------------------------+ +| Partition type GUID | Comment | ++======================================+=======================================+ +| 00000000-0000-0000-0000-000000000000 | Unused entry (example; do not honour) | ++--------------------------------------+---------------------------------------+
+MBR partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have a partition type of 0xF8 unless some +immutable feature of the platform makes this impossible.
+It is recommended that disk partitioning utilities treat such +partitions in the same manner as GPT partitions with the Platform +Required Attribute Flag set.
+It is strongly recommended that protective partitions with a type other +than 0xF8 be placed within 1MB of the start of the disk.
What does this sentence mean?
Which bit is unclear?
Based on your feedback and Grant's then how about:
It is recommended that pre-installed protective partitions that are not type 0xF8 be located wholly within 1MB of the start of the disk.
Automatic disk partitioning utilities shall not create partitions within 1MB of the start of the disk. Manual disk partitioning utilities should avoid recommending that partitions start within 1MB of the start of the disk.
That paragraph I understand, yes. Thanks :).
Alex
On Wed, May 23, 2018 at 04:08:52PM +0200, Alexander Graf wrote:
+MBR partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have a partition type of 0xF8 unless some +immutable feature of the platform makes this impossible.
I'd like to be rid of the caveat here too, but there is a lot more legacy to support with MBR.
The known behaviour wiki mentions that RPi dictates 0x0C.
On the RPI we simply use the ESP as firmware partition, so we don't have any need for a protective partition there.
Hmmnnnn... this moves towards one of Grants' comments on the need to follow up my work with some rules about managing the ESP. Specifically what tells the OS that formatting the ESP will delete vital firmware (normally it only destroys other OS and firmware *extensions*).
So maybe we could just allow the ESP to have type 0xC instead of 0xEF if dictated by firmware? That should cover all cases except for Altera then which has its bootloader in a 0xAF or so partition.
I think I'm OK with this.
Do we *have* to specify the alternative partition type is 0x0C or can we rely on searching for the EFI/ directory of FAT partitions when no other ESP presents itself? I admit I'm struggling a little to see how the pieces fit together but there are definitely clues that firmware might choose to searching for the EFI directory (albeit for GPT rather than MBR):
"UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID. Partition creators may prevent UEFI firmware from examining and using a specific partition by setting bit 1 of the Partition Attributes"
Daniel.
On 24.05.18 11:16, Daniel Thompson wrote:
On Wed, May 23, 2018 at 04:08:52PM +0200, Alexander Graf wrote:
+MBR partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have a partition type of 0xF8 unless some +immutable feature of the platform makes this impossible.
I'd like to be rid of the caveat here too, but there is a lot more legacy to support with MBR.
The known behaviour wiki mentions that RPi dictates 0x0C.
On the RPI we simply use the ESP as firmware partition, so we don't have any need for a protective partition there.
Hmmnnnn... this moves towards one of Grants' comments on the need to follow up my work with some rules about managing the ESP. Specifically what tells the OS that formatting the ESP will delete vital firmware (normally it only destroys other OS and firmware *extensions*).
Firmware extensions may well be a driver necessary to actually boot the system. I'd be very surprised if any installer thought it was a good idea to remove the ESP. And if they do, it must be considered bad behavior.
So maybe we could just allow the ESP to have type 0xC instead of 0xEF if dictated by firmware? That should cover all cases except for Altera then which has its bootloader in a 0xAF or so partition.
I think I'm OK with this.
Do we *have* to specify the alternative partition type is 0x0C or can we rely on searching for the EFI/ directory of FAT partitions when no other ESP presents itself? I admit I'm struggling a little to see how the pieces fit together but there are definitely clues that firmware might choose to searching for the EFI directory (albeit for GPT rather than MBR):
"UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID. Partition creators may prevent UEFI firmware from examining and using a specific partition by setting bit 1 of the Partition Attributes"
I think what our ESP search order should be is:
* ESP GUID / ESP MBR partition ID * All partitions marked with bootable flag
That should cover all cases IMHO.
Alex
Personally I think we should encourage separate ESP and firmware partitions.
--- Grant Likely Sr. Technical Director SW Engineering
________________________________ From: Alexander Graf agraf@suse.de Sent: Thursday, May 24, 2018 2:00:54 PM To: Daniel Thompson Cc: Grant Likely; boot-architecture@lists.linaro.org; arm.ebbr-discuss Subject: Re: [Arm.ebbr-discuss] [PATCH] Describe protective partitioning for platforms using shared storage
On 24.05.18 11:16, Daniel Thompson wrote:
On Wed, May 23, 2018 at 04:08:52PM +0200, Alexander Graf wrote:
+MBR partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have a partition type of 0xF8 unless some +immutable feature of the platform makes this impossible.
I'd like to be rid of the caveat here too, but there is a lot more legacy to support with MBR.
The known behaviour wiki mentions that RPi dictates 0x0C.
On the RPI we simply use the ESP as firmware partition, so we don't have any need for a protective partition there.
Hmmnnnn... this moves towards one of Grants' comments on the need to follow up my work with some rules about managing the ESP. Specifically what tells the OS that formatting the ESP will delete vital firmware (normally it only destroys other OS and firmware *extensions*).
Firmware extensions may well be a driver necessary to actually boot the system. I'd be very surprised if any installer thought it was a good idea to remove the ESP. And if they do, it must be considered bad behavior.
So maybe we could just allow the ESP to have type 0xC instead of 0xEF if dictated by firmware? That should cover all cases except for Altera then which has its bootloader in a 0xAF or so partition.
I think I'm OK with this.
Do we *have* to specify the alternative partition type is 0x0C or can we rely on searching for the EFI/ directory of FAT partitions when no other ESP presents itself? I admit I'm struggling a little to see how the pieces fit together but there are definitely clues that firmware might choose to searching for the EFI directory (albeit for GPT rather than MBR):
"UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID. Partition creators may prevent UEFI firmware from examining and using a specific partition by setting bit 1 of the Partition Attributes"
I think what our ESP search order should be is:
* ESP GUID / ESP MBR partition ID * All partitions marked with bootable flag
That should cover all cases IMHO.
Alex 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 Thu, May 24, 2018 at 02:55:26PM +0000, Grant Likely wrote:
Personally I think we should encourage separate ESP and firmware partitions.
I'm still on the fence TBH... but whichever way we go I don't think it will contradict anything introduced by this patch. That leaves me inclined to post a github issue and then spin a v2 without mentioning this.
Daniel.
From: Alexander Graf agraf@suse.de Sent: Thursday, May 24, 2018 2:00:54 PM To: Daniel Thompson Cc: Grant Likely; boot-architecture@lists.linaro.org; arm.ebbr-discuss Subject: Re: [Arm.ebbr-discuss] [PATCH] Describe protective partitioning for platforms using shared storage
On 24.05.18 11:16, Daniel Thompson wrote:
On Wed, May 23, 2018 at 04:08:52PM +0200, Alexander Graf wrote:
+MBR partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have a partition type of 0xF8 unless some +immutable feature of the platform makes this impossible.
I'd like to be rid of the caveat here too, but there is a lot more legacy to support with MBR.
The known behaviour wiki mentions that RPi dictates 0x0C.
On the RPI we simply use the ESP as firmware partition, so we don't have any need for a protective partition there.
Hmmnnnn... this moves towards one of Grants' comments on the need to follow up my work with some rules about managing the ESP. Specifically what tells the OS that formatting the ESP will delete vital firmware (normally it only destroys other OS and firmware *extensions*).
Firmware extensions may well be a driver necessary to actually boot the system. I'd be very surprised if any installer thought it was a good idea to remove the ESP. And if they do, it must be considered bad behavior.
So maybe we could just allow the ESP to have type 0xC instead of 0xEF if dictated by firmware? That should cover all cases except for Altera then which has its bootloader in a 0xAF or so partition.
I think I'm OK with this.
Do we *have* to specify the alternative partition type is 0x0C or can we rely on searching for the EFI/ directory of FAT partitions when no other ESP presents itself? I admit I'm struggling a little to see how the pieces fit together but there are definitely clues that firmware might choose to searching for the EFI directory (albeit for GPT rather than MBR):
"UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID. Partition creators may prevent UEFI firmware from examining and using a specific partition by setting bit 1 of the Partition Attributes"
I think what our ESP search order should be is:
- ESP GUID / ESP MBR partition ID
- All partitions marked with bootable flag
That should cover all cases IMHO.
Alex 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 24/05/2018 14:00, Alexander Graf wrote:
On 24.05.18 11:16, Daniel Thompson wrote:
On Wed, May 23, 2018 at 04:08:52PM +0200, Alexander Graf wrote:
+MBR partitioning +^^^^^^^^^^^^^^^^
+Protective partitions should have a partition type of 0xF8 unless some +immutable feature of the platform makes this impossible.
I'd like to be rid of the caveat here too, but there is a lot more legacy to support with MBR.
The known behaviour wiki mentions that RPi dictates 0x0C.
On the RPI we simply use the ESP as firmware partition, so we don't have any need for a protective partition there.
Hmmnnnn... this moves towards one of Grants' comments on the need to follow up my work with some rules about managing the ESP. Specifically what tells the OS that formatting the ESP will delete vital firmware (normally it only destroys other OS and firmware *extensions*).
Firmware extensions may well be a driver necessary to actually boot the system. I'd be very surprised if any installer thought it was a good idea to remove the ESP. And if they do, it must be considered bad behavior.
So maybe we could just allow the ESP to have type 0xC instead of 0xEF if dictated by firmware? That should cover all cases except for Altera then which has its bootloader in a 0xAF or so partition.
I think I'm OK with this.
Do we *have* to specify the alternative partition type is 0x0C or can we rely on searching for the EFI/ directory of FAT partitions when no other ESP presents itself? I admit I'm struggling a little to see how the pieces fit together but there are definitely clues that firmware might choose to searching for the EFI directory (albeit for GPT rather than MBR):
"UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID. Partition creators may prevent UEFI firmware from examining and using a specific partition by setting bit 1 of the Partition Attributes"
I think what our ESP search order should be is:
- ESP GUID / ESP MBR partition ID
- All partitions marked with bootable flag
That should cover all cases IMHO.
That begs the question of whether or not we /want/ to cover all cases. :-) I think EBBR should be quite strict about what firmware is allowed to accept as an ESP; or at least strongly recommend that firmware only boot from partitions with the ESP GUID. Being loose here just means firmware will always have to deal with a wide variety of schemes for ESP partitions.
This goes hand in hand with my opinion that on shared media there should be separate partitions for firmware and the ESP. Firmware can use whatever GUID it likes, and that partition should be marked as protected. (I'd strongly recommend firmware partitions use a filesystem, but that's out of scope for EBBR)
Conversely, EBBR should be really strict about what constitutes an ESP. We can do that if we don't try to conflate the vendor-defined firmware partition and the generic ESP partition.
I could be convinced to soften my position on firmware files being stored in the ESP, provided we define a directory structure for storing vendor firmware files to prevent collisions, and in all other respects the partition is a normal ESP.
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 23/05/2018 14:21, Daniel Thompson wrote:
On Tue, May 22, 2018 at 11:12:26PM +0200, Alexander Graf wrote:
Am 22.05.2018 um 21:17 schrieb Daniel Thompson daniel.thompson@linaro.org:
Fixes: #3 Fixed: #8 Signed-off-by: Daniel Thompson daniel.thompson@linaro.org
Notes: This patch tries to capture contributions from a long a varied discussion. I hope I haven't missed anything major.
Thanks to all the contributors to this topic so far!source/ebbr.rst | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 40f03f173bd9..30a9c6ac2666 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -185,6 +185,53 @@ System Volume Format
The system firmware must support GPT partitioning. +It may optionally also support MBR partitioning.
Please make both mandatory.
Will do (or alternatively will just remove this entirely and rely on the underlying UEFI spec to mandate GPT, MBR and el torito).
As discussed in our meeting this afternoon, I would at the very least make it clear that the partitioning must strictly follow the spec. No clever schemes like hybrid-mbr allowed!
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 Thu, May 24, 2018 at 3:55 PM, Grant Likely Grant.Likely@arm.com wrote:
Personally I think we should encourage separate ESP and firmware partitions.
I tend to agree here.
Also, not directly related but someone referred me to the design spec used by the OpenCompute ONIE (Open Network Install Environment) project.
https://opencomputeproject.github.io/onie/overview/index.html
The u-boot (for PPC/ARM) specifications are quite interesting: https://opencomputeproject.github.io/onie/design-spec/uboot_hw_requirements....
The non-volatile storage requirements and formats was also interesting for things like MAC addresses: https://opencomputeproject.github.io/onie/design-spec/hw_requirements.html
There's likely a bunch of things we could glean and find useful as there's certainly some cross over in this.
Peter
On 25/05/2018 15:41, Peter Robinson wrote:
On Thu, May 24, 2018 at 3:55 PM, Grant Likely Grant.Likely@arm.com wrote:
Personally I think we should encourage separate ESP and firmware partitions.
I tend to agree here.
Also, not directly related but someone referred me to the design spec used by the OpenCompute ONIE (Open Network Install Environment) project.
https://opencomputeproject.github.io/onie/overview/index.html
Very useful. I've got contacts with the ONIE folks. I'll reach out and se if they're interested in participating in EBBR. I suspect they'll continue to prefer their Linux-based installer, but EBBR should simplify ONIE by eliminating any platform specific install paths.
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 30/05/2018 14:04, Grant Likely wrote:
On 25/05/2018 15:41, Peter Robinson wrote:
On Thu, May 24, 2018 at 3:55 PM, Grant Likely Grant.Likely@arm.com wrote:
Personally I think we should encourage separate ESP and firmware partitions.
I tend to agree here.
Also, not directly related but someone referred me to the design spec used by the OpenCompute ONIE (Open Network Install Environment) project.
https://opencomputeproject.github.io/onie/overview/index.html
Very useful. I've got contacts with the ONIE folks. I'll reach out and se if they're interested in participating in EBBR. I suspect they'll continue to prefer their Linux-based installer, but EBBR should simplify ONIE by eliminating any platform specific install paths.
g.
I've sent an email to Curt Brune who leads the ONIE project and invited him to chat with us.
g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
boot-architecture@lists.linaro.org
-
Alexander Graf -
Daniel Thompson -
Grant Likely -
Grant Likely
-
Peter Robinson