GPT Partition Flag for "Platform Partition"

[AdrianVovk]

Some devices, namely Android phones, store their UEFI firmware / Android Boot Loader image in the same partition table as the host system. This also includes devices using U-Boot, such as @calebccff's UBoot build for qcom Android devices, devices using Tow-Boot, etc.

Ultimately in all of these cases it would be very bad for partition management software to touch these partitions. Potentially very destructive; it could leave the device bricked.

So I propose that we take inspiration from Microsoft, and introduce a GPT partition flag basically marking these partitions as "owned by the platform". This flag would then be respected by various tools (i.e. systemd-repart, udisks, command-line partitioning tools) however is deemed appropriate for that tool. Command-line tools might raise warnings but let the edits happen anyways, systemd-repart will refuse to touch these partitions and will ensure they're always there (i.e. you can still wipe the disk with repart, but those partitions will remain in the new partition table), etc.

The installers for Tow-Boot, @calebccff's qcom UBoot build, etc. can apply these attributes to all relevant partitions when installing the firmware for the device, thus ensuring that the Linux systems we subsequently boot on these devices don't accidentally brick them.

Microsoft defines this attribute as: GPT_ATTRIBUTE_PLATFORM_REQUIRED 0x0000000000000001

[ricardosalveti]

This is also a requirement coming from EBBR (part of SystemReady IR), as firmware partitions are indeed common on embedded and they shouldn't be modified by the OS installer or at runtime.

From EBBR: https://github.com/ARM-software/ebbr/blob/main/source/chapter4-firmware-media.rst#gpt-partitioning

[AdrianVovk]

Hmm, right. Looks like this value is defined in the UEFI spec.

https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html#defined-gpt-partition-entry-attributes

So it should be documented as part of conforming with the DPS, so Linux tools are more aware of it.

[poettering]

I am not sure I follow, but repart doesn't touch partitions it has no .conf files for. Hence protecting these partitions seems unnecessary, repart at least is not going to touch them anyway.

Also we cannot just invade the partition type's flag space anyway. Half of the bits of th partition flags are owned by the GPT spec, the other half by the individual partition type. Hence we as a 3rd party bystander cannot define new flags for android's partitions, in neither half.

[AdrianVovk]

Repart will definitely touch those partitions if you tell it you want to wipe the disk first, via --empty. What I'm proposing is that even if we're doing that, we should still preserve those partitions

Looks like that flag is already defined by UEFI. sd-gpt even has a #define for it. We just need to use it in places like repart, and installers for firmware like Tow-Boot and Caleb's UBoot-for-Qualcomm need to apply it to partitions that are dangerous to manipulate.

To that end, UAPI group should document these flags, just to raise visibility to the fact that they exist in the first place.

---

For example: I have a OnePlus 6 phone. I want to boot generic UEFI Linux. So I take Caleb's Qualcomm UBoot build, and follow the installation instructions. This ends up erasing Android system/data partitions, installing UBoot, and marking any partitions we can't erase (i.e. the modem's firmware, for example) as "protected" so the OS can never trample over it.

Then when installing a distro on my OP6, the distro installer "wipes the disk" (preserving all the protected partitions) and then installs the OS into the free space. I get a device that still boots, and a functional modem

[poettering]

I figure you mean bit zero? https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html#defined-gpt-partition-entry-attributes

adding a new --empty=reset or so to repart that erases all partitions not marked with bit zero makes a lot of sense to me.

[calebccff]

Thanks for making this issue. I have a lot of thoughts on this, sorry for the wall of text incoming, I've tried to split it into sections...

Qualcomm quirks / issue statement

On the Qualcomm/Android case, for devices with UFS storage most of the important partitions are on separate SCSI LUNs (see gdisk output for all partitions on the op6 here). Ideally we would just be able to do what we want with LUN 0 (the big one where the Android userdata partition is).

There is almost definitely a way to do this, but it varies by device (other phones even with the same SoC have the system partitions on a different LUN for some reason) and there are edge cases like the Android bootloader (which we're stuck with and can never replace, yay secureboot) will hunt for the system partition and crash out if it can't find it, unless you flash a permissive vbmeta configuration.

There are also OEM/vendor specific partitions which may be "required" in the same way (bootloader crashes out if it can't find them even if they're unused), this will vary by vendor, generation, device, and even bootloader version. On the OnePlus 6 we can safely experiment since it's easy to boot into bootROM (EDL) mode and the signed tools needed to re-provision the storage are easily available, but on other devices like the PocoPhone F1 if you mess up the GPT and the bootloader crashes then you're just screwed.

Solution for golden devices like the op6

For devices like the op6 which have

• Accessible bootROM (OnePlus wired it up so you can do a key combo with USB attached to get to bootROM, this is pretty exclusive to OnePlus devices afaik).
• Signed "firehose" loader image available (leaked for basically all OnePlus phones)
• Somewhat sensible bootloader

We can build a custom "rescue package" flashed via the bootROM mode which leaves LUN 0 free for use as well as installing the latest bootloader and other firmware (including U-Boot), this would then be a pre-requisite for folks wanting to run Linux on that device. There's a lot of hurdles but if the device jumps them all then I think this is the ideal solution. In this case setting the reserved attribute is a no-brainer, and something we can do via the rescue package.

On devices that don't meet these requirements I don't think we should advocate for modifying the GPT, since any wrong move could hard brick the device (maybe not it goes to fastboot mode but crashes trying to boot the kernel since some random partition can't be found). A stupid fate for badly designed hardware/firmware.

Qualcomm dev boards / SystemReady

On Qualcomm development boards (like the RB1/2/3/5) we're currently in the process of applying for SystemReady certification. We have a lot more freedom there and on the UFS boards we can implement the above approach. However the RB1/2 boards specifically use eMMC storage instead of UFS, so everything is on a single "LUN". In this case it would be necessary to allow for the Fedora installer (for example) to use the existing ESP/rootfs partitions or erase them and add it's own, without touching any others.

The rescue packages Linaro builds for these boards already includes ESP and rootfs partitions, but obviously this goes against what most Linux installers want to do.

We should update the rescue packages to set the reserved attribute on all the important partitions (and add some sanity check to U-Boot or something). What do you think @lumag ?

Some other solution might be needed

For the worst-case mentioned above where we really don't want to risk messing with the GPT I see a few options:

1. Take the "subpartition" approach like pmOS (putting a partition table on the userdata partition and loop-mounting it), something which requires initramfs support and would need support added in U-Boot as well unless we reuse an existing partition.
2. Reuse the existing partitions without messing with the GPT (U-Boot can already treat any partition with /EFI/BOOT/BOOTAA64.EFI as an ESP I think). system as root, userdata as home, vendor as var, something like that. Notably this doesn't work on devices with a super partition instead.
3. LVM with some tool that maintains a list of safe-to-clobber partitions (super, system, vendor, userdata, etc...). This might make for a nice escape hatch which could be easier to support than the subpartition stuff, but I'm not sure what the story is for dracut and other ramdisks there.
4. Hybrid approach (userdata as home, LVM on super or system/vendor for root and var, esp somewhere else???)