[parted-devel] Revised GPT defects/fixes with parted 1.7.0

Wed Aug 30 08:24:21 UTC 2006

Hello Leslie et al

I have revised and added some fixes to parted/libparted previously
submitted by David Cantrell on my behalf (patched against v1.7.0
attached).

Please could you review/consider them for inclusion in to the next
update of parted?  I have added brief changelog details in each patch
and hopefully kept within your coding guidelines, but feel free to
berate as necessary! :-)   I have broken the 80 char guideline in one
place where the code was already >80 chars, I did not correct this since
the changed line only contained a single character modification.

Below is a change summary and below that you will find more verbose
details of the modifications/additions:

1. fix for an assertion error in v1.7.0 of parted, this was
   also observed in v1.6.19 as a seg-fault. Both myself and Redhat
   simultaneously provided exactly the same fix.

2. addition of device/LUN resize detection and optional GPT header 
   update. 

3. fix for an 'off-by-one' defect in the backup GPT header

Details for Change#2 above
--------------------------

When I made the initial changes to _parse_header() I had not considered
how it might affect other callers, especially non-interactive programs
such as partprobe.  The revised changes now generate a warning, provide
more details of the issue and perform no other action.  To give an
example, my ia64 test system has access to a number of gpt disk devices,
not all of which have been created via parted, two of these in
particular have defects in their GPT header (sigh) which gets noticed by
my gpt changes when the volumes are scanned.  Nothing bad comes of this
but in the patch I originally submitted the user would have no clue as
to the volumes in question, consequently I made a few changes to the
patch to better cope with this, the main feature being that the
exception message now indicates the volume in question and the
space/size being talked about, eg:

royce:~/parted-1.7.0 # ./partprobe/.libs/partprobe  -s -d
Warning: Not all of the space available to /dev/sda appears to be used,
you can fix the GPT to use all of the space (an extra 2 blocks) or
continue with the current setting? 
/dev/sda: gpt partitions 1 2 4 5 3
/dev/sdb: msdos partitions 1 2 3 4
Warning: Not all of the space available to /dev/sdc appears to be used,
you can fix the GPT to use all of the space (an extra 2 blocks) or
continue with the current setting? 
/dev/sdc: gpt partitions 1 2 4 5 3
/dev/sdd: gpt partitions 1
/dev/sde: gpt partitions
royce:~/parted-1.7.0 # 

Notice the disk device and the 'extra N blocks' text. The warning still
comes out as a question but clearly this is not going to be addressable
in partprobe, you need to perform the update in parted.  If you see a
better way of handling this please let me know.

Details for Change#3 above
--------------------------

I compared the headers created by parted and diskpart.efi (MS/Intel
utility I believe).  The diskpart.efi util creates a GPT header which
matches my understanding/interpretation of the EFI spec v1.02, parted
currently does not!  The issue is with the backup GPT header and regions
with overlapping LBAs (the spec says a no-no) and although I could not
demonstrate corruption of the partition table I still think that it
could at some stage occur, if not via Linux then perhaps some other OS.
The problem is as follows:

Backup GPT:

Signature EFI PART
Revision  0x00010000
HeaderSize 92
HeaderCRC32 374384132
MyLBA  25165823
Alt-LBA 1
FirstUsableLBA 34
LastUsableLBA  25165790            <-------- note #1
DiskGUID
PartitionEntryLBA  25165790        <-------- note #2
NumberOfPartitionEntries  128
SizeOfPartitionEntry  128
PartitionEntryArrayCRC32  4283204935

Partition entry = 0
StartingLBA = 25165000
EndingLBA = 25165790               <-------- note #3

Partition entry = 1
StartingLBA = 34
EndingLBA = 1000

Partition entry = 2
StartingLBA = 0
EndingLBA = 0

LastUsableLBA (note#1) overlaps with the backup PartitionEntryLBA
(note#2), this is bad since LastUsableLBA is an inclusive block it could
contain user data.  As I mentioned above, in practice I could not cause
a corruption of this block, it seems that Linux would not write to this
last block (perhaps a safety feature or some other off-by-one defect,
I've not pursued it).   I found three places in the code where this
partition area is referenced, two of them I believe are wrong, one
appears correct.  Re-writing and thus correcting the data does not
appear to have any undesirable effects since the 1 block shift (advance)
puts data in an unused location, so my fixes will automatically address
this problem any time the GPT/partition data is re-written.

In summary, I have provided limited testing in an IA64 environment and
thus far not noticed any undesirable side-effects to my modifications,
however I welcome further code scrutiny and feedback.

Regards
-- 
Darren Lavender <dl1 at hppine99.gbr.hp.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libparted-gpt.patch
Type: text/x-patch
Size: 4449 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20060830/60efdc6a/libparted-gpt.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parted-ui.patch
Type: text/x-patch
Size: 985 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20060830/60efdc6a/parted-ui.bin