Re: Minimum size of GPT partition table header

[Rod Smith]

On 09/22/2012 12:00 PM, address@hidden wrote:

> > > There seems to be a bug in function _header_is_valid() in file
> > > gpt.c.
...
> > > The check gpt->HeaderSize<  pth_get_size_static seems to be
> > > incorrect. I think minimum size of gpt header is 92 bytes. So,
> > > correct check should be gtp->HeaderSize<  92.
...
> > Has this code caused an actual problem for you?
...
> One more question here. Should we allow read of gpt table in case the
> header size>  92 ? This is because if the header size has been
> increased, the header revision should also be increased.

I'm not sure that's correct. In the EFI spec (version 2.3.1), p. 102, 
Table 16's description of the HeaderSize item is:

: Size in bytes of the GPT Header. The HeaderSize must be
: greater than 92 and must be less than or equal to the
: logical block size.

First, this description is clearly not quite correct -- or at least, it 
doesn't reflect what most software does, in the sense that most programs 
set HeaderSize to 92, which is NOT "greater than 92."

Leaving that aside (assuming the authors mean "greater than or equal to 
92"), I don't read this as meaning that the HeaderSize must be 92 for 
the current version of the GPT table; it clearly states that the value 
must be BETWEEEN 92 and the logical block size. You could set HeaderSize 
to 92, 93, 122, or whatever, and it would be legal. There may be 
something else in the spec that contradicts this reading, though, and 
I've just missed it. There could also be some subtle difference between 
the 2.3.1 spec and an earlier spec.

> I am seeing this problem for gpt partitions created by Solaris "zpool
> create" command. It creates a gpt hdr with size 512 bytes (but
> doesn't change the revision which is incorect).

Perhaps the zpool authors read the spec and took the "greater than 92" 
literally. In any event, I don't believe that zpool's behavior on this 
score is incorrect.

> Apart from this it
> has only 9 partition table entries (which doesn't comply with the EFI
> spec). Moreover, it doesn't place the backup gpt at the end of disk.

IIRC, zpool does create short partition tables, as you say, and this 
does violate the spec. OTOH, aside from violating the part of the spec 
that says the table must be a minimum size, a short partition table does 
work, in the sense that it doesn't necessarily cause data structures to 
overwrite each other. Thus, I don't see the harm in reading and working 
with such tables, *IF* the code can do so in a sane way -- either by 
preserving the short table or by enlarging the table to the correct 
minimum size without overwriting partitions.

I don't recall zpool mislocating the backup data structures, but perhaps 
I'm not remembering correctly.

> Using libparted, I can read this table. But, if I modify such a table
> the original gpt hdr contents are lost.
>
> I feel that we should fail both read/write of a table whose hdr size>
> 92. What's your opinion ?

IMHO, one of parted's weaknesses is that it has poor handling of error 
conditions. All too often, it bails out, and the result is that tools 
like GParted often display empty partition tables. This makes recovering 
from error conditions -- even very trivial errors -- unnecessarily 
difficult for users. Throwing more disks into this error condition is 
undesirable, IMHO, especially for the case of a HeaderSize value >92, 
which as I say, I believe to be legal.

--
Rod Smith
address@hidden
http://www.rodsbooks.com