Re: Minimum size of GPT partition table header

[rahul dev]

> 
> >>> 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."

I believe this description is not correct. It should be greater than or equal 
to 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 don't agree with this. The description for the "Reserved" field clearly says 
that "The rest of the block is reserved by UEFI and must be zero". 
The size of "Reserved" field mentioned is "BlockSize - 92". So, for current 
version the HeaderSize should not be > 92 (even if it is > 92, the fields 
beyond 92 should all be zero.

Only safe assumption is that the header size can be increased in future and it 
cannot be > blockSize.

I also believe that in future if the headerSize is increased, its Revision 
number should also be changed.
  
> 
> > 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.
> 
zpool behavior contradicts the description of "Reserved" Field.

> > 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 agree there's no harm in reading such a table.

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

Please see this 
http://lists.gnu.org/archive/html/bug-parted/2012-01/msg00037.html

I have myself observed this, where zpool does not create backup table at the 
end.

> 
> > 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.

I agree there's no harm in reading tables that have HeaderSize > 92. But, what 
about modifying them ? While modifying we change the headerSize to 92 and all 
contents beyond 92 are lost.

Thanks,
rahul