On 01.09.20 16:49, Daniel Thompson wrote: > On Tue, Sep 01, 2020 at 03:55:15PM +0200, Heinrich Schuchardt wrote: >> On 01.09.20 12:59, Grant Likely wrote: >>> The existing language around how firmware and an OS can share a storage >>> device doesn't go into sufficient detail on how the firmware should >>> protect firmware data on the device. Add language for both the GPT and >>> MBR partitioning schemes on how firmware images should be described in >>> the partition table. >>> >>> Signed-off-by: Grant Likely <[email protected]> >>> --- >>> >>> I posted this patch before the v1.0.1 release, but didn't merge it at >>> that time because it needs a little more due diligence than can be give >>> on a minor point release. Posting it now for proper review. >>> >>> 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 >> >> %s/'Required Partition'/bit 0, 'Required Partition'/ >> >>> +set. >> >> Shouldn't we also set bit 1, 'No Block IO Protocol'? > > Would that make it more difficult to write EFI based firmware update > tools (that do know what the partition is used for) to write out > updates?
You would still have the Block IO Protocol on disk level. So no, I do not think this would complicate things. Best regards Heinrich > > >>> +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). >> >> Can we positively define a PartitionTypeGUID here that identifies a >> firmware protective partition, e.g. >> >> "GUID 72c91f31-9307-4668-b6e8-9a9ea07112e1 can be used to mark a >> partition as firmware protective." > > No objections to providing a value but I think it should be strictly > optional (e.g. MAY/OPTIONAL in the SHALL, SHOULD, MAY taxonomy of > requirements). > > > Daniel. > _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
