GUID PARTITIONS
The method of creating partitions is not the only thing showing its age. The Basic Input Output System (BIOS) boot process is also quite outdated. Under the BIOS boot process an ultramodern 64-bit computer is not started in 64-bit mode. It isn’t even started in 32-bit mode. The CPU is forced to regress all the way back to 16-bit compatibility mode. In fact, if you examine the boot code in the MBR you will discover that it is 16-bit machine code.
The BIOS boot process has been replaced with the Unified Extensible Firmware Interface (UEFI) boot process. UEFI (pronounced ooh-fee) booting allows a computer to start in 64-bit mode directly. All 64-bit computers shipped today use UEFI and not BIOS for booting, although they support legacy booting from MBR-based drives. This legacy support is primarily intended to allow booting from removable media such as DVDs and USB drives.
A new method of specifying partitions was also created to go along with UEFI. This new method assigns a Globally Unique Identifier (GUID) to each partition. The GUIDs are stored in a GUID Partition Table (GPT). The GPT has space for 128 partitions. In addition to the primary GPT, there is a secondary GPT stored at the end of the disk (highest numbered logical block) to mitigate the chances of bad sectors in the GPT rendering a disk unreadable.
A drive using GUID partitioning begins with a protective MBR. This MBR has a single entry covering the entire disk with a partition type of 0xEE. Legacy systems that don’t know how to process a GPT also don’t know what to do with a partition of type 0xEE so they will ignore the entire drive. This is preferable to having the drive accidentally formatted if it appears empty or unformatted.
As has been mentioned previously, modern systems use Logical Block Addressing
(LBA). The protective MBR is stored in LBA0. The primary GPT begins with a header in LBA1, followed by GPT entries in LBA2 through LBA34. Each GPT entry requires 128 bytes. As a result, there are four entries per standard 512 byte block. While GPT entries are 128 bytes today, the specification allows for larger entries (with size specified in the GPT header) to be used in the future. Blocks are probably 512 bytes long, but this should not be assumed. The secondary GPT header is stored in the last LBA and the secondary GPT entries are stored in the preceding 32 sectors. The layout of a GPT-based drive is shown in Figure 5.3.
FIGURE 5.3
Layout of a drive with GUID partitioning.
The GPT header format is shown in Table 5.3. When attempting to mount images of drives using GUID partitioning, this header should be checked in order to future proof any scripts should the default values shown in the table change.
Table 5.3. GUID Partition Table Header Format.
| Offset | Length | Contents |
|---|---|---|
| 0 (0x00) | 8 bytes | Signature (“EFI PART” or 0x5452415020494645) |
| 8 (0x08) | 4 bytes | Revision in Binary Coded Decimal format (version 1.0 = 0x00 0x00 0x01 0x00) |
| 12 (0x0C) | 4 bytes | Header size in bytes (92 bytes at present) |
| 16 (0x10) | 4 bytes | Header CRC32 checksum |
| 20 (0x14) | 4 bytes | Reserved; must be zero |
| 24 (0x18) | 8 bytes | Current LBA (where this header is located) |
| 32 (0x20) | 8 bytes | Backup LBA (where the other header is located) |
| 40 (0x28) | 8 bytes | First usable LBA for partitions |
| 48 (0x30) | 8 bytes | Last usable LBA for partitions |
| 56 (0x38) | 16 bytes | Disk GUID |
| 72 (0x48) | 8 bytes | Starting LBA of array of partition entries |
| 80 (0x50) | 4 bytes | Number of partition entries in array |
| 84 (0x54) | 4 bytes | Size of a single partition entry (usually 128) |
| 88 (0x58) | 4 bytes | CRC32 checksum of the partition array |
| 92 (0x5C) | — | Reserved; must be zeroes for the rest of the block |
The format for each partition entry is shown in Table 5.4. The format for the attributes field in these entries is shown in Table 5.5. Unlike MBR-based partitions with one byte to indicate partition type, GPT-based partitions have a 16-byte GUID for specifying the partition type. This type GUID is followed by a partition GUID (essentially a serial number) which is also sixteen bytes long. You might see Linux documentation refer to this partition GUID as a Universally Unique Identifier (UUID).
Table 5.4. GUID Partition Table Entry Format.
| Offset | Length | Item |
|---|---|---|
| 0 (0x00 | 16 (0x10) | Partition type GUID |
| 16 (0x10) | 16 (0x10) | Unique partition GUID |
| 32 (0x20) | 8 (0x08) | First LBA |
| 40 (0x28) | 8 (0x08) | Last LBA |
| 48 (0x30) | 8 (0x08) | Attributes |
| 56 (0x38) | 72 (0x48) | Partition name (UTF-16 encoding) |
Table 5.5. GUID Partition Table Entry Attributes Format.
| Bit | Content | Description |
|---|---|---|
| 0 | System partition | Must preserve partition as is |
| 1 | EFI Firmware | Operating system should ignore this partition |
| 2 | Legacy BIOS boot | Equivalent to 0x80 in MBR |
| 3-47 | Reserved | Should be zeros |
| 48-63 | Type specific | Varies by partition type (60=RO, 62=Hidden, 63=No automount for Windows) |
The start and end LBA follow the UUID. Next comes the attributes and then the partition name which can be up to 36 Unicode characters long. Attribute fields are 64 bits long. As can be seen in Table 5.5, the lowest three bits are used to indicate a system partition, firmware partition, and support for legacy boot. System partitions are not to be changed and firmware partitions are to be completely ignored by operating systems. The meaning of the upper sixteen bits of the attribute field depends on the partition type.