[Bug 196388] New: Gpart code violates EFI specification

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196388

            Bug ID: 196388
           Summary: Gpart code violates EFI specification
           Product: Base System
           Version: 10.1-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: petrek729 at gmail.com

Hi,

Lately I was bitten by this bug:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=115406
Due to too much time I read said specification (the old link doesn't work,
here's the current one
http://www.intel.com/content/dam/www/public/us/en/zip/efi-110.zip to save your
time).

To save even more time the most relevant quotes from it are placed here with my
(hopefully valuable) comment.

In Table 11-6 we find information, that Start Head, Sector and Track and End
Head, Sector and Track are not used by EFI firmware, in the contrary to the
"Starting LBA" and "Size in LBA".

1. Below the table we read: "Each MBR partition record must be checked to make
sure that the partition that it defines physically resides on the disk" and
little later: "If any of these checks fail, the MBR is not considered valid".
When the address of the End Head of said partition is set to 0xff (as is in the
current code), indicating the 0x100 Head (since Heads are counted from 0), the
above condition is not met, since physically (most) CHS disks end at most at
0xff Head and such partition exceeds this value, so due to this such MBR can't
be even considered valid.

2. "The Protective MBR has the same format as a legacy MBR" means the point
number 1 applies to it also.

3. In the table 11-7 in the End Head, Sector and Track records we can read:
"Set to match the Ending LBA of the EFI Partition structure. Must be set to
0xFFFFFF if it is not possible to represent the starting LBA". As was mentioned
in the bug report, it is possible to represent the starting LBA, and the
current gpart code does that for Start CHS address (which by the way has
exactly the same description as the End CHS address, so either both should be
set to 0xFFFFFF or none), so the condition for setting End CHS address as
0xFFFFFF is not even met here.

5. "(PMBR) reserves the entire space used on the disk by the GPT partitions,
including all headers. [...] If the GPT partition is larger than a partition
that can be represented by a legacy MBR, values of all Fs must be used". Legacy
MBR can represent up to 2 TiB of space, so we should set "Size in LBA" to all
Fs if the GPT partition exceeds this value, not any of the possible CHS values,
these are irrelevant here. Indeed, as a confirmation of this in Table 11-7 we
read in "Size in LBA" record: "Length of EFI Partition Head, 0xFFFFFFFF if this
value overflows."

So the EFI specification doesn't require setting address of the End Head as
0xff, and even forbids it if this will overflow the CHS capacity of the disk,
so the current PMBR for all those reasons due to some previous
misunderstandings in reality is invalid and violates EFI specification.

-- 
You are receiving this mail because:
You are the assignee for the bug.