[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Minimum size of GPT partition table header

From: Rod Smith
Subject: Re: Minimum size of GPT partition table header
Date: Sat, 22 Sep 2012 14:05:01 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120813 Thunderbird/10.0.6

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

There seems to be a bug in function _header_is_valid() in file
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]