Re: [RFC PATCH] Fill out the system firmware discussion

On Fri, Jun 08, 2018 at 08:57:52PM +0100, Grant Likely wrote:

Add some more detail on how to handle system firmware. I'm still undecided about this, so this patch is more of an RFC discussion than a serious patch. Please comment.

Cc: Daniel Thompson daniel.thompson@linaro.org Signed-off-by: Grant Likely grant.likely@arm.com

---

source/ebbr.rst | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 53 insertions(+), 5 deletions(-)

diff --git a/source/ebbr.rst b/source/ebbr.rst index 3998397..c24cef5 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -200,16 +200,64 @@ System Volume Format The system firmware must support all partitioning standards required by the UEFI specification. -On systems where the system firmware binaries reside on the System Volume then -the System Volume must be pre-configured with a partition table and include -protective partitions to reduce risk of accidental destruction of the system -firmware.

All pre-installed partition tables must use GPT partitioning unless some immutable feature of the platform (such as a mask programmed boot ROM) makes this impossible; on such platforms MBR partitioning may be used as an alternative. +System Firmware Partitions +^^^^^^^^^^^^^^^^^^^^^^^^^^

New title might be called for. I had to look twice at this to be sure it doesn't mean ESP (given what the F in EFI stands for).

+On systems where the system firmware binaries reside on the System Volume then +the System Volume must be pre-configured with a partition table and system +firmware binaries.

+When system firmware is located at a fixed offset, It is strongly recommended +for the partition table to include protective partitions covering the location +of firmware to reduce risk of accidental destruction of the system firmware.

I think this should be required, rather than strongly recommended.

+System boot ROM should obtain the system firmware partition location +by reading the partition table.

Similar, I think the "should" could be safely upgraded to "strongly recommended" too.

+Using a fixed offset into the storage media is deprecated and should +not be used for new SoC designs. +Future issues of this specification will disallow the use of fixed offsets.

+A system firmware partition should not also be used as a EFI System +Partition (ESP). +Pre-installed system firmware partitions must not use the ESP GUID, +and OS installation tools should not install EFI executables in a system +firmware partition.

+.. todo::

• I'm not sure if this is a good idea. It might be that EBBR should define a
• common GUID for system firmware partitions. It also might be that I'm worrying
• too much and it is fine to use the ESP as a system firmware partition.
• This TODO note is a bit of a discussion of the options.
• Options:
• • Require ESP and SFPs to be separate

• - Should a common SFP GUID be defined so a single image can hold firmware
  

•   for multiple platforms?
  

•   - Don't have to repartition to add additional platforms.
  

•     - Yet repartitioning required to add the *first* platform
  

•   - Require FAT formatting?
  

•   - Probably also requires a vendor/soc/file pathname spec to avoid
  

•     conflicts.
  

•   - OS can mount the ESP without touching SFPs. This means firmware could
  

•     perform (mediated) operations on the SPF (ex. to update variables)
  

•     without unmounting the ESP.
  

•   - Downside: Requries at least two fixed sized partitions to boot the
  

•     platform: a SFP, and the ESP. A single combined SFP+ESP would be more
  

•     efficient on space.
  

• • Allow ESP to be used as an SFP

• - Downside: Partitioning/Install tools can't simply blank the ESP to reset
  

•   to scratch
  

I'm certainly in the habit of nuking the ESP during install testing to ensure it gets repopulated correctly. It's a manual act on my part but many GUI installers make it easy to do this.

If we permit a shared ESP is must be discoverable (marked as System Required?) and I think also needs a means to trigger a factory reset.

Likewise is worrying about file system corruption here merited? FAT failure modes can be rather nasty (although its a long time since I've seen one).

• - Upside: platform firmware can be added by simply dropping files
  

•   in the ESP
  

• - Using the ESP filesystem is a more efficient use of space.
  

• - Still need to define pathname spec to avoid conflicts
  

Note that this still doesn't help RPi without a relaxation of partition ID for the ESP (which I'm not very comfortable about).

GPT partitioning ^^^^^^^^^^^^^^^^ -- 2.13.0