Re: bug-parted Digest, Vol 118, Issue 10

[Rod Smith]

On 09/23/2012 12:00 PM, address@hidden wrote:
> > ...
> > >
> > >  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.

I disagree. IMHO, the statement in the HeaderSize description about that 
field's legal values (adjusted for common sense in this case) should 
take precedence over any inferences you might draw based on a 
description of another field.

That said, I agree that there's a potential for harm should somebody 
write software that stores data past byte 92 in the GPT header's sector. 
Such software would clearly violate the spec, though. Note that, the 
last I checked, libparted trashes hybrid MBRs, which are 
standards-violating but that *DO* exist in the wild. This is analogous 
to zeroing out the post-92 bytes in the GPT header sector. Thus, I don't 
see much point in going out of the way, and creating problems with known 
software (zpool) in the process, to avoid what are currently purely 
hypothetical problems. My opinion might change if and when software that 
stores data past byte 92 actually appears in the wild.

This would of course be much simpler if the spec just said that 
HeaderSize should equal 92.

> I also believe that in future if the headerSize is increased, its
> Revision number should also be changed.

I agree, but that's something that I (and I'm guessing you) have no 
control over.

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

Assuming the Revision value checks out, IMHO that's fine. The spec 
clearly states that values past 92 must be 0. Thus, if something else is 
there, no matter what the HeaderSize value states, it doesn't conform to 
the spec, and zeroing it out qualifies as a repair. That said, including 
code to check for this condition and giving the user the option of 
aborting or preserving this non-compliant data would be reasonable, too.

I've never heard of any tool that stores data in the post-92 reserved 
field of the GPT header. Thus, all this is very hypothetical at the 
moment. Since zpool *DOES* create disks with HeaderSize values of 512, 
though, something reasonable MUST be done with them.

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