Bootstrapping (computing) - Wikipedia, the free encyclopedia



Bootstrapping

In computing, bootstrapping refers to a process where a simple system activates another more complicated system that serves the same purpose. It is a solution to the Chicken-and-egg problem of starting a certain system without the system already functioning. The term is most often applied to the process of starting up a computer, in which a mechanism is needed to execute the software program that is responsible for executing software programs (the operating system).

Bootstrapping was shortened to booting, or the process of starting up any computer, which is the most common meaning for non-technical computer users. The verb "boot" is similarly derived. A "bootstrap" most commonly refers to the simple program itself that actually begins the initialization of the computer's operating system, like GRUB, LILO or NTLDR. Modern personal computers have the ability of using their network interface card (NIC) for bootstrapping; on IA-32 (x86) and IA-64 (Itanium) this method is implemented by PXE and Etherboot.

The computer is regarded as starting in a "blank slate" condition - either its main memory is blank, or else its content is suspect due to a prior crash. Although magnetic core memory retains its state with the power off, there would still exist the problem of loading in to it the very first programme. A special start programme could be very large, and given the modern affordability of read-only memory chips, could constitute the entire programme to be run (as in embedded systems) but such an arrangement is inflexible. The bootstrap part would be a short simple piece of code that loads the main code.

Thus the bootstrap sequence begins with a very simple hardware state, plus arrangements that cause something to be read into memory and executed. That something is the bootstrap loader, which is capable of loading an arbitrary programme into an arbitrary part of memory, and then starting it. Note the changes in tempo along the way. The initial state is half-way through the hardware's instruction cycle, as if the instruction had been read into the instruction register but before it is executed. This is followed by the execution of a programme that is not in memory except that its instructions are read (from specially-prepared input) into memory just before they are executed, then that simple programme is executed, that (due to carefully-prepared input) places a programme somewhere in memory, that finally is executed.

Master boot record

|Structure of a Master Boot Record |

|Address |Description |Size |

| | |in |

| | |bytes |

|Hex |Dec | | |

|0000 |0 |Code Area |max. |

| | | |446 |

|01B8 |440 |Optional Disk signature |4 |

|01BC |444 |Usually Nulls; 0x0000 |2 |

|01BE |446 |Table of primary partitions |64 |

| | |(Four 16-byte entries, IBM | |

| | |Partition Table scheme) | |

|01FE |510 |55h |MBR signature; |2 |

| | | |0xAA55[1] | |

|01FF |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 ("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's possible to create a record that acts as both, it's called 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.[1][2][3][4]

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.

[pic]MBRs and disk partitioning

|Layout of one 16-byte partition record |

|Offset |Description |

|0x00 |(1 byte) Status[3] (0x80 = bootable, 0x00 = |

| |non-bootable, other = malformed[4]) |

|0x01 |(3 bytes) Cylinder-head-sector address of the first |

| |sector in the partition[5] |

|0x04 |(1 byte) Partition type[5] |

|0x05 |(3 bytes) Cylinder-head-sector address of the last |

| |sector in the partition[6] |

|0x08 |(4 bytes) Logical block address of the first sector |

| |in the partition |

|0x0C |(4 bytes) Length of the partition, in sectors |

Where a data storage device has been partitioned with (what Microsoft terms) 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, BSD disklabels, and Logical Disk Manager metadata partitions that are described by those primary entries.[6]

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)[7] or even eight (AST or NEC DOS)[8][9] entries.

Where a data storage device has been partitioned with the GUID Partition Table 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 only understand the MBR Partition Table scheme from creating any partitions in what they would see as only free space on the disk.

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 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 only be involved insofar as it might contain the partition table if the MBR Partition Table scheme has been used.

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

MBRs and disk identity

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.[10]

Windows NT (and later Microsoft operating systems) use 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.[11] 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 were 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 (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 ([7]).

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.

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. Some of the end of the 512 byte sector is preallocated 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)[8]. 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.

Differences in MBR Code

Even different versions of the MS-DOS FDISK program, not to mention the partitioning utilities for other types of operating systems, may write variations of code to the MBR sector. For example, the bytes of code written by FDISK under MS-DOS 6.22, Windows 98 and the Recovery Console of a Windows XP install CD are all different. Yet, no matter how great a difference exists in the MBR code, such as that written by an MS-DOS 3.30 install compared to the MBR produced by Windows XP, they will all load the boot sector of any OS residing in the "active" primary partition.

The following table shows how the Standard Microsoft MBR Code (created by MS-DOS 3.30 through Windows 95) would appear in a disk editor:

Absolute Sector 0 (Cylinder 0, Head 0, Sector 1)

0 1 2 3 4 5 6 7 8 9 A B C D E F

0000 FA 33 C0 8E D0 BC 00 7C 8B F4 50 07 50 1F FB FC .3.....|..P.P...

0010 BF 00 06 B9 00 01 F2 A5 EA 1D 06 00 00 BE BE 07 ................

0020 B3 04 80 3C 80 74 0E 80 3C 00 75 1C 83 C6 10 FE ... ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download