Master boot record

From Wikipedia, the free encyclopedia

Jump to: navigation, search
Structure of a Master Boot Record
Address Description Size
in
bytes
Hex Oct Dec
0000 0000 0 Code Area 440
(max. 446)
01B8 0670 440 Optional Disk signature 4
01BC 0674 444 Usually Nulls; 0x0000 2
01BE 0676 446 Table of primary partitions
(Four 16-byte entries, IBM Partition Table scheme)		 64
01FE 0776 510 55h MBR signature;
0xAA55[1]		 2
01FF 0777 511 AAh
MBR, total size: 446 + 64 + 2 = 512

A master boot record (MBR), or partition sector, is the 512-byte boot sector that is the first sector ("LBA Sector 0") of a partitioned data storage device such as a hard disk. (The boot sector of a non-partitioned device is a Volume Boot Record. These are usually different, although it is possible to create a record that acts as both; it is called a multi boot record.) The MBR may be used for one or more of the following:

  • Holding a disk's primary partition table.[2]
  • Bootstrapping operating systems, after the computer's BIOS passes execution to machine code instructions contained within the MBR.
  • Uniquely identifying individual disk media, with a 32-bit disk signature; even though it may never be used by the machine the disk is running on.[3][4][5][6]

Due to the broad popularity of IBM PC-compatible computers, this type of MBR is widely used, to the extent of being supported by and incorporated into other computer types including newer cross-platform standards for bootstrapping and partitioning.[citation needed]

Contents

[edit] MBRs and disk partitioning

Layout of one 16-byte partition record
Offset Field
length
(bytes)		 Description
0x00 1 status[7] (0x80 = bootable, 0x00 = non-bootable,
other = invalid[8])
0x01 3 CHS address of first block in partition.[9]
The format is described in the next 3 bytes.
0x01 1 head[10]
0x02 1 sector is in bits 5–0[11]; bits 9–8 of cylinder are in bits 7–6
0x03 1 bits 7–0 of cylinder[12]
0x04 1 partition type[13]
0x05 3 CHS address of last block in partition.[14]
The format is described in the next 3 bytes.
0x05 1 head
0x06 1 sector is in bits 5–0; bits 9–8 of cylinder are in bits 7–6
0x07 1 bits 7–0 of cylinder
0x08 4 LBA of first sector in the partition
0x0C 4 number of blocks in partition, in little-endian format

The MBR is not located in a partition, it is located at a Main Boot Record area in front of the first partition.

When a data storage device has been partitioned with the MBR Partition Table scheme (i.e., the conventional IBM PC partitioning scheme), the master boot record contains the primary partition entries in its partition table. The partition table entries for other, secondary partitions are stored in extended boot records (EBRs), BSD disklabels, and Logical Disk Manager metadata partitions that are described by those primary entries.[15]

By convention, there are exactly four primary partition table entries in the MBR Partition Table scheme, although some DOS operating systems did extend this to five (PTS-DOS)[16] or even eight (AST or NEC DOS)[17][18] entries. Both the partition length and partition start address are stored as 32-bit quantities. Because the block size is 512 bytes, this implies that neither the maximum size of a partition nor the maximum start address (both in bytes) can exceed 232 × 512 bytes, or 2 TiB. Alleviating this capacity limitation is one of the prime motivations for the development of the GUID Partition Table (GPT).

Where a data storage device has been partitioned with the GPT scheme, the Master Boot Record will still contain a partition table, but its only purpose is to indicate the existence of the GUID Table and to prevent utility programs that understand only the MBR Partition Table scheme from creating any partitions in what they would see as free space on the disk, thereby accidentally erasing the GUID table.

[edit] MBRs and system bootstrapping

On IA-32 IBM PC compatible machines using the MBR Partition Table scheme, the bootstrapping firmware contained within the ROM BIOS loads and executes the master boot record. Because the i386 family of processors boot up in real mode, the code in the MBR is real mode machine language instructions. This code normally passes control by chain loading the volume boot record (VBR) of the active (primary) partition, although some boot managers replace that conventional code with their own.

The conventional MBR code expects the MBR Partition Table scheme to have been used, and scans the list of (primary) partition entries in its embedded partition table to find the only one that is marked with the active flag. It then loads and runs the Volume Boot Record for that partition. (Thus the master boot record, like other boot sectors, is a target for boot-sector infecting computer viruses. See boot sector.)

The MBR replacement code in some boot managers can perform a variety of tasks, and what those tasks are varies from boot manager to boot manager. In some, for example, it loads the remainder of the boot manager code from the first track of the disk, which it assumes to be "free" space that is not allocated to any disk partition, and executes it. In others, it uses a table of embedded disk locations to locate the remainder of the boot manager code to load and to execute. (Both approaches have problems. The first relies on behavior that is not universal across all disk partitioning utilities. The second requires that the embedded list of disk locations be updated when changes are made that would relocate the remainder of the code.)

On machines that do not use IA-32 processors, and on machines that use Extensible Firmware Interface (EFI) firmware, this design is unsuitable, and the MBR is not used as part of the system bootstrap. On the latter, the firmware is instead capable of directly understanding the GPT partitioning scheme and the FAT filesystem format, and loads and runs programs held as files in the EFI System partition. The MBR will be involved only insofar as it might contain the partition table if the MBR Partition Table scheme has been used.

There is some MBR replacement code that emulates EFI firmware's bootstrap, which makes non-EFI machines capable of booting from disks using the GPT partitioning scheme. (A typical example is a Multi Boot Record, which can be used as MBR and as a Volume Boot Record in the bootstrap process, hence the name. It detects a GPT and loads the EFI compatible code from disk to complete this task.)

[edit] MBRs and disk identity

Information contained in the Partition Table of an external hard drive as it appears in the utility program, QTparted, running under Linux.

In addition to the bootstrap code and a partition table, master boot records may contain a Windows NT disk signature. This is a 32-bit value that is intended to uniquely identify the disk medium (as opposed to the disk unit — the two not necessarily being the same for removable hard disks).

The disk signature was introduced by Windows NT version 3.5, but is now used by several operating systems, including the Linux kernel version 2.6 and later. Linux uses the NT disk signature at boot time to determine the location of the boot volume.[19]

Windows NT (and later Microsoft operating systems) uses the disk signature as an index to all the partitions on any disk ever connected to the computer under that OS; these signatures are kept in Registry keys, primarily for storing the persistent mappings between disk partitions and drive letters. It may also be used in boot.ini files (though most do not), to describe the location of bootable Windows NT (or later) partitions.[20] One key (among many) where NT disk signatures appear in a Windows 2000/XP Registry is:

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

If a disk's signature stored in the MBR was A8 E1 B9 D2 (in that order) and its first partition corresponded with logical drive C: under Windows, then the REG_BINARY data under the key value, \DosDevices\C:, would be:

A8 E1 B9 D2 00 7E 00 00 00 00 00 00

The first four bytes are said disk signature. (Note: In other keys, these bytes may appear in reverse order from that found in the MBR sector.) These are followed by eight more bytes, forming a 64-bit Integer, in little endian notation, which are used to locate the byte offset of this partition. In this case, 00 7E corresponds to the hexadecimal value 0x7E00 (32,256dec). Dividing this byte offset by 512 (the size of a hard disk's physical sector in bytes) results in 63, which is the physical sector number (or LBA) containing the first block of the partition ([21]).

If this disk had another partition with the values 00 F8 93 71 02 following the disk signature (under, e.g., the key value \DosDevices\D:), it would begin at byte offset 0x27193f800 (10,495,457,280dec), which is also the first byte of physical sector 20,498,940.

[edit] Programming Considerations

Assume that the system being programmed uses the BIOS MBR scheme, as stated above, and the system BIOS locates a valid MBR on a partitioned drive in its boot sequence. As stated above, conventional MBR code loads and runs the operating-system-dependent Volume Boot Record (or bootloader) code that is located at the beginning of the disk's "active" partition. The MBR can simply assume that the one active partition on the current drive is supposed to boot, or alternately, it can be programmed as a Dual boot MBR. A dual boot MBR must interact with the user to determine which partition on which drive should boot, and may transfer control to the MBR of a different drive.

The BIOS will load the first valid MBR that it finds into hexadecimal physical address 0x7c00, and jump to that address. Part of the end of the 512 byte sector is pre-allocated for the partition table and other information (see above), so the MBR program must be tiny enough to fit within 440 bytes of memory. The MBR program may communicate with the user, examine the partition table, or perform some housekeeping tasks such as enabling the A20 line, or changing to Unreal mode from Real mode. Eventually, the MBR will need to perform its main task, and load the program that will perform the next stage of the boot process, usually by making use of the INT 13 BIOS call.

Typical boot sector code also expects to be loaded at physical address 0x7c00, even though all the memory from physical address 0x501 (address 0x500 is the last one used by the BIOS)[citation needed] to somewhere short of 0x9ffff is typically available in Real mode (a total of up to 640 KB minus the first 1281 bytes of memory)[22] Since 0x7c00 is the location where the MBR is already running, one of the first tasks of an MBR is usually to relocate itself somewhere else in memory -- most often at 0x600 (for Microsoft code). A conventional Volume Boot Record is only one sector long; but it does no harm and is trivial to allow the MBR to load significantly more than just one sector. Some bootloaders are longer than one sector, so loading more than one sector can speed up the boot process.

[edit] Editing/replacing MBR contents

Though it is possible to directly manipulate the bytes in the MBR sector using various Disk Editors, there are tools to write fixed sets of functioning code to the MBR . Since MS-DOS 5.0, the DOS-mode program FDISK has included the (undocumented, but widely used) switch /mbr, which will rewrite the MBR code. Under Windows 2000 or later, the Recovery Console can be used to write new MBR code to a hard disk using its fixmbr command. Under Windows Vista and Windows 7, the Recovery Environment can be used to write new MBR code to a hard disk clicking on Command Prompt and typing bootrec /FixMbr.

Some third-party utilities may also be used for directly editing the contents of partition tables (without requiring any knowledge of hexadecimal or disk/sector editors).[23]

In Linux, the GRUB and LILO projects have tools for writing code to the MBR sector, namely grub-install and lilo -mbr. The grub interactive console also has commands to write to the MBR.

[edit] References

  1. ^ On all IBM PC, PC compatible or any other little-endian computers, hexadecimal numbers of two or more bytes are always stored on media or in memory in reverse order (for more efficient CPU processing). Thus, the hex number 0xAA55 (or AA55h) will appear in a disk editor as the sequence: 55 AA.
  2. ^ In cases where the disk has a BIOS overlay or Boot manager installed, the partition table may be moved to some other physical location on the drive; e.g., a BIOS overlay often places a copy of the original MBR contents in the second sector ("Sector 1") then hides itself from any subsequently booted OS or application, so the MBR copy in Sector 1 is treated as if it were still residing in the first sector.
  3. ^ Peter C Norton and Scott Clark (2002). Peter Norton's New Inside the PC. Sams Publishing. pp. 360–361. ISBN 0672322897. 
  4. ^ Michael W. Graves (2004). A+ Guide To PC Hardware Maintenance and Repair. Thomson Delmar. pp. 276. ISBN 1401852300. 
  5. ^ Jean Andrews (2003). Upgrade and Repair with Jean Andrews. Thomson Course Technology. pp. 646. ISBN 1592001122. 
  6. ^ William Boswell (2003). Inside Windows Server 2003. Addison-Wesley Professional. pp. 13. ISBN 0735711585. 
  7. ^ The status fields in an non-extended partition table record are used by the embedded bootstrap code within the MBR to determine which partition is bootable (it is referred to as the active partition, and there can be only one active/bootable partition within the MBR). The status fields in an extended partition table record may also be used by boot manager programs to determine which partitions are bootable.
  8. ^ Formally, partition status values other than 0x00 and 0x80 are undefined and the bootstrap program may display an error message if this occurs. In practice, their meaning depends upon what the actual bootstrap code within the MBR has been written to accept. Some MBR bootstrap programs specifically look for the value 0x80 to indicate the bootable ("active") partition, others simply look for a non-zero value, and yet others look for any value with the top bit set.
  9. ^ Starting Sector fields are limited to 1024 cylinders, 255 heads, and 63 sectors. Sector indices have always begun with a 1, not a zero, and due to an early error in MS-DOS, the heads are generally limited to 255 instead of 256. When a CHS address is too large to fit into these fields, the tuple (1023, 254, 63) is used, which is 0xfeffff.
  10. ^ The range for head is 0 through 254 inclusive
  11. ^ The range for sector is 1 through 63
  12. ^ The 10-bit cylinder value is split into two bytes. The value can be reassembled using this formula: cylinder = (byte[2] & 0xc0) * 4 + byte[3]; range for cylinder is 0 through 1023
  13. ^ Andries Brouwer. "List of partition identifiers for PCs". Partition types. http://www.win.tue.nl/~aeb/partitions/partition_types-1.html. 
  14. ^ Ending Sector fields have the same limitations as the Starting Sector fields.
  15. ^ Roderick W. Smith (2000). The Multi-Boot Configuration Handbook. Que Publishing. pp. 260–261. ISBN 0789722836. 
  16. ^ Andries Brouwer. "Properties of partition tables". Partition types. http://www.win.tue.nl/~aeb/partitions/partition_types-2.html. . PTS-DOS uses "a special 5th partition entry in front of the other four entries in the MBR and corresponding AAP-aware MBR bootstrap code." (Brouwer).
  17. ^ Brouwer, ibid. Some OEM systems, such as AST DOS (type 14h) and NEC DOS (type 24h) had 8 instead of 4 partition entries in their MBR sectors.
  18. ^ Daniel B. Sedory. "Notes on the Differences in one OEM version of the DOS 3.30 MBR". Master Boot Records. http://mirror.href.com/thestarman/asm/mbr/DOS33MBR.htm.  Shows an 8-entry partition table and where its boot code differs from MS-DOS 3.30.
  19. ^ Matt Domsch. "Re: RFC 2.6.0 EDD enhancements". Linux Kernel Mailing List. http://lkml.org/lkml/2003/12/19/139. 
  20. ^ Microsoft. "Windows May Use Signature() Syntax in the Boot.ini File". KnowledgeBase. http://support.microsoft.com/kb/227704. 
  21. ^ Unlike the sector count used in the Sectors value of CHS tuples, which counts from one, the Absolute or LBA Sectors value starts counting from zero.
  22. ^ Very old machines may have less than 640 KB (A0000h or 655,360 bytes) of memory, and newer machines may allocate significant amounts of memory for BIOS uses. The INT 12 BIOS call may help in determining how much memory can safely be allocated (it simply reads the Base Memory size in KB from Segment:Offset location 0040h:0013h). In theory, only 64255 bytes is guaranteed (beginning at 0x501 and ending at 0x0ffff); in practice it is safe to assume at least 382.74 KB (ending at 0x5ffff) are available on modern hardware.
  23. ^ For example, Power Quest's Partition Table Editor (PTEDIT32.EXE), which runs under Windows operating systems, is still available here: Symantec's FTP site.

[edit] Further reading

[edit] See also

[edit] External links

Retrieved from "http://en.wikipedia.org/wiki/Master_boot_record"
Personal tools