On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote:
On Wed, 11 Mar 2020 at 12:45, Daniel Thompson daniel.thompson@linaro.org wrote:
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: 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.
We have the following cases:
- FW compatible with GPT (I mean firmware can be searched based on
GUID partition) Ok
- FW that uses offsets and can be positioned at LBA >= 33
Ok Need to define a protective partition
- FW that uses offsets and can be positioned such that space between LBA-2
and LBA-33 is used. Ok in theory as the header states where the partition entries location is specified in a GPT_HEADER "Starting LBA of array of partition entries". Linux kernel properly loads the partition entries if we push them after 16MB.
read_lba https://elixir.bootlin.com/linux/latest/ident/read_lba(state, le64_to_cpu https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu(gpt->partition_entry_lba)
But I bet 2 is hardcoded in many tools...
Agree... but that's "just bugs" and I suspect we could get >90% test coverage for Linux systems just by checking util-linux (and the kernel itself). Maybe for extra style points also check on of the BSDs.
- FW that supposes LBA-1 (macchiatobin the firmware blob that contain TF-A
must be here) In theory OK as Linux will detect bad signature and use the alternate GPT
In the current spec this case isn't materially different to firmware whose boot ROM parses the MBR to load extra code (which wasn't listed above). In both cases the system would be expected to adopt MBR and create protective partitions for the firmware (and accept that the protective partition is vulnerable to damage by auto-partitioning installers).
Having said is this really relevant for MacchiatoBin? Why put EBBR firmware onto shared media? I thought MacchiatoBin could boot from the 4MB SPI NOR.
Daniel.
On 11/03/2020 16:42, Daniel Thompson wrote:
On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote:
On Wed, 11 Mar 2020 at 12:45, Daniel Thompson daniel.thompson@linaro.org wrote:
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: 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.
Yes. I think a hybrid MBR should not be adopted. It is not allowed by the UEFI spec's definition of GPT partitioning. Plus there isn't much point. If there is no way for an existing platform to use GPT, then fall back to MBR and be done with it so that there isn't any ambiguity on how the disk is partitioned. Hybrid MBRs have caused problems in the past.
We have the following cases:
- FW compatible with GPT (I mean firmware can be searched based on
GUID partition) Ok
- FW that uses offsets and can be positioned at LBA >= 33
Ok Need to define a protective partition >>
- FW that uses offsets and can be positioned such that space between LBA-2
and LBA-33 is used. Ok in theory as the header states where the partition entries location is specified in a GPT_HEADER "Starting LBA of array of partition entries". Linux kernel properly loads the partition entries if we push them after 16MB.
read_lba https://elixir.bootlin.com/linux/latest/ident/read_lba(state, le64_to_cpu https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu(gpt->partition_entry_lba)
But I bet 2 is hardcoded in many tools...
Agree... but that's "just bugs" and I suspect we could get >90% test coverage for Linux systems just by checking util-linux (and the kernel itself). Maybe for extra style points also check on of the BSDs.
It is worth stepping back from the details to take a look at the intent. The purpose of this entire section of EBBR is to describe how firmware and the OS can co-exist on the same media device. In broad strokes it means if firmware is stored on the block device, then the OS must constrain how it uses the device.
On platforms with separate firmware storage (e.g., SPI flash or UFS boot partitions) this isn't an issue. The OS can blow away everything on the disk and recreate it.
But when it is an issue, the rules need to lay down what regions (offsets, partitions, or file paths) firmware is allowed to own and what the OS is and is not allowed to do. e.g., the OS is allowed to erase and recreate the OS partitions, but it is not allowed to write a blank GPT or erase the system partition.
I think the EBBR spec should focus on defining exactly what restrictions on the OS are, and how the restrictions are communicated. Then OS vendors have a fighting chance of supporting the restricted platforms well.
Ultimately though this is a guide and the OS could choose to ignore the restrictions... in which case it gets to keep the unbootable brick when it does. :-)
- FW that supposes LBA-1 (macchiatobin the firmware blob that contain TF-A
must be here) In theory OK as Linux will detect bad signature and use the alternate GPT
In the current spec this case isn't materially different to firmware whose boot ROM parses the MBR to load extra code (which wasn't listed above). In both cases the system would be expected to adopt MBR and create protective partitions for the firmware (and accept that the protective partition is vulnerable to damage by auto-partitioning installers).
Having said is this really relevant for MacchiatoBin? Why put EBBR firmware onto shared media? I thought MacchiatoBin could boot from the 4MB SPI NOR.
Yes! This is the preferred solution. All this GPT/MBR restrictions faff and separate storage is always preferred.
g.
On Tue, May 19, 2020 at 03:29:01PM +0100, Grant Likely wrote:
On 11/03/2020 16:42, Daniel Thompson wrote:
On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote:
We have the following cases:
- FW compatible with GPT (I mean firmware can be searched based on
GUID partition) Ok
- FW that uses offsets and can be positioned at LBA >= 33
Ok Need to define a protective partition >>
- FW that uses offsets and can be positioned such that space between LBA-2
and LBA-33 is used. Ok in theory as the header states where the partition entries location is specified in a GPT_HEADER "Starting LBA of array of partition entries". Linux kernel properly loads the partition entries if we push them after 16MB.
read_lba https://elixir.bootlin.com/linux/latest/ident/read_lba(state, le64_to_cpu https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu(gpt->partition_entry_lba)
But I bet 2 is hardcoded in many tools...
Agree... but that's "just bugs" and I suspect we could get >90% test coverage for Linux systems just by checking util-linux (and the kernel itself). Maybe for extra style points also check on of the BSDs.
It is worth stepping back from the details to take a look at the intent. The purpose of this entire section of EBBR is to describe how firmware and the OS can co-exist on the same media device. In broad strokes it means if firmware is stored on the block device, then the OS must constrain how it uses the device.
On platforms with separate firmware storage (e.g., SPI flash or UFS boot partitions) this isn't an issue. The OS can blow away everything on the disk and recreate it.
But when it is an issue, the rules need to lay down what regions (offsets, partitions, or file paths) firmware is allowed to own and what the OS is and is not allowed to do. e.g., the OS is allowed to erase and recreate the OS partitions, but it is not allowed to write a blank GPT or erase the system partition.
I think the EBBR spec should focus on defining exactly what restrictions on the OS are, and how the restrictions are communicated. Then OS vendors have a fighting chance of supporting the restricted platforms well.
Ultimately though this is a guide and the OS could choose to ignore the restrictions... in which case it gets to keep the unbootable brick when it does. :-)
Agree with all above.
Also I think we can turn at least part of the original issue into a concrete question.
We have a SOC with some magic values hard coded into its boot ROM. The System Firmware author wants to ship it with the following GPT on the shared eMMC.
LBA0 Protective MBR LBA1 Primary GPT header LBA2..18001 Reserved, mixture of dead space and a system firmware loaded by Boot rom LBA18002 Start of partition arrray (Entry 1, 2, 3, 4) ... LBA18033 End of partition arrray LBA18034 Start of allocatable partition space LBA-33..-1 End of disk is labelled as normal
(or in a shorter GPT jargon form, a system where PartitionEntryLBA is 18002).
Is such a system EBBR compliant? If yes, should it be?
Daniel.
PS 18002 is arbitrary but I think the example is sufficient in this form and it was easier to diagram with a concrete number.
On Wed, 20 May 2020 at 18:39, Daniel Thompson daniel.thompson@linaro.org wrote:
On Tue, May 19, 2020 at 03:29:01PM +0100, Grant Likely wrote:
On 11/03/2020 16:42, Daniel Thompson wrote:
On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote:
We have the following cases:
- FW compatible with GPT (I mean firmware can be searched based on
GUID partition) Ok
- FW that uses offsets and can be positioned at LBA >= 33
Ok Need to define a protective partition >>
- FW that uses offsets and can be positioned such that space between
LBA-2
and LBA-33 is used. Ok in theory as the header states where the partition entries
location is
specified in a GPT_HEADER "Starting LBA of array of partition
entries".
Linux kernel properly loads the partition entries if we push them
after
16MB.
read_lba <https://elixir.bootlin.com/linux/latest/ident/read_lba
(state,
le64_to_cpu <
https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu
(gpt->partition_entry_lba)
But I bet 2 is hardcoded in many tools...
Agree... but that's "just bugs" and I suspect we could get >90% test coverage for Linux systems just by checking util-linux (and the kernel itself). Maybe for extra style points also check on of the BSDs.
It is worth stepping back from the details to take a look at the intent.
The
purpose of this entire section of EBBR is to describe how firmware and
the
OS can co-exist on the same media device. In broad strokes it means if firmware is stored on the block device, then the OS must constrain how it uses the device.
On platforms with separate firmware storage (e.g., SPI flash or UFS boot partitions) this isn't an issue. The OS can blow away everything on the
disk
and recreate it.
But when it is an issue, the rules need to lay down what regions
(offsets,
partitions, or file paths) firmware is allowed to own and what the OS is
and
is not allowed to do. e.g., the OS is allowed to erase and recreate the
OS
partitions, but it is not allowed to write a blank GPT or erase the
system
partition.
I think the EBBR spec should focus on defining exactly what restrictions
on
the OS are, and how the restrictions are communicated. Then OS vendors
have
a fighting chance of supporting the restricted platforms well.
Ultimately though this is a guide and the OS could choose to ignore the restrictions... in which case it gets to keep the unbootable brick when
it
does. :-)
Agree with all above.
Also I think we can turn at least part of the original issue into a concrete question.
We have a SOC with some magic values hard coded into its boot ROM. The System Firmware author wants to ship it with the following GPT on the shared eMMC.
LBA0 Protective MBR LBA1 Primary GPT header LBA2..18001 Reserved, mixture of dead space and a system firmware loaded by Boot rom LBA18002 Start of partition arrray (Entry 1, 2, 3, 4) ... LBA18033 End of partition arrray LBA18034 Start of allocatable partition space LBA-33..-1 End of disk is labelled as normal
(or in a shorter GPT jargon form, a system where PartitionEntryLBA is 18002).
Is such a system EBBR compliant? If yes, should it be?
I would say it is not EBBR compliant because it does not follow EFI spec
and we mandate it in EBBR. Is the use case "valid"? I think it is valid because when you deal with immutable BootROM you don't want complex code, GPT may evolve so that you would have to evolve the BootROM... If we conclude this is a valid use case (and not creating ugly legacy to deal with in the future), we need a clean reservation in EFI so that GPT can start at an arbitrary LBA as 18002. enhancing the protective MBR semantics does not seem too complex to achieve. Can we list SoCs that have similar characteristic?
Daniel.
PS 18002 is arbitrary but I think the example is sufficient in this form and it was easier to diagram with a concrete number.
On Wed, May 20, 2020 at 07:00:53PM +0200, François Ozog wrote:
On Wed, 20 May 2020 at 18:39, Daniel Thompson daniel.thompson@linaro.org wrote:
On Tue, May 19, 2020 at 03:29:01PM +0100, Grant Likely wrote:
On 11/03/2020 16:42, Daniel Thompson wrote:
On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote:
We have the following cases:
- FW compatible with GPT (I mean firmware can be searched based on
GUID partition) Ok
- FW that uses offsets and can be positioned at LBA >= 33
Ok Need to define a protective partition >>
- FW that uses offsets and can be positioned such that space between
LBA-2
and LBA-33 is used. Ok in theory as the header states where the partition entries
location is
specified in a GPT_HEADER "Starting LBA of array of partition
entries".
Linux kernel properly loads the partition entries if we push them
after
16MB.
read_lba <https://elixir.bootlin.com/linux/latest/ident/read_lba
(state,
le64_to_cpu <
https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu
(gpt->partition_entry_lba)
But I bet 2 is hardcoded in many tools...
Agree... but that's "just bugs" and I suspect we could get >90% test coverage for Linux systems just by checking util-linux (and the kernel itself). Maybe for extra style points also check on of the BSDs.
It is worth stepping back from the details to take a look at the intent.
The
purpose of this entire section of EBBR is to describe how firmware and
the
OS can co-exist on the same media device. In broad strokes it means if firmware is stored on the block device, then the OS must constrain how it uses the device.
On platforms with separate firmware storage (e.g., SPI flash or UFS boot partitions) this isn't an issue. The OS can blow away everything on the
disk
and recreate it.
But when it is an issue, the rules need to lay down what regions
(offsets,
partitions, or file paths) firmware is allowed to own and what the OS is
and
is not allowed to do. e.g., the OS is allowed to erase and recreate the
OS
partitions, but it is not allowed to write a blank GPT or erase the
system
partition.
I think the EBBR spec should focus on defining exactly what restrictions
on
the OS are, and how the restrictions are communicated. Then OS vendors
have
a fighting chance of supporting the restricted platforms well.
Ultimately though this is a guide and the OS could choose to ignore the restrictions... in which case it gets to keep the unbootable brick when
it
does. :-)
Agree with all above.
Also I think we can turn at least part of the original issue into a concrete question.
We have a SOC with some magic values hard coded into its boot ROM. The System Firmware author wants to ship it with the following GPT on the shared eMMC.
LBA0 Protective MBR LBA1 Primary GPT header LBA2..18001 Reserved, mixture of dead space and a system firmware loaded by Boot rom LBA18002 Start of partition arrray (Entry 1, 2, 3, 4) ... LBA18033 End of partition arrray LBA18034 Start of allocatable partition space LBA-33..-1 End of disk is labelled as normal
(or in a shorter GPT jargon form, a system where PartitionEntryLBA is 18002).
Is such a system EBBR compliant? If yes, should it be?
I would say it is not EBBR compliant because it does not follow EFI spec
and we mandate it in EBBR.
Sure, if there is language in the EFI spec that prohibits this then the answer is a no brainer.
Assuming you've found such language could you quote your references? ;-)
Daniel.
Is the use case "valid"? I think it is valid because when you deal with immutable BootROM you don't want complex code, GPT may evolve so that you would have to evolve the BootROM... If we conclude this is a valid use case (and not creating ugly legacy to deal with in the future), we need a clean reservation in EFI so that GPT can start at an arbitrary LBA as 18002. enhancing the protective MBR semantics does not seem too complex to achieve. Can we list SoCs that have similar characteristic?
Daniel.
PS 18002 is arbitrary but I think the example is sufficient in this form and it was easier to diagram with a concrete number.
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
On 20/05/2020 18:00, François Ozog wrote:
On Wed, 20 May 2020 at 18:39, Daniel Thompson <daniel.thompson@linaro.org mailto:daniel.thompson@linaro.org> wrote:
On Tue, May 19, 2020 at 03:29:01PM +0100, Grant Likely wrote: > On 11/03/2020 16:42, Daniel Thompson wrote: > > On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote: > > > We have the following cases: > > > > > > - FW compatible with GPT (I mean firmware can be searched based on > > > GUID partition) > > > Ok > > > > > > - FW that uses offsets and can be positioned at LBA >= 33 > > > Ok > > > Need to define a protective partition >> > > > - FW that uses offsets and can be positioned such that space between LBA-2 > > > and LBA-33 is used. > > > Ok in theory as the header states where the partition entries location is > > > specified in a GPT_HEADER "Starting LBA of array of partition entries". > > > Linux kernel properly loads the partition entries if we push them after > > > 16MB. > > > > > > read_lba <https://elixir.bootlin.com/linux/latest/ident/read_lba>(state, > > > le64_to_cpu <https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu>(gpt->partition_entry_lba) > > > > > > But I bet 2 is hardcoded in many tools... > > > > Agree... but that's "just bugs" and I suspect we could get >90% test > > coverage for Linux systems just by checking util-linux (and the kernel > > itself). Maybe for extra style points also check on of the BSDs. > > It is worth stepping back from the details to take a look at the intent. The > purpose of this entire section of EBBR is to describe how firmware and the > OS can co-exist on the same media device. In broad strokes it means if > firmware is stored on the block device, then the OS must constrain how it > uses the device. > > On platforms with separate firmware storage (e.g., SPI flash or UFS boot > partitions) this isn't an issue. The OS can blow away everything on the disk > and recreate it. > > But when it is an issue, the rules need to lay down what regions (offsets, > partitions, or file paths) firmware is allowed to own and what the OS is and > is not allowed to do. e.g., the OS is allowed to erase and recreate the OS > partitions, but it is not allowed to write a blank GPT or erase the system > partition. > > I think the EBBR spec should focus on defining exactly what restrictions on > the OS are, and how the restrictions are communicated. Then OS vendors have > a fighting chance of supporting the restricted platforms well. > > Ultimately though this is a guide and the OS could choose to ignore the > restrictions... in which case it gets to keep the unbootable brick when it > does. :-) Agree with all above. Also I think we can turn at least part of the original issue into a concrete question. We have a SOC with some magic values hard coded into its boot ROM. The System Firmware author wants to ship it with the following GPT on the shared eMMC. LBA0 Protective MBR LBA1 Primary GPT header LBA2..18001 Reserved, mixture of dead space and a system firmware loaded by Boot rom LBA18002 Start of partition arrray (Entry 1, 2, 3, 4) ... LBA18033 End of partition arrray LBA18034 Start of allocatable partition space LBA-33..-1 End of disk is labelled as normal (or in a shorter GPT jargon form, a system where PartitionEntryLBA is 18002). Is such a system EBBR compliant? If yes, should it be?I would say it is not EBBR compliant because it does not follow EFI spec and we mandate it in EBBR.
Not quite that cut and dry. We have the ability to specify exceptions to what UEFI specifies where it is warranted to do so.
In this particular example the GPT looks like it is entirely spec-compliant, but if the OS recreates the GPT without accounting for the firmware space then it results in a dead platform. Within spec, but with behaviour an OS might not be prepared for. In this case EBBR should specify how the OS knows not to mess with the GPT layout.
g.
Is the use case "valid"? I think it is valid because when you deal with immutable BootROM you don't want complex code, GPT may evolve so that you would have to evolve the BootROM... If we conclude this is a valid use case (and not creating ugly legacy to deal with in the future), we need a clean reservation in EFI so that GPT can start at an arbitrary LBA as 18002. enhancing the protective MBR semantics does not seem too complex to achieve. Can we list SoCs that have similar characteristic?
Daniel. PS 18002 is arbitrary but I think the example is sufficient in this form and it was easier to diagram with a concrete number.-- François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ T: +33.67221.6485 francois.ozog@linaro.org mailto:francois.ozog@linaro.org | Skype: ffozog
On 20.05.20 18:39, Daniel Thompson wrote:
On Tue, May 19, 2020 at 03:29:01PM +0100, Grant Likely wrote:
On 11/03/2020 16:42, Daniel Thompson wrote:
On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote:
We have the following cases:
- FW compatible with GPT (I mean firmware can be searched based on
GUID partition) Ok
- FW that uses offsets and can be positioned at LBA >= 33
Ok Need to define a protective partition >>
- FW that uses offsets and can be positioned such that space between LBA-2
and LBA-33 is used. Ok in theory as the header states where the partition entries location is specified in a GPT_HEADER "Starting LBA of array of partition entries". Linux kernel properly loads the partition entries if we push them after 16MB.
read_lba https://elixir.bootlin.com/linux/latest/ident/read_lba(state, le64_to_cpu https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu(gpt->partition_entry_lba)
But I bet 2 is hardcoded in many tools...
Agree... but that's "just bugs" and I suspect we could get >90% test coverage for Linux systems just by checking util-linux (and the kernel itself). Maybe for extra style points also check on of the BSDs.
It is worth stepping back from the details to take a look at the intent. The purpose of this entire section of EBBR is to describe how firmware and the OS can co-exist on the same media device. In broad strokes it means if firmware is stored on the block device, then the OS must constrain how it uses the device.
On platforms with separate firmware storage (e.g., SPI flash or UFS boot partitions) this isn't an issue. The OS can blow away everything on the disk and recreate it.
But when it is an issue, the rules need to lay down what regions (offsets, partitions, or file paths) firmware is allowed to own and what the OS is and is not allowed to do. e.g., the OS is allowed to erase and recreate the OS partitions, but it is not allowed to write a blank GPT or erase the system partition.
I think the EBBR spec should focus on defining exactly what restrictions on the OS are, and how the restrictions are communicated. Then OS vendors have a fighting chance of supporting the restricted platforms well.
Ultimately though this is a guide and the OS could choose to ignore the restrictions... in which case it gets to keep the unbootable brick when it does. :-)
Agree with all above.
Also I think we can turn at least part of the original issue into a concrete question.
We have a SOC with some magic values hard coded into its boot ROM. The System Firmware author wants to ship it with the following GPT on the shared eMMC.
LBA0 Protective MBR LBA1 Primary GPT header LBA2..18001 Reserved, mixture of dead space and a system firmware loaded by Boot rom LBA18002 Start of partition arrray (Entry 1, 2, 3, 4) ... LBA18033 End of partition arrray LBA18034 Start of allocatable partition space LBA-33..-1 End of disk is labelled as normal
(or in a shorter GPT jargon form, a system where PartitionEntryLBA is 18002).
Is such a system EBBR compliant? If yes, should it be?
Where UEFI wants to restrict possible GPT header values it is mentioned explicitly in the spec, e.g. SizeOfPartitionEntry has to be a power of two and be at least 128. The UEFI 2.8 spec does not prescribe values for PartitionEntryLBA and NumberOfPartitionEntries.
Many tools default to PartitionEntryLBA = 2, SizeOfPartitionEntry = 128 and NumberOfPartitionEntries = 128 which is a sensible choice in many cases.
If a tool or operating system cannot work with PartitionEntryLBA > 2, SizeOfPartitionEntry > 128 or NumberOfPartitionEntries != 128, it is simply not UEFI compliant and should be fixed.
So you should be fine as long as the first GPT table resides in the first 2 TiB assuming an LBA size of 512 bytes.
The requirement to be written into the EBBR is that a firmware MUST be able to deal with GPTs with PartitionEntryLBA > 2, SizeOfPartitionEntry
128, and NumberOfPartitionEntries != 128 to be EBBR compliant.
U-Boot can use such GPTs. It does not yet support creating them via the 'gpt write' command. - But the creation of partition tables should not be in the scope of the EBBR.
Best regards
Heinrich
Daniel.
PS 18002 is arbitrary but I think the example is sufficient in this form and it was easier to diagram with a concrete number.
On 20/05/2020 18:40, Heinrich Schuchardt wrote:
On 20.05.20 18:39, Daniel Thompson wrote:
On Tue, May 19, 2020 at 03:29:01PM +0100, Grant Likely wrote:
On 11/03/2020 16:42, Daniel Thompson wrote:
On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote:
We have the following cases:
- FW compatible with GPT (I mean firmware can be searched based on
GUID partition) Ok
- FW that uses offsets and can be positioned at LBA >= 33
Ok Need to define a protective partition >>
- FW that uses offsets and can be positioned such that space between LBA-2
and LBA-33 is used. Ok in theory as the header states where the partition entries location is specified in a GPT_HEADER "Starting LBA of array of partition entries". Linux kernel properly loads the partition entries if we push them after 16MB.
read_lba https://elixir.bootlin.com/linux/latest/ident/read_lba(state, le64_to_cpu https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu(gpt->partition_entry_lba)
But I bet 2 is hardcoded in many tools...
Agree... but that's "just bugs" and I suspect we could get >90% test coverage for Linux systems just by checking util-linux (and the kernel itself). Maybe for extra style points also check on of the BSDs.
It is worth stepping back from the details to take a look at the intent. The purpose of this entire section of EBBR is to describe how firmware and the OS can co-exist on the same media device. In broad strokes it means if firmware is stored on the block device, then the OS must constrain how it uses the device.
On platforms with separate firmware storage (e.g., SPI flash or UFS boot partitions) this isn't an issue. The OS can blow away everything on the disk and recreate it.
But when it is an issue, the rules need to lay down what regions (offsets, partitions, or file paths) firmware is allowed to own and what the OS is and is not allowed to do. e.g., the OS is allowed to erase and recreate the OS partitions, but it is not allowed to write a blank GPT or erase the system partition.
I think the EBBR spec should focus on defining exactly what restrictions on the OS are, and how the restrictions are communicated. Then OS vendors have a fighting chance of supporting the restricted platforms well.
Ultimately though this is a guide and the OS could choose to ignore the restrictions... in which case it gets to keep the unbootable brick when it does. :-)
Agree with all above.
Also I think we can turn at least part of the original issue into a concrete question.
We have a SOC with some magic values hard coded into its boot ROM. The System Firmware author wants to ship it with the following GPT on the shared eMMC.
LBA0 Protective MBR LBA1 Primary GPT header LBA2..18001 Reserved, mixture of dead space and a system firmware loaded by Boot rom LBA18002 Start of partition arrray (Entry 1, 2, 3, 4) ... LBA18033 End of partition arrray LBA18034 Start of allocatable partition space LBA-33..-1 End of disk is labelled as normal
(or in a shorter GPT jargon form, a system where PartitionEntryLBA is 18002).
Is such a system EBBR compliant? If yes, should it be?
Where UEFI wants to restrict possible GPT header values it is mentioned explicitly in the spec, e.g. SizeOfPartitionEntry has to be a power of two and be at least 128. The UEFI 2.8 spec does not prescribe values for PartitionEntryLBA and NumberOfPartitionEntries.
Many tools default to PartitionEntryLBA = 2, SizeOfPartitionEntry = 128 and NumberOfPartitionEntries = 128 which is a sensible choice in many cases.
If a tool or operating system cannot work with PartitionEntryLBA > 2, SizeOfPartitionEntry > 128 or NumberOfPartitionEntries != 128, it is simply not UEFI compliant and should be fixed.
So you should be fine as long as the first GPT table resides in the first 2 TiB assuming an LBA size of 512 bytes.
The requirement to be written into the EBBR is that a firmware MUST be able to deal with GPTs with PartitionEntryLBA > 2, SizeOfPartitionEntry
128, and NumberOfPartitionEntries != 128 to be EBBR compliant.
U-Boot can use such GPTs. It does not yet support creating them via the 'gpt write' command. - But the creation of partition tables should not be in the scope of the EBBR.
That all sounds reasonable. Let me try drafting an update to the spec...
How does this look?
g.
--- From 4593cf03fd652448de0e3fe912c7ae9467850e78 Mon Sep 17 00:00:00 2001 From: Grant Likely grant.likely@arm.com Date: Mon, 25 May 2020 20:52:31 +0100 Subject: [PATCH] Attempt to refine firmware shared storage requirements.
Signed-off-by: Grant Likely grant.likely@arm.com --- source/chapter4-firmware-media.rst | 67 +++++++++++++++++++++++------- 1 file changed, 51 insertions(+), 16 deletions(-)
diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware-media.rst index fc71274..65da603 100644 --- a/source/chapter4-firmware-media.rst +++ b/source/chapter4-firmware-media.rst @@ -47,13 +47,19 @@ conflict with normal usage of the media by an OS. Partitioning of Shared Storage ==============================
-A shared storage device shall use GPT partitioning unless it is incompatible -with the platform boot sequence. -In which case, MBR partitioning shall be used. [#MBRReqExample]_ - -.. [#MBRReqExample] For example, if the boot ROM doesn't understand GPT - partitioning, and will only work with an MBR, then the storage must be - partitioned using an MBR. +The shared storage device must use the GUID Partition Table (GPT) disk +layout as defined in [UEFI]_ § 5.3, unless the platform boot sequence is +fundamentally incompatible with the GPT disk layout. +In which case, a legacy Master Boot Recored (MBR) must be used. +[#MBRReqExample]_ + +.. [#MBRReqExample] For example, if the SoC boot ROM requires an MBR to + find the next stage firmware image, then it is incompatible with + the GPT boot layout. + Similarly, if the boot ROM expects the next stage firmware to be located + at LBA1 (the location of the GPT Header), then it is incompatible with + the GPT disk layout. + In both cases the shared storage device must use legacy MBR partitioning.
.. warning::
@@ -71,15 +77,14 @@ the partition(s) containing firmware.
However, some SoCs load firmware from a fixed offset into the storage media. In this case, to protect against partitioning tools overwriting firmware, the -firmware image shall either reside entirely within the first 1MiB of storage, -or should be covered by a protective partition entry in the partition table as +partition table must be formed in a way to protect the firmware image(s) as described in sections :ref:`section-gpt-parts` and :ref:`section-mbr-parts`.
-Automatic partitioning tools (e.g. an OS installer) must not create -partitions within the first 1MiB of storage, or delete, move, or modify -protective partition entries. +Automatic partitioning tools (e.g. an OS installer) must not +delete the protective information in the partition table, or +delete, move, or modify protective partition entries. Manual partitioning tools should provide warnings when modifying -protective partitions or creating partitions within the first 1MiB. +protective partitions.
.. warning::
@@ -95,19 +100,49 @@ GPT partitioning ----------------
The partition table must strictly conform to the UEFI specification and include -a protective MBR authored exactly as described in [UEFI]_ § 5 (hybrid +a protective MBR authored exactly as described in [UEFI]_ § 5.3 (hybrid partitioning schemes are not permitted).
-Protective partitions must have the Platform Required Attribute Flag set. +Fixed-location firmware images must be protected by creating protective +partition entries, or by placing GPT data structures away from the LBAs +occupied by firmware, + +Protective partitions are entries in the partition table that cover the +LBA region occupied by firmware and have the 'Required Partition' attribute +set. +A protective partition must use a `PartitionTypeGUID` that identifies it +as a firmware protective partition. (e.g., don't reuse a GUID used by +non-protective partitions). +There are no requirements on the contents or layout of the firmware +protective partition. + +Placing GPT data structures away from firmware images can be accomplished by +adjusting the GUID Partition Entry array location +(adjusting the values of `PartitionEntryLBA` and `NumberOfPartitionEntries`, +and `SizeOfPartitionEntry`), +or by specifying the usable LBAs (Choosing `FirstUsableLBA`/`LastUsableLBA` +to not overlap the fixed firmware location). +See [UEFI]_ § 5.3.2. + +Given the choice, platforms should use protective partitions over +adjusting the placement of GPT data structures because protective partitions +provide explicit information about the protected region.
.. _section-mbr-parts:
MBR partitioning ^^^^^^^^^^^^^^^^
-Protective partitions should have a partition type of 0xF8 unless some +If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible.
+OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions. + .. _section-fw-partition-fs:
Firmware Partition Filesystem
On Mon, 25 May 2020 at 21:55, Grant Likely grant.likely@arm.com wrote:
On 20/05/2020 18:40, Heinrich Schuchardt wrote:
On 20.05.20 18:39, Daniel Thompson wrote:
On Tue, May 19, 2020 at 03:29:01PM +0100, Grant Likely wrote:
On 11/03/2020 16:42, Daniel Thompson wrote:
On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote:
We have the following cases:
- FW compatible with GPT (I mean firmware can be searched based on
GUID partition) Ok
- FW that uses offsets and can be positioned at LBA >= 33
Ok Need to define a protective partition >>
- FW that uses offsets and can be positioned such that space between
LBA-2
and LBA-33 is used. Ok in theory as the header states where the partition entries
location is
specified in a GPT_HEADER "Starting LBA of array of partition
entries".
Linux kernel properly loads the partition entries if we push them
after
16MB.
read_lba <https://elixir.bootlin.com/linux/latest/ident/read_lba
(state,
le64_to_cpu <
https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu
(gpt->partition_entry_lba)
But I bet 2 is hardcoded in many tools...
Agree... but that's "just bugs" and I suspect we could get >90% test coverage for Linux systems just by checking util-linux (and the kernel itself). Maybe for extra style points also check on of the BSDs.
It is worth stepping back from the details to take a look at the
intent. The
purpose of this entire section of EBBR is to describe how firmware and
the
OS can co-exist on the same media device. In broad strokes it means if firmware is stored on the block device, then the OS must constrain how
it
uses the device.
On platforms with separate firmware storage (e.g., SPI flash or UFS
boot
partitions) this isn't an issue. The OS can blow away everything on
the disk
and recreate it.
But when it is an issue, the rules need to lay down what regions
(offsets,
partitions, or file paths) firmware is allowed to own and what the OS
is and
is not allowed to do. e.g., the OS is allowed to erase and recreate
the OS
partitions, but it is not allowed to write a blank GPT or erase the
system
partition.
I think the EBBR spec should focus on defining exactly what
restrictions on
the OS are, and how the restrictions are communicated. Then OS vendors
have
a fighting chance of supporting the restricted platforms well.
Ultimately though this is a guide and the OS could choose to ignore the restrictions... in which case it gets to keep the unbootable brick
when it
does. :-)
Agree with all above.
Also I think we can turn at least part of the original issue into a concrete question.
We have a SOC with some magic values hard coded into its boot ROM. The System Firmware author wants to ship it with the following GPT on the shared eMMC.
LBA0 Protective MBR LBA1 Primary GPT header LBA2..18001 Reserved, mixture of dead space and a system firmware loaded by Boot rom LBA18002 Start of partition arrray (Entry 1, 2, 3, 4) ... LBA18033 End of partition arrray LBA18034 Start of allocatable partition space LBA-33..-1 End of disk is labelled as normal
(or in a shorter GPT jargon form, a system where PartitionEntryLBA is 18002).
Is such a system EBBR compliant? If yes, should it be?
Where UEFI wants to restrict possible GPT header values it is mentioned explicitly in the spec, e.g. SizeOfPartitionEntry has to be a power of two and be at least 128. The UEFI 2.8 spec does not prescribe values for PartitionEntryLBA and NumberOfPartitionEntries.
Many tools default to PartitionEntryLBA = 2, SizeOfPartitionEntry = 128 and NumberOfPartitionEntries = 128 which is a sensible choice in many
cases.
If a tool or operating system cannot work with PartitionEntryLBA > 2, SizeOfPartitionEntry > 128 or NumberOfPartitionEntries != 128, it is simply not UEFI compliant and should be fixed.
So you should be fine as long as the first GPT table resides in the first 2 TiB assuming an LBA size of 512 bytes.
The requirement to be written into the EBBR is that a firmware MUST be able to deal with GPTs with PartitionEntryLBA > 2, SizeOfPartitionEntry
128, and NumberOfPartitionEntries != 128 to be EBBR compliant.
U-Boot can use such GPTs. It does not yet support creating them via the 'gpt write' command. - But the creation of partition tables should not be in the scope of the EBBR.
That all sounds reasonable. Let me try drafting an update to the spec...
How does this look?
g.
From 4593cf03fd652448de0e3fe912c7ae9467850e78 Mon Sep 17 00:00:00 2001 From: Grant Likely grant.likely@arm.com Date: Mon, 25 May 2020 20:52:31 +0100 Subject: [PATCH] Attempt to refine firmware shared storage requirements.
Signed-off-by: Grant Likely grant.likely@arm.com
source/chapter4-firmware-media.rst | 67 +++++++++++++++++++++++------- 1 file changed, 51 insertions(+), 16 deletions(-)
diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware-media.rst index fc71274..65da603 100644 --- a/source/chapter4-firmware-media.rst +++ b/source/chapter4-firmware-media.rst @@ -47,13 +47,19 @@ conflict with normal usage of the media by an OS. Partitioning of Shared Storage ==============================
-A shared storage device shall use GPT partitioning unless it is incompatible -with the platform boot sequence. -In which case, MBR partitioning shall be used. [#MBRReqExample]_
-.. [#MBRReqExample] For example, if the boot ROM doesn't understand GPT
- partitioning, and will only work with an MBR, then the storage must be
- partitioned using an MBR.
+The shared storage device must use the GUID Partition Table (GPT) disk +layout as defined in [UEFI]_ § 5.3, unless the platform boot sequence is +fundamentally incompatible with the GPT disk layout. +In which case, a legacy Master Boot Recored (MBR) must be used. +[#MBRReqExample]_
+.. [#MBRReqExample] For example, if the SoC boot ROM requires an MBR to
- find the next stage firmware image, then it is incompatible with
- the GPT boot layout.
- Similarly, if the boot ROM expects the next stage firmware to be
located
- at LBA1 (the location of the GPT Header), then it is incompatible with
- the GPT disk layout.
- In both cases the shared storage device must use legacy MBR
partitioning.
.. warning::
@@ -71,15 +77,14 @@ the partition(s) containing firmware.
However, some SoCs load firmware from a fixed offset into the storage media. In this case, to protect against partitioning tools overwriting firmware, the -firmware image shall either reside entirely within the first 1MiB of storage, -or should be covered by a protective partition entry in the partition table as +partition table must be formed in a way to protect the firmware image(s) as described in sections :ref:`section-gpt-parts` and :ref:`section-mbr-parts`.
-Automatic partitioning tools (e.g. an OS installer) must not create -partitions within the first 1MiB of storage, or delete, move, or modify -protective partition entries. +Automatic partitioning tools (e.g. an OS installer) must not +delete the protective information in the partition table, or +delete, move, or modify protective partition entries. Manual partitioning tools should provide warnings when modifying -protective partitions or creating partitions within the first 1MiB. +protective partitions.
.. warning::
@@ -95,19 +100,49 @@ GPT partitioning
The partition table must strictly conform to the UEFI specification and include -a protective MBR authored exactly as described in [UEFI]_ § 5 (hybrid +a protective MBR authored exactly as described in [UEFI]_ § 5.3 (hybrid partitioning schemes are not permitted).
-Protective partitions must have the Platform Required Attribute Flag set. +Fixed-location firmware images must be protected by creating protective +partition entries, or by placing GPT data structures away from the LBAs +occupied by firmware,
+Protective partitions are entries in the partition table that cover the +LBA region occupied by firmware and have the 'Required Partition' attribute +set. +A protective partition must use a `PartitionTypeGUID` that identifies it +as a firmware protective partition. (e.g., don't reuse a GUID used by +non-protective partitions). +There are no requirements on the contents or layout of the firmware +protective partition.
+Placing GPT data structures away from firmware images can be accomplished by +adjusting the GUID Partition Entry array location +(adjusting the values of `PartitionEntryLBA` and `NumberOfPartitionEntries`, +and `SizeOfPartitionEntry`), +or by specifying the usable LBAs (Choosing `FirstUsableLBA`/`LastUsableLBA` +to not overlap the fixed firmware location). +See [UEFI]_ § 5.3.2.
+Given the choice, platforms should use protective partitions over +adjusting the placement of GPT data structures because protective partitions +provide explicit information about the protected region.
.. _section-mbr-parts:
MBR partitioning ^^^^^^^^^^^^^^^^
-Protective partitions should have a partition type of 0xF8 unless some +If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible.
+OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions.
For the boards I work on, fixed locations FIP with (TFA+DDR+SCP+U-Boot) are 1.5MB. Adding OP-TEE and StandaloneMM to get UEFI SecureBoot we are getting close to 4MB. If we add firmwareTPM and measuredBoot, I assume we will reach 4MB. So I wonder if the right value shouldn't be 32MiB (rationale is 4MB/Page rounding; future growth to 8MB; A/B versions:16MB; 2x margin: 32MiB).
.. _section-fw-partition-fs:
Firmware Partition Filesystem
-- 2.20.1
On 26/05/2020 15:30, François Ozog wrote:
On Mon, 25 May 2020 at 21:55, Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> wrote:
[...]
MBR partitioning ^^^^^^^^^^^^^^^^ -Protective partitions should have a partition type of 0xF8 unless some +If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible. +OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions.For the boards I work on, fixed locations FIP with (TFA+DDR+SCP+U-Boot) are 1.5MB. Adding OP-TEE and StandaloneMM to get UEFI SecureBoot we are getting close to 4MB. If we add firmwareTPM and measuredBoot, I assume we will reach 4MB. So I wonder if the right value shouldn't be 32MiB (rationale is 4MB/Page rounding; future growth to 8MB; A/B versions:16MB; 2x margin: 32MiB).
The thinking here is that existing partitioning tools already avoid the first 1MiB of storage by default, so there isn't a massive impact to get distro tooling changed. If a larger limit was chosen then we've got a lot of tooling that needs to be changed, assuming we can get the maintainers of those tools to agree to avoid a larger number of LBAs at the base of storage.
However, in the case that you're describing it is probably possible to switch to GPT partitioning because the firmware image is at a fixed location (unless the fixed firmware begins at LBA1) and the loaded firmware image can be taught to understand GPT.
g.
Le mar. 26 mai 2020 à 16:38, Grant Likely grant.likely@arm.com a écrit :
On 26/05/2020 15:30, François Ozog wrote:
On Mon, 25 May 2020 at 21:55, Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> wrote:
[...]
MBR partitioning ^^^^^^^^^^^^^^^^ -Protective partitions should have a partition type of 0xF8 unlesssome
+If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible. +OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions.For the boards I work on, fixed locations FIP with (TFA+DDR+SCP+U-Boot) are 1.5MB. Adding OP-TEE and StandaloneMM to get UEFI SecureBoot we are getting close to 4MB. If we add firmwareTPM and measuredBoot, I assume we will reach 4MB. So I wonder if the right value shouldn't be 32MiB (rationale is 4MB/Page rounding; future growth to 8MB; A/B versions:16MB; 2x margin: 32MiB).
The thinking here is that existing partitioning tools already avoid the first 1MiB of storage by default, so there isn't a massive impact to get distro tooling changed. If a larger limit was chosen then we've got a lot of tooling that needs to be changed, assuming we can get the maintainers of those tools to agree to avoid a larger number of LBAs at the base of storage.
However, in the case that you're describing it is probably possible to switch to GPT partitioning because the firmware image is at a fixed location (unless the fixed firmware begins at LBA1) and the loaded firmware image can be taught to understand GPT.
ROM That I deal with have this tendency to be stubborn and start loading at LBA1 ;-) so no GPT. Isn’t there a good opportunity to say “recommend” instead of must/shall. Otherwise tool projects can’t get their cues from reliable sources.
g.
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
On Tue, May 26, 2020 at 05:02:04PM +0200, François Ozog wrote:
Le mar. 26 mai 2020 à 16:38, Grant Likely grant.likely@arm.com a écrit :
On 26/05/2020 15:30, François Ozog wrote:
On Mon, 25 May 2020 at 21:55, Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> wrote:
[...]
MBR partitioning ^^^^^^^^^^^^^^^^ -Protective partitions should have a partition type of 0xF8 unlesssome
+If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible. +OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions.For the boards I work on, fixed locations FIP with (TFA+DDR+SCP+U-Boot) are 1.5MB. Adding OP-TEE and StandaloneMM to get UEFI SecureBoot we are getting close to 4MB. If we add firmwareTPM and measuredBoot, I assume we will reach 4MB. So I wonder if the right value shouldn't be 32MiB (rationale is 4MB/Page rounding; future growth to 8MB; A/B versions:16MB; 2x margin: 32MiB).
The thinking here is that existing partitioning tools already avoid the first 1MiB of storage by default, so there isn't a massive impact to get distro tooling changed. If a larger limit was chosen then we've got a lot of tooling that needs to be changed, assuming we can get the maintainers of those tools to agree to avoid a larger number of LBAs at the base of storage.
However, in the case that you're describing it is probably possible to switch to GPT partitioning because the firmware image is at a fixed location (unless the fixed firmware begins at LBA1) and the loaded firmware image can be taught to understand GPT.
ROM That I deal with have this tendency to be stubborn and start loading at LBA1 ;-) so no GPT. Isn’t there a good opportunity to say “recommend” instead of must/shall. Otherwise tool projects can’t get their cues from reliable sources.
Is there any reason that a protective (MBR) partition cannot be used on this system?
Daniel.
On 5/26/20 5:24 PM, Daniel Thompson wrote:
On Tue, May 26, 2020 at 05:02:04PM +0200, François Ozog wrote:
Le mar. 26 mai 2020 à 16:38, Grant Likely grant.likely@arm.com a écrit :
On 26/05/2020 15:30, François Ozog wrote:
On Mon, 25 May 2020 at 21:55, Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> wrote:
[...]
MBR partitioning ^^^^^^^^^^^^^^^^ -Protective partitions should have a partition type of 0xF8 unlesssome
+If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible. +OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions.For the boards I work on, fixed locations FIP with (TFA+DDR+SCP+U-Boot) are 1.5MB. Adding OP-TEE and StandaloneMM to get UEFI SecureBoot we are getting close to 4MB. If we add firmwareTPM and measuredBoot, I assume we will reach 4MB. So I wonder if the right value shouldn't be 32MiB (rationale is 4MB/Page rounding; future growth to 8MB; A/B versions:16MB; 2x margin: 32MiB).
The thinking here is that existing partitioning tools already avoid the first 1MiB of storage by default, so there isn't a massive impact to get distro tooling changed. If a larger limit was chosen then we've got a lot of tooling that needs to be changed, assuming we can get the maintainers of those tools to agree to avoid a larger number of LBAs at the base of storage.
However, in the case that you're describing it is probably possible to switch to GPT partitioning because the firmware image is at a fixed location (unless the fixed firmware begins at LBA1) and the loaded firmware image can be taught to understand GPT.
ROM That I deal with have this tendency to be stubborn and start loading at LBA1 ;-) so no GPT. Isn’t there a good opportunity to say “recommend” instead of must/shall. Otherwise tool projects can’t get their cues from reliable sources.
Is there any reason that a protective (MBR) partition cannot be used on this system?
The UEFI spec requires a protective MBR. This MBR will not indicate any partitions except for a single entry with OStype 0xEE as described in "Table 20. Protective MBR Partition Record protecting the entire disk." of UEFI spec 2.8.
On a GPT partitioned disk all partitions must be after the first GPT table. It is the location of the GPT table that protects the space between the MBR and and the GPT table which we may need for our firmware. A partitioning tool MUST not change the position of the GPT when adding or deleting partitions. Of cause you loose the protection if you write a new partition table.
Best regards
Heinrich
On Tue, May 26, 2020 at 11:28:32PM +0200, Heinrich Schuchardt wrote:
On 5/26/20 5:24 PM, Daniel Thompson wrote:
On Tue, May 26, 2020 at 05:02:04PM +0200, François Ozog wrote:
Le mar. 26 mai 2020 à 16:38, Grant Likely grant.likely@arm.com a écrit :
On 26/05/2020 15:30, François Ozog wrote:
On Mon, 25 May 2020 at 21:55, Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> wrote:
[...]
MBR partitioning ^^^^^^^^^^^^^^^^ -Protective partitions should have a partition type of 0xF8 unlesssome
+If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible. +OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions.For the boards I work on, fixed locations FIP with (TFA+DDR+SCP+U-Boot) are 1.5MB. Adding OP-TEE and StandaloneMM to get UEFI SecureBoot we are getting close to 4MB. If we add firmwareTPM and measuredBoot, I assume we will reach 4MB. So I wonder if the right value shouldn't be 32MiB (rationale is 4MB/Page rounding; future growth to 8MB; A/B versions:16MB; 2x margin: 32MiB).
The thinking here is that existing partitioning tools already avoid the first 1MiB of storage by default, so there isn't a massive impact to get distro tooling changed. If a larger limit was chosen then we've got a lot of tooling that needs to be changed, assuming we can get the maintainers of those tools to agree to avoid a larger number of LBAs at the base of storage.
However, in the case that you're describing it is probably possible to switch to GPT partitioning because the firmware image is at a fixed location (unless the fixed firmware begins at LBA1) and the loaded firmware image can be taught to understand GPT.
ROM That I deal with have this tendency to be stubborn and start loading at LBA1 ;-) so no GPT. Isn’t there a good opportunity to say “recommend” instead of must/shall. Otherwise tool projects can’t get their cues from reliable sources.
Is there any reason that a protective (MBR) partition cannot be used on this system?
The UEFI spec requires a protective MBR. This MBR will not indicate any partitions except for a single entry with OStype 0xEE as described in "Table 20. Protective MBR Partition Record protecting the entire disk." of UEFI spec 2.8.
On a GPT partitioned disk all partitions must be after the first GPT table. It is the location of the GPT table that protects the space between the MBR and and the GPT table which we may need for our firmware. A partitioning tool MUST not change the position of the GPT when adding or deleting partitions. Of cause you loose the protection if you write a new partition table.
I think there may be a misunderstanding here.
I didn't mean why not have a protective MBR.
I mean if François has a system with 32MB of firmware that must start at LBA1 (and hence must be MBR format) when why isn't is sufficient to add a protective partition, with partition type 0xf8, to describe the firmware.
Daniel.
boot-architecture@lists.linaro.org
-
Daniel Thompson -
François Ozog -
Grant Likely -
Heinrich Schuchardt