On Wed, Sep 02, 2020 at 02:26:26PM +0200, Heinrich Schuchardt wrote:
> On 02.09.20 12:11, Daniel Thompson wrote:
> > On Tue, Sep 01, 2020 at 04:53:49PM +0200, Heinrich Schuchardt wrote:
> >> 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.
> >
> > Not quite sure I agree with that.
> >
> > It certainly means it is not impossible for an EFI app to update firmware
> > components. However not having partitioned block IO protocols sounds
> > like the updater would need to include additional GPT parsing code
> > (although on platforms where the offsets are fixed perhaps the offsets
> > could be burned in instead).
>
> I don't have any strong feelings about that bit being set or not. I
> meant my comment as a question.
Fair enough. As you can infer I'm reluctant to mandate the bit, if only
because the description associated with a RequiredPartition seems to fully
describe the nature of the partition already. It's a weakly held view...
but it is nevertheless held.
> In U-Boot there is currently no support for bit 1 suppressing the
> IO_BLOCK_PROTOCOL.
>
> So this leads to the next question. Shall EBBR require support for bit
> 1, 'No Block IO Protocol' of GPT partitions? If yes, we should write it
> into the EBBR.
I believe that technically this is already a requirement of EBBR. The
language in the UEFI spec is unambiguous ("No Block IO Protocol: If this
bit is set, then firmware must not produce an EFI_BLOCK_IO_PROTOCOL
device for this partition.") and GPT support is an explicit (albeit
conditional) requirement in UEFI section 2.6.2 (which is required for
EBBR compliance).
Daniel.
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
