On 24/05/2018 14:00, Alexander Graf wrote:
On 24.05.18 11:16, Daniel Thompson wrote:
On Wed, May 23, 2018 at 04:08:52PM +0200, Alexander Graf wrote:
+MBR partitioning
+^^^^^^^^^^^^^^^^
+
+Protective partitions should have a partition type of 0xF8 unless some
+immutable feature of the platform makes this impossible.
I'd like to be rid of the caveat here too, but there is a lot more
legacy to support with MBR.
The known behaviour wiki mentions that RPi dictates 0x0C.
On the RPI we simply use the ESP as firmware partition, so we don't have any
need for a protective partition there.
Hmmnnnn... this moves towards one of Grants' comments on the need to
follow up my work with some rules about managing the ESP. Specifically
what tells the OS that formatting the ESP will delete vital firmware
(normally it only destroys other OS and firmware *extensions*).
Firmware extensions may well be a driver necessary to actually boot the
system. I'd be very surprised if any installer thought it was a good
idea to remove the ESP. And if they do, it must be considered bad behavior.
So maybe we could just allow the ESP to have type 0xC instead of 0xEF if
dictated by firmware? That should cover all cases except for Altera then
which has its bootloader in a 0xAF or so partition.
I think I'm OK with this.
Do we *have* to specify the alternative partition type is 0x0C or can we
rely on searching for the EFI/ directory of FAT partitions when no other
ESP presents itself? I admit I'm struggling a little to see how the
pieces fit together but there are definitely clues that firmware might
choose to searching for the EFI directory (albeit for GPT rather than
MBR):
"UEFI implementations may allow the use of conforming FAT partitions
which do not use the ESP GUID. Partition creators may prevent UEFI
firmware from examining and using a specific partition by setting bit
1 of the Partition Attributes"
I think what our ESP search order should be is:
* ESP GUID / ESP MBR partition ID
* All partitions marked with bootable flag
That should cover all cases IMHO.
That begs the question of whether or not we /want/ to cover all cases.
:-) I think EBBR should be quite strict about what firmware is allowed
to accept as an ESP; or at least strongly recommend that firmware only
boot from partitions with the ESP GUID. Being loose here just means
firmware will always have to deal with a wide variety of schemes for ESP
partitions.
This goes hand in hand with my opinion that on shared media there should
be separate partitions for firmware and the ESP. Firmware can use
whatever GUID it likes, and that partition should be marked as
protected. (I'd strongly recommend firmware partitions use a filesystem,
but that's out of scope for EBBR)
Conversely, EBBR should be really strict about what constitutes an ESP.
We can do that if we don't try to conflate the vendor-defined firmware
partition and the generic ESP partition.
I could be convinced to soften my position on firmware files being
stored in the ESP, provided we define a directory structure for storing
vendor firmware files to prevent collisions, and in all other respects
the partition is a normal ESP.
g.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
