14

According to this Wikipedia article, the second Logical Block Address of a GUID Partition Table (LBA 1) is the primary GPT header. It then states in the section about the header that the first 8 bytes of the header is for a 'Signature'.

What is this GPT header signature and what is its relevance to the function/operation of the GPT table/storage device?

I have searched around on the web, but found very little information on what this header signature is for.

Edit:

I asked these follow-on questions in the comments to Deltik's answer, which they very helpfully expanded to address:

  • If the signature was blank, then would the GPT table not be recognized?
  • I am currently inspecting a Chrome OS GPT, where the signature seems to have been set to 'IGNOREME'. What effect would that have?
  • Are there any other valid GPT signatures available? (apart from the default 'EFI PART')
Time4Tea
  • 389

1 Answers1

24

The signature EFI PART (0x45 0x46 0x49 0x20 0x50 0x41 0x52 0x54) simply says "This is a GUID Partition Table". It's how software know that the block device is formatted in the GPT layout.

You can see it from this snippet of a hexdump:

*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  ea b5 99 a4 00 00 00 00  01 00 00 00 00 00 00 00  |................|
00000220  af 12 9e 3b 00 00 00 00  22 00 00 00 00 00 00 00  |...;....".......|
00000230  8e 12 9e 3b 00 00 00 00  7f 8c d6 05 c8 e8 01 4a  |...;...........J|
00000240  b8 74 6b 37 30 7c bf 15  02 00 00 00 00 00 00 00  |.tk70|..........|
00000250  80 00 00 00 80 00 00 00  10 d3 0e 29 00 00 00 00  |...........)....|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

Signatures are not unique to GPT. Files also have signatures that software can use to identify what the files are. This is the mechanism of operation of the file command. (Examples of file)

Answers to Follow-Up Questions

So, if this signature was blank, then the GPT partition table would not be recognized?

At least, gdisk would no longer recognize it. Check out this demo:

  1. Create a file (acting as a block device) for the demo:

    root@demo [/tmp]# truncate -s 1M gpt-demo

  2. Format the file with GPT:

    root@demo [/tmp]# sgdisk --clear gpt-demo
Creating new GPT entries.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

  3. Check the binary data of the partition table:

    root@demo [/tmp]# hexdump -C gpt-demo
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  02 00 ee 20 20 00 01 00  00 00 ff 07 00 00 00 00  |...  ...........|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  13 14 6d 6a 00 00 00 00  01 00 00 00 00 00 00 00  |..mj............|
00000220  ff 07 00 00 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
00000230  de 07 00 00 00 00 00 00  be 2c cb 6e 58 d4 e3 46  |.........,.nX..F|
00000240  84 84 3c 83 52 59 5b 58  02 00 00 00 00 00 00 00  |..<.RY[X........|
00000250  80 00 00 00 80 00 00 00  86 d2 54 ab 00 00 00 00  |..........T.....|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000ffe00  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
000ffe10  18 3a 1f d9 00 00 00 00  ff 07 00 00 00 00 00 00  |.:..............|
000ffe20  01 00 00 00 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
000ffe30  de 07 00 00 00 00 00 00  be 2c cb 6e 58 d4 e3 46  |.........,.nX..F|
000ffe40  84 84 3c 83 52 59 5b 58  df 07 00 00 00 00 00 00  |..<.RY[X........|
000ffe50  80 00 00 00 80 00 00 00  86 d2 54 ab 00 00 00 00  |..........T.....|
000ffe60  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000

  4. Examine how gdisk reads the partition table:

    root@demo [/tmp]# gdisk gpt-demo
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): q

  5. Change the GPT signature:

    root@demo [/tmp]# sed -i 's/EFI PART/IGNOREME/g' gpt-demo

  6. Verify that the signature was nuked:

    root@demo [/tmp]# hexdump -C gpt-demo
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  02 00 ee 20 20 00 01 00  00 00 ff 07 00 00 00 00  |...  ...........|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  49 47 4e 4f 52 45 4d 45  00 00 01 00 5c 00 00 00  |IGNOREME....\...|
00000210  13 14 6d 6a 00 00 00 00  01 00 00 00 00 00 00 00  |..mj............|
00000220  ff 07 00 00 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
00000230  de 07 00 00 00 00 00 00  be 2c cb 6e 58 d4 e3 46  |.........,.nX..F|
00000240  84 84 3c 83 52 59 5b 58  02 00 00 00 00 00 00 00  |..<.RY[X........|
00000250  80 00 00 00 80 00 00 00  86 d2 54 ab 00 00 00 00  |..........T.....|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000ffe00  49 47 4e 4f 52 45 4d 45  00 00 01 00 5c 00 00 00  |IGNOREME....\...|
000ffe10  18 3a 1f d9 00 00 00 00  ff 07 00 00 00 00 00 00  |.:..............|
000ffe20  01 00 00 00 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
000ffe30  de 07 00 00 00 00 00 00  be 2c cb 6e 58 d4 e3 46  |.........,.nX..F|
000ffe40  84 84 3c 83 52 59 5b 58  df 07 00 00 00 00 00 00  |..<.RY[X........|
000ffe50  80 00 00 00 80 00 00 00  86 d2 54 ab 00 00 00 00  |..........T.....|
000ffe60  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000

  7. Notice that the GUID Partition Table (GPT) is no longer recognized by gdisk:

    root@demo [/tmp]# gdisk gpt-demo
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.

Command (? for help): q

I am currently inspecting a Chrome OS GPT, where the signature seems to have been set to 'IGNOREME'. Do you know what effect that would have?

As far as I can tell from the demo above, if the signature is different from EFI PART, GPT is not recognized.

The IGNOREME "signature" is a special signature created by Chromium. This is the documentation I found for IGNOREME:

cgptlib: Add support for IGNOREME GPT signature

This patch makes cgpt aware of a special "IGNOREME" GPT header signature
string that may appear in either the primary or the secondary GPT and
cause cgpt (and other cgptlib clients) to completely ignore that GPT. It
will continue to function correctly for all other purposes (using the
data from the non-ignored GPT), but never write any data back to the
ignored GPT.


BRANCH=None
BUG=chrome-os-partner:52595
TEST=unit tests


Change-Id: I7e53542385ae9d8d24dc25b75e91f4ff4917f66f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/340072
Reviewed-by: Nam Nguyen <namnguyen@google.com>

Did you check the secondary GPT at the end of the disk/block device?

Are there any other valid GPT signatures available?

No, there are no signatures other than EFI PART because that is the only signature in the UEFI Specification (see page 123). (Archive copy of UEFI Specification Version 2.7 (Errata A))

TooTea
  • 651
Deltik
  • 19,971