MBR (x86): Difference between revisions

A Master Boot Record (MBR) is the bootsector of a hard disk. That is, it is what the BIOS loads and runs, when it boots a hard disk. The MBR is the very first sector of the hard disk; it contains an MBR Bootstrap program (described below), and a Partition Table. Devices that emulate a hard disk during system initialization must also contain an MBR, because they must also have Partition Tables -- even if they are not bootable.

The BIOS will only boot an MBR from a device if that device is in the "boot sequence" stored in CMOS, and if the MBR on the device is formatted correctly. On the other hand, if a device is not in the boot sequence (but has a "drive number"), it is still possible for a Real Mode program (such as another MBR or bootloader) to load and boot that device's MBR directly.

MBR Bootstrap

An MBR is loaded by the BIOS at physical address 0x7c00, with DL set to the "drive number" that the MBR was loaded from. The BIOS then jumps to the very beginning of the loaded MBR (0x7c00), because that part of the MBR contains the "bootstrap" executable code.

Typical MBR bootstrap code will do the following:

• relocate itself away from the 0x7c00 physical address (using a memory copy, and usually a far jump)
• determine which partition (or hard disk) to boot from (either by looking for the active partition, or by presenting the user with a selection of installed operating systems to choose from)
  • if the user selected an "inactive" partition, then set the selected partition entry to "active", and clear the "active" bits of other partition entries
  • use BIOS INT 13h commands to rewrite the MBR if the partition table entries were modified
• use BIOS INT 13h commands to load the Volume Boot Record (VBR, the "bootsector" of the bootloader) from the beginning of the selected partition to physical address 0x7c00
• set DS:SI pointing to the selected partition table entry
• jump to 0x7c00 (with CS set to 0, and DL set to the "drive number")

Note: it is intended for the value of DL, and the DS:SI pointer to be passed all the way into the kernel, for the kernel's use. This also means that the relocated MBR should not be overwritten during the boot process -- because the DS:SI pointer is aimed at a partition table entry inside that MBR, and needs to remain valid.

MBR Format

Notes:

• See the Partition Table article for the format of each partition table entry field.
• It is important to remember that the partition table entries are not aligned on 32-bit boundaries.
• Naming the partition table entries as "First" through "Fourth" is for convenience only. The partition table entries are not required to be in any kind of order.
• Any one of the partitions may be "active".
• There is supposed to be one active partition table entry, at most.
• Windows seems to verify and require that the partition it boots from be marked "active".
• Most other operating systems don't seem to care about the "active" bit in the partition table entry.

¹ This can be extended to 446 bytes if you omit the next 2 optional fields: Disk ID and reserved.

² The 4 byte "Unique Disk ID" is used by recent Linux and Windows systems to identify the drive. "Unique" in this case means that the IDs of all the drives attached to a particular system are distinct.

³ The 2 byte reserved is usually 0x0000. 0x5A5A means read-only according to https://neosmart.net/wiki/mbr-boot-process/.

Partition table entry format

¹ Relative to the start of the partition entry.

Traditional MBR

The DOS FDISK program was the first to ever use an MBR, so that MBR became the de-facto standard. It also automatically became the standard for the minimum level of functionality of an MBR. It was never changed after it was first introduced.

The whole point of the FDISK program is to manipulate the MBRs of the hard disks attached to a system. When FDISK partitions a blank disk, it writes an MBR to sector 0 of the drive. When FDISK adds a new partition to a disk, it adds an entry into the Partition Table in the MBR. When FDISK makes a partition "active", it sets the "flag" byte in the Partition Table entry to 0x80.

The MBR that FDISK uses is coded to:

• relocate itself to 0x0000:0x0600
• examine the byte at offset 0x1be, 0x1ce, 0x1de, and 0x1ee to determine the active partition
• load only the first sector of the active partition (which is expected to contain a DOS bootsector) to 0x0000:0x7c00 (hence the previous relocation)
• set SI
• jump to 0x7c00 -- transferring control to the DOS bootsector.

Dual Booting

A typical system may have several hard disks on it, and each hard disk can have 4 standard partitions (without going into the extra complication of Extended Partitions). Each of those partitions could theoretically hold its own distinct bootable OS, and filesystem.

However, the standard x86 boot sequence will only ever boot the MBR from the "C:" disk (the first disk found during the disk detection phase). And the standard MBR will only allow a single active partition on that disk, and will only ever boot that one partition. This is really completely inadequate.

It is not possible to modify the BIOS/CMOS boot sequence -- but you can change the MBR. So, one solution is to replace the standard MBR with a "custom, Dual Booting" MBR. (For a good example, see John Fine's SMBMBR in the External Links, below.)

A simple dual booting MBR will allow the user to select any partition on the current drive, to boot. A more complicated dual booting MBR will also allow the user to select other hard disks, or even to specifically choose other partitions on other hard disks, to boot.

For one MBR to load and run a different MBR off a different drive is called "chain loading". If all the MBRs are dual booting, then the user can cycle through all the disks, and choose to boot the "correct" partition from the "correct" drive.

A dual booting MBR is a huge improvement over the standard MBR. The only problem is that an MBR bootstrap is limited to a little over 400 bytes of code. Such a tiny program is insufficient to create a "nice" user-friendly dual booting system that has commercial appeal. It is enough space to hack up an interface that is good enough for the person who wrote it.

One way around this size limitation is to note that a bootloader can contain a lot more code than an MBR. So a custom MBR can try to load a "preferred" bootloader (if it can find one on some partition, somewhere) -- and that preferred bootloader can have a very pretty, user-friendly interface that allows the user to select any partition off any drive, to boot.

It is also nice, if there is only one partition on only one drive (ie. there is no choice for a user to make), if the MBR will boot that one partition automatically -- without bothering the user with prompts.

Generic MBRs

As said above, the MBR that is written to the disk by the DOS FDISK program is "the most generic" one. But every disk partitioning app must write some sort of MBR to the disk, and every generic bootloader may well need a custom MBR.

Fortunately, there was a standard for them to conform to (the FDISK MBR), and they all did conform to it. Some of them may be Dual Booting, or have other features -- but they will all end up loading your bootloader at the standard address (0x7c00), with the DL register set to the boot "drive number", and DS:SI pointing at the correct partition table entry of the correct MBR.

Building a Custom MBR Bootstrap program

When the BIOS transfers control to the MBR bootstrap code, the system is in Real mode. The MBR will probably also run entirely in Real mode, so it is important to understand Real mode addressing.

Self-relocation is one of the things C can't do, and most modern C compilers can't create code that is compatible with Real mode, anyway. So an MBR must be written in Assembly.

It is necessary to build an MBR that is exactly 512 bytes long. How this is done depends on your assembler and linker. The last 2 bytes must be the special boot pattern (0x55 followed by 0xAA), and as said above, the bootstrap portion of the MBR must be at most 446 bytes long. You must also put at least one partition table entry in the Partition Table portion of the MBR -- otherwise some BIOSes will refuse to boot from the disk. This includes most UEFI firmware in BIOS-compatibility mode.

Initial Environment

When the BIOS loads and runs an MBR, it is loaded into memory at physical address 0x7c00. This is usually 0x0000:0x7c00 (CS = 0, offset address 0x7c00). However, some BIOSes load to 0x7c0:0x0000 (CS = 0x07c0, offset address 0) -- which resolves to the same physical address, but can cause problems. A good practice is to enforce CS:IP with a far jump near the beginning of your bootstrap code. The MBR will probably need to immediately relocate itself anyway, and that is a good time to enforce CS:IP.

The BIOS passes very little useful information directly to the MBR. In fact, the only important number is the value in DL -- the "drive number". It needs to be passed to all later calls to BIOS function INT 13h, so that byte in DL probably needs to be saved carefully.

The values in all the other registers, and in most of memory, are undefined.

Immediate Priorities

It is important to immediately set up a stack, and also to set the rest of the CPU's segment registers (DS, ES, FS, GS) properly. Setting up a stack involves pointing the SS:SP pair of registers at some memory that is not being used for anything else (and the address must be even). The other segment registers should usually be set to 0.

See the Memory Map (x86) article to understand what memory is available during boot (low memory from 0x500 to 0x7ffff, generally).

In general, you do not want to fragment your available memory, or the memory of each 64K "page", if possible. The MBR needs a stack, and a place to relocate itself to. The MBR will be loading a bootloader at 0x7c00, so it is reasonably convenient for the MBR to relocate itself either to somewhere around the 0x500 to 0x600 address range, or to 0x7a00 (ie. just below 0x7c00). The stack can then point to 0x7c00 (if the MBR is not at 0x7a00), or the stack can be just below the relocated MBR.

Storing an MBR to the disk

To write an MBR to the first sector of a disk, you must use special disk I/O tools, because the MBR (by definition) is not inside any disk partition. The MBR only exists on the "raw device". There are quite a few "disk editing" tools available; some are listed in Disk Image Utilities.

x86 Examples

Assuming one knows how to read sectors from disk and has setup a function allowing them to do so, and assuming the inputs to said function are:

• EBX - 32-bit LBA Address
• CX - Sector Count
• ES:DI - Buffer
• BYTE [bootDrive] - Drive Number
  

An extremely simple MBR complying to the standard could look like:

[bits16]
[org0x0600]
start:
cli; We do not want to be interrupted
xorax,ax; 0 AX
movds,ax; Set Data Segment to 0
moves,ax; Set Extra Segment to 0
movss,ax; Set Stack Segment to 0
movsp,ax; Set Stack Pointer to 0
.CopyLower:
movcx,0x0100; 256 WORDs in MBR
movsi,0x7C00; Current MBR Address
movdi,0x0600; New MBR Address
repmovsw; Copy MBR
jmp0:LowStart; Jump to new Address
LowStart:
sti; Start interrupts
movBYTE[bootDrive],dl; Save BootDrive
.CheckPartitions:; Check Partition Table For Bootable Partition
movbx,PT1; Base = Partition Table Entry 1
movcx,4; There are 4 Partition Table Entries
.CKPTloop:
moval,BYTE[bx]; Get Boot indicator bit flag
testal,0x80; Check For Active Bit
jnz.CKPTFound; We Found an Active Partition
addbx,0x10; Partition Table Entry is 16 Bytes
deccx; Decrement Counter
jnz.CKPTloop; Loop
jmpERROR; ERROR!
.CKPTFound:
movWORD[PToff],bx; Save Offset
addbx,8; Increment Base to LBA Address
.ReadVBR:
movEBX,DWORD[bx]; Start LBA of Active Partition
movdi,0x7C00; We Are Loading VBR to 0x07C0:0x0000
movcx,1; Only one sector
callReadSectors; Read Sector
.jumpToVBR:
cmpWORD[0x7DFE],0xAA55; Check Boot Signature
jneERROR; Error if not Boot Signature
movsi,WORD[PToff]; Set DS:SI to Partition Table Entry
movdl,BYTE[bootDrive]; Set DL to Drive Number
jmp0x7C00; Jump To VBR
times(218-($-$$))nop; Pad for disk time stamp
DiskTimeStamptimes8db0; Disk Time Stamp
bootDrivedb0; Our Drive Number Variable
PToffdw0; Our Partition Table Entry Offset
times(0x1b4-($-$$))nop; Pad For MBR Partition Table
UIDtimes10db0; Unique Disk ID
PT1times16db0; First Partition Entry
PT2times16db0; Second Partition Entry
PT3times16db0; Third Partition Entry
PT4times16db0; Fourth Partition Entry
dw0xAA55; Boot Signature

Of course this is an extremely simplified MBR, and is only able to load the [first] active partition.

Comments

See Also

Articles

• System Initialization (x86)

External Links

• Fine's MBR code on osdever
• OSRC -- for more boot sector info
• Ranish Partition Manager -- Disk partitioning software

• X86
• Booting
• Bootloaders