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.