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 <[email protected]> a écrit : > >>> On 26/05/2020 15:30, François Ozog wrote: > >>>> On Mon, 25 May 2020 at 21:55, Grant Likely <[email protected] > >>>> <mailto:[email protected]>> 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. > >> > >> 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 mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
