On 05/04/2018 06:20 PM, William Mills wrote:
[explicitly cc'ing boot-arch to see if this solves the TI auth problems]
On 05/04/2018 11:45 AM, Alexander Graf wrote:
On 05/04/2018 04:56 PM, Grant Likely wrote:
On 04/05/2018 15:46, Grant Likely wrote:
On 03/05/2018 09:43, Daniel Thompson wrote:
On Wed, May 02, 2018 at 06:09:15PM -0400, Tom Rini wrote:
On Wed, May 02, 2018 at 10:48:11PM +0100, Grant Likely wrote: > On 02/05/2018 22:24, Tom Rini wrote: >> On Wed, May 02, 2018 at 08:40:42PM +0100, Daniel Thompson wrote: >>> In terms of the restrictions that come from EBBR mandating GPT: >> Can we step back, why is EBBR mandating GPT? > I think EBBR should recommend GPT, but allow MBR if the SoC boot > masked > rom conflicts with GPT. > > In the early days of GPT there was also a hybrid GPT+MBR scheme that > could list the boot partition in the MBR, but still have a full > GPT. It > isn't pretty, but there is precidence. How about recommends GPT but allows MBR, no qualifiers. As you note there's a lot of ways to fiddle around and make it work, probably, on all of the existing SoCs that do magic offsets. But it's a lot easier to just allow MBR (what the SoCs were designed to have to live with) and guide line that in this case nothing before the first 2MiB be used by the OS. With a few more spec words around all of that so it's nice and formal :)
I'm OK to allow MBR.
I'd be inclined to require that protective partitions be used to defend the first 2MB though. They are more flexible and are a useful hint to anyone trying to manually partition.
In a different mail Tom wrote:
And I agree with the high level idea of needing to do something to protect systems with a magic in-use spot.
There are a couple of extra details.
- We can't allocate a GUID to discourage an automatic partitioner
from harming a protected partition. We only have the 8-bit partition type. Some potential candidates could be 0xA2 (which Altera appear use for a similar purpose), 0xE7 (wikipedia does not report existing uses) or 0xF0 (PA-RISC Linux boot loader).
- Boot ROMs that have built-in support for FAT could be hard coded to
require a specific partition type. > I think we don't need to worry about #2 to much: systems with built-in MBR/FAT parsing can use hybrid MBR/GPT to communicate to distros which partitions are protected because (presumably) they allow flexibility in placing the first sector of the FAT partition.
Can we start a list of SoCs that have special requirements on the boot eMMC/SD/USB? It would be useful to see the cross-section of requirements.
I've created a wiki page to start capturing data. From their we can decide what scenarios the spec needs to cover.
https://github.com/glikely/ebbr-for-discussion/wiki/Boot-Media-Behaviour
One more thought, are there many new SoCs still using hard coded offsets instead of an MBR or GPT? It may be that there aren't enough left for us to care about for EBBR level 0. In which case EBBR Level 0 should support both MBR and GPT (non-hybrid), and then narrow to GPT only in a future revision.
I don't think we'll be able to move away from MBR anytime soon. For a quick glimpse on what SoCs need to have blobs installed where, take a look at our image creation script:
https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM:Live/JeOS/...
There you can see that we force to MBR (for various reasons) on:
* RPi (reads MBR) * i.MX 5x/6 (SPL at sector 2) * Exynos 4/5 (SPL is in sector 1, not sure about newer ones) * AM905 (SPL in sector 1) * Kirkwood (SPL in sector 1) * Zynq(MP) (convenient to store boot.bin on FAT partition in MBR)
I think we should simply dictate that EBBR compliant OSs do not start any partitions before a sane boundary (1MB? 2MB?). IIRC most partitioning tools these days won't start partitions before 1MB anyway, so if we declare 1MB a safe bound we essentially have no work to do.
I did skim (not study) the script. Looks like a good resource of current board info. I see you are using raw mode for many boards.
Yes, we usually prefer raw mode over anything else, as it's then more consistent across the different platforms. Special "firmware partitions" just become maintenance headaches because then suddenly our partitioner needs adoption and awareness.
I am missing something. If there is only MBR and no GPT then there is no GUID type for EFI Partition. So how does the firmware find the "EFI Partition" and the default /efi/boot/boot*.efi file? Does it just use the partition with boot flag?
There is a special partition ID for the ESP (0xEF), but U-Boot currently just searches on every partition that's marked bootable.
Alex