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 <[email protected]>
wrote:
On Wed, Mar 11, 2020 at 11:20:17AM +0100, Francois Ozog wrote:
On Wed, 11 Mar 2020 at 07:48, Heinrich Schuchardt <[email protected]>
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.
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
