search

ARM-software / ebbr

Embedded Base Boot Requirements Specification
Creative Commons Attribution Share Alike 4.0 International
115 stars 37 forks source link

Firmware Storage: Partition type GUID recommendations #84

Closed samueldr closed 1 year ago

samueldr commented 3 years ago

Hi,

From the Firmware Storage chapter:

https://github.com/ARM-software/ebbr/blob/6dae6fd764e7a0a1111943c41cc3eb7eef3012b0/source/chapter4-firmware-media.rst#L114-L116

I couldn't find a partition type matching something like a firmware protective partition in the few lists I know of:

Is there a non-binding recommendation for such a partition type? Did I miss a source of well-known partition types?

Should the spec recommend (and own) a specific partition type GUID?

Would the partition type be owned by the platform (e.g. SoC) vendor? The board integrator? The firmware provider?

Thank you!

samueldr commented 2 years ago

As far as Tow-Boot is concerned, which sparked this question, the assumption has been that the project itself owns the Type GUID.

As such, the partition type "67401509-72E7-4628-B1AF-EDD128E4316A" represents the protective partition used by the Tow-Boot project when installing a platform firmware to a shared storage area.

daniel-thompson commented 2 years ago

Assuming this GUID is one you have generated yourself then I tinnk that it meets the spec.

The theory is that the RequiredPartition flag is the key piece of information to help automatic partitioning tools make good decisions (e.g. don't delete the partition). The requirement to use a GUID that identifies it as a firmware protective partition is to prevent existing GUIDs being used since they might undermine the confidence in the RequiredPartition flag (e.g. if the firmware happened to use a FAT filesystem internally for variable storage then this is fine... but don't give it a GUID that makes an OS try to mount it).

Thus any party can create a GUID and providing they define what it means (it contains some firmware that is necessary to boot) then it will be "a GUID that identifies it as a firmware protective partition".

PS Personally I'd like there to be a standard or de-facto standard fallback value so that firmware that has no opinions on what GUID to use (e.g. no reason to pick a different one) can pick a common one. This is mostly because having a well known value gives us something to add to partitioning tools so they can present a user-friendly name when they see it.

trini commented 2 years ago

To what granularity should there be GUIDs here? For example, should U-Boot as an upstream project generate one GUID and use it for all platforms? Or one GUID per SoC / SoC family where the firmware magic locations are the same? And then what would be the guidance for customized distributions of U-Boot such as Tow-Boot ?

daniel-thompson commented 2 years ago

To what granularity should there be GUIDs here?

Currently I don't think the spec offers any guidance on this.

Naturally I have an opinion but not an authoritative one! FWIW it is mostly in my PS: few GUIDs are better than many... and one is better than few.

samueldr commented 2 years ago

It would be convenient if there was a default "EBBR Compliant Firmware" GUID type. I figure it would be easier for partitioning utilities to know about a single GUID, than even a handful of GUIDs (per project).

The spec could be worded in a way that makes it the fallback type when another one is not required by the platform. Similarly to how 0xF8 is used with MBR, except if "an immutable feature of the platform makes this impossible". Or worded in a way that makes it an option?

I don't mind either way. I see now that the RequiredPartition is what matters.

xypron commented 2 years ago

Firmware may require multiple partitions with distinct GUIDs.

U-boot may use partition type b000 "U-Boot boot loader "3DE21764-95BD-54BD-A5C3-4ABE786F38A8" for storing the environment. Some devices require U-Boot SPL living in one partition and OpenSBI, device-tree, and main U-Boot (as a FIT image) living in the other partition. Secure world may add a few more partitions.

EBBR may make recommendations for the GUIDs but I think a system that uses vendor GUIDs for its firmware partitioning scheme should not be blemished as non-compliant.

vstehle commented 1 year ago

Protective partitions should have the ‘Required Partition’ attribute set and should not reuse a GUID used by non-protective partitions.

xypron commented 1 year ago

The flag is described in the UEFI specification. In gdisk it is reachable via expert command 'a - attributes' as bit '0: system partition'.