libburnia/libisofs
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Documented probable isohybrid.c bugs and polished overview table.

Browse Source
This commit is contained in:
Thomas Schmitt 2012-05-09 12:03:50 +02:00
parent 502bea814e
commit 262e49ad6b
1 changed files with 59 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

99
doc/boot_sectors.txt
View File

@ -411,17 +411,19 @@ Sources:
>>> Motivation: What systems will use the additional data ? amd64 UEFI ?
This is a very condensed format which exposes as many entry points for boot
firmware as possible.
This is a very condensed format which exposes a lot of entry points for boot
firmware.
Byte Range | Value | Meaning (all numbers are stored big endian)
Byte Range | Value | Meaning
-------------- | ---------- | -------------------------------------------------
0 - 511 | mbr | Isohybrid MBR pointing to x86 boot image file,
| | with three entries in its partition map.
| | It shares its first 32 bytes with apm_head.
0 - 31 | apm_head | Mock-up of the start of the first block of
| | an Apple Partition Map (APM).
446 - 461 | mbr_entry1 | Partition table entry 1 describing ISO image size
446 - 461 | mbr_entry1 | Partition table entry 1 describing the size of
| | the ISO image plus the backup GPT, padded up to
| | the next full MiB.
462 - 477 | mbr_entry2 | Entry 2 describing the UEFI VFAT boot image.
478 - 493 | mbr_entry3 | Entry 3 describing the HFS+ boot image.
| |
@ -443,6 +445,13 @@ firmware as possible.
-------------- | ---------- | -------------------------------------------------
For the purpose of booting, there may be two EFI boot image files in the
ISO image. A VFAT image and a HFS+ image. The content of both is not in the
scope of this document.
These boot images get announced by EL Torito boot catalog entries with
Platform Id 0xef.
Newer SYSLINUX MBR templates begin by 32 bytes of machine code which are
intentionally non-essential:
33 ed 90 90 90 90 90 90 90 90 90 90 90 90 90 90
@ -453,8 +462,8 @@ The following 32 bytes from block 0 of an Apple Partiton Map (APM) are such
harmless code. They stem from Fedora-LiveCD.iso by Matthew Garret:
45 52 08 00 00 00 90 90 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
It is a constant that does not depend on any properties of the ISO image or
the information that is described in the following text.
They do not depend on any properties of the ISO image or the information
that is described in the following text.
The layout of a Block0 of an APM is:
@ -475,13 +484,6 @@ Byte Range | Value | Meaning (all numbers are stored big endian)
(The block_count of 0x9090 is pure fantasy. It shall only mark the disc as
not empty.)
For the purpose of booting, there may be two EFI boot image files in the
ISO image. A VFAT image and a HFS+ image. The content of both is not in the
scope of this document.
These boot images get announced by EL Torito boot catalog entries with
Platform Id 0xef.
The data block ranges of the two EFI boot images get described by MBR
partition entries 2 and 3, which thus claim blocks inside of partition 1.
This partition nesting is acceptable to some EFI implementations only if the
@ -531,8 +533,10 @@ Byte Range | Value | Meaning (little endian numbers, LBA unit is 512 byte)
20 - 23 | reserved | = 0
24 - 31 | curr_lba | Location of this header block = 0x1
32 - 39 | back_lba | Location of header backup block = 0x144ffe = 1331198
| This is 1 KiB before the end of MBR partition 1.
>>> ??? why 1 KiB and not 512 bytes ?
| | This is 1 KiB before the end of MBR partition 1
| | (but should be 512 bytes).
| | (Potential isohybrid.c bug #1:
| | Backup GPT is dislocated by 512 bytes.)
40 - 47 | first_lba | First usable LBA for partitions = 0x30 = 48
48 - 55 | last_lba | Last usable LBA for partitions = 0x144fde = 1331166
56 - 71 | guid | Disk GUID
@ -591,7 +595,7 @@ Byte Range | Value | Meaning (all numbers are stored big endian)
8 - 11 | start_block| "physical block start of partition" = 1
12 - 15 | block_count| "physical block count of partition" = 16
| | (The value of 16 claims the ISO 9660 PVD as part of
| | the partition table. This might be unhealthy.)
| | the partition table. It should be 4 instead.)
16 - 47 | name | Partition name = "Apple"
48 - 79 | type | Type string = "Apple_partition_map"
80 - 83 | lb_start | Logical block start = 0
@ -608,6 +612,10 @@ Byte Range | Value | Meaning (all numbers are stored big endian)
136 - 511 | reserved |
---------- | ---------- | ----------------------------------------------------
(Potential isohybrid.c bug #2:
Apple partition map entries bear the block count for blocks of 512 bytes
whereas Apple Block0 announces blocks of 2048 bytes.)
The next Apple partition map entry is at byte 0x1000 = 4096:
50 4d 00 00 00 00 00 03 00 00 00 29 00 00 04 70
@ -619,15 +627,17 @@ The next Apple partition map entry is at byte 0x1000 = 4096:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 04 70 00 00 00 33 00 00 00 00
3 partitions, start block is 0x29 = 41, block count is 0x0470 = 1136,
name is "EFI", type is "Apple_HFS"
>>> although this is a FAT image
, logical block start = 0, lb_count = 1136,
3 partitions, start block is 0x29 = 41,
block count is 0x0470 = 1136 (should be 284), name is "EFI",
type is "Apple_HFS" (although this is a FAT image),
logical block start = 0, lb_count = 1136 (should be 284),
flags = 0x33 : valid, allocated, readable, writable.
This points to file /isolinux/efiboot.img in the ISO image,
>>> but misrepresents its size of 284 blocks of 2048.
This points to file /isolinux/efiboot.img in the ISO image.
(Potential isohybrid.c bug #2:
Apple partition map entries bear the block count for blocks of 512 bytes
whereas Apple Block0 announces blocks of 2048 bytes.)
At byte 0x1800 = 6144, there is map entry 3:
At byte 0x1800 = 6144, there is Apple partition map entry 3:
50 4d 00 00 00 00 00 03 00 00 01 51 00 00 08 c0
45 46 49 00 00 00 00 00 00 00 00 00 00 00 00 00
@ -639,14 +649,13 @@ At byte 0x1800 = 6144, there is map entry 3:
00 00 00 00 00 00 08 c0 00 00 00 33 00 00 00 00
3 partitions, start block is 0x0151 = 337 (LBA of /isolinux/macboot.img),
block count = 2240
>>> (4 times higher than ISO size of 560 blocks)
, name is "EFI", type is "Apple_HFS",
, logical block start = 0, lb_count = 2240,
block count = 0x08c0 = 2240 (should be 560), name is "EFI",
type is "Apple_HFS", logical block start = 0, lb_count = 2240 (should be 560),
flags = 0x33 : valid, allocated, readable, writable.
(Potential isohybrid.c bug #2:
Apple partition map entries bear the block count for blocks of 512 bytes
whereas Apple Block0 announces blocks of 2048 bytes.)
>>> GPT partitions marking ISO image, VFAT image within, HFS+ image within
At byte 0x2000 = 8192 begins the GPT partition array.
It ends at byte 0x4000 = 16384.
@ -666,7 +675,7 @@ A GPT partion entry looks like:
Byte Range | Value | Meaning (numbers are stored little endian)
---------- | ---------- | ----------------------------------------------------
0 - 15 | type_guid | Partition type guid = Basic data partition
0 - 15 | type_guid | Partition type GUID = Basic data partition
| | Wikipedia: "EBD0A0A2-B9E5-4433-87C0-68B6B72699C7"
| | (Note: The first three words are shown byte swapped)
16 - 31 | part_guid | Unique partition GUID
@ -675,14 +684,17 @@ Byte Range | Value | Meaning (numbers are stored little endian)
32 - 39 | start_lba | First LBA = 0
40 - 47 | end_lba | Last LBA (inclusive) = 0x144828 = 1329448
| | This is the ISO image size in blocks of 512.
>>> But it should be 1 block less than that
| | (Potential isohybrid.c bug #3:
| | The end_lba in the first GPT entry should be 1 less
| | than the count of 512 byte blocks of the ISO image.)
48 - 55 | flags | Attribute flags
| | bit0= "System Partition" Do not alter.
| | bit2= Legacy BIOS bootable (MBR partition type 0x80)
| | bit60= read-only
56 - 127 | name | >>> Wikipedia says UTF-16LE.
| | >>> The name in Fedora-LiveCD.iso is 8 bit and result
| | >>> of faulty memory operation on a text constant.
56 - 127 | name | Wikipedia says UTF-16LE.
| | (Potential isohybrid.c bug #4:
| | The name in Fedora-LiveCD.iso is 8 bit and result
| | of faulty memory operation on a text constant.)
---------- | ---------- | ----------------------------------------------------
Next entry is at 0x2800 = 10240:
@ -701,7 +713,8 @@ Next entry is at 0x2800 = 10240:
Partition type GUID : "EBD0A0A2-B9E5-4433-87C0-68B6B72699C7" = Basic data
Start at block 0xa4 = 164 * 512 = 41 * 2048. The VFAT image file.
Last block is 0x0513 = 1299 = 164 + 1135. This end is correct.
>>> The name is an unintentional patchwork in an 8 bit character set.
(Potential isohybrid.c bug #4:
Wrong character set and incidential bytes in GPT partition name.)
Next entry at byte 0x02100 = 8448:
@ -719,7 +732,8 @@ Next entry at byte 0x02100 = 8448:
Partition type GUID : "48465300-0000-11AA-AA11-00306543ECAC" = HFS+
Start block is 0x0544 = 1348 * 512 = 337 * 2048. The HFS+ image file.
Last block is 0x0e03 = 3587 = 1348 + 2239. Correct.
>>> Frankenstein's name, again.
(Potential isohybrid.c bug #4:
Wrong character set and incidential bytes in GPT partition name.)
The rest of the System Area is 0 up to the Primary Volume Descriptor
at block 16.
@ -731,12 +745,16 @@ at least 16.5 KiB, which effectively occupy 18 KiB.
The backup partition array is stored 17 KiB before the end of MBR partition 1
resp. the image file.
>>> why not 16.5 KiB before end ? Wikipedia suggests "LBA -33" counted from end.
(Potential isohybrid.c bug #1:
Wikipedia suggests "LBA -33" counted from end. This would be 16.5 KiB before
end.)
The content of the partition arry is the same as the one of the primary array
at byte 0x4000.
The GPT header is stored 1 KiB before the end of MBR partition 1.
>>> why not 512 byte before end ? Wikipedia suggests "LBA -1" counted from end.
(Potential isohybrid.c bug #1:
Wikipedia suggests "LBA -1" counted from end. This ould be 512 bytes.)
45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00
E F I P A R T
@ -749,8 +767,9 @@ The GPT header is stored 1 KiB before the end of MBR partition 1.
It differs by its own CRC and by some of its parameters:
Own address is 0x144ffe. The backup lba is 0x01 = Primary GPT header.
Partition entries start is 0x144fde
>>> This overlaps with the last usable LBA. The backup GPT must move up by
>>> 512 bytes.
(Potential isohybrid.c bug #1:
This overlaps with the last usable LBA. The backup GPT must move up by
512 bytes.)
------------------------------------------------------------------------------