6

I understand that the BIOS is in ROM, and the manufacturer "typically" designs it to point to the first sector of the "active" storage device's first sector or CHS (0,0,1)*physical and CHS (0,0,0)*logical which is either an MBR or VBR based on your preference of partitioning.

Wikipedia:

The presence of an IBM PC compatible boot loader for x86-CPUs in the boot sector is by convention indicated by a two-byte hexadecimal sequence 0x55 0xAA (called the boot sector signature) at the end of the boot sector (offsets 0x1FE and 0x1FF). This signature indicates the presence of at least a dummy boot loader which is safe to be executed, even if it may not be able to actually load an operating system.

The boot signature identifies the boot loader using a two-byte hexadecimal sequence, so I'm guessing the signature has to be an offset in the same sector? Therefore then assuming the boot loader must be in this same sector?

Kevin Panko
  • 7,346
  • 22
  • 44
  • 53
Jordan Davis
  • 641
  • 2
  • 8
  • 16
  • [MBR (1983)](https://en.wikipedia.org/wiki/Master_boot_record) predates [LBA (1986ish)](https://en.wikipedia.org/wiki/Parallel_ATA) by a few years, making it rather difficult to have MBR dependent on LBA. – 8bittree Sep 21 '15 at 16:07
  • Yes I understand that, but HOW is the BIOS identifying the boot sector using only a two-bytes?! If the BIOS can do it in two bytes, why aren't we using two bytes for CHS or LBA to identify sectors as does the BIOS. – Jordan Davis Sep 21 '15 at 16:14
  • I just updated the question to make it more clear. – Jordan Davis Sep 21 '15 at 16:18
  • The boot sector signature isn't used to find where on the disk the boot sector is located (it's assumed to be the first sector, or else nonexistant), it's used after reading in that first sector to check if that first sector is, indeed, a boot sector, or if it's some mystery thing that the BIOS should ignore. – 8bittree Sep 21 '15 at 16:23
  • Got it! yea was just reading that it `identifies` the boot loader and that by default goes to the sector. – Jordan Davis Sep 21 '15 at 16:27
  • so I'm guessing the boot-loader would have to be in the same sector, because if the boot-signature is only two bytes, then it would have to be some type of offset within the same sector, right? – Jordan Davis Sep 21 '15 at 16:31
  • Minor nitpick: `two-byte hexadecimal` in inaccurate. It's just `two-bytes`. It's binary data. Hexadecimal is just one of the ways it can be formatted for human understanding (the data itself is not hexadecimal, hexadecimal is just one of the options you can print data as using printf()) – slebetman Sep 21 '15 at 19:05

2 Answers2

9

The basic order of operations that happens while a BIOS is trying to find something to boot is:

  1. Load first sector (512 bytes) of the device you're trying to boot from (HDD, SSD, Floppy Disk, Optical Disc, etc) into memory
  2. Check if the 511th and 512th bytes are 0x55 and 0xAA, respectively.
    • If not, go back to step 1 and try the next device, or give up if there aren't any more.
    • If yes, start executing code at the beginning of this sector, thus passing control to (hopefully) a boot loader/manager.

You might find the OSDev wiki page on the Boot Sequence useful. The MBR page also has a useful table explaining the layout of that first sector. I've recreated it here with some simplification:

Offset | Size (bytes) | Description
    0  | 436          | MBR Bootstrap (flat binary executable code) 
0x1b4  |  10          | Optional "unique" disk ID
0x1be  |  64          | MBR Partition Table, with 4 entries
0x1fe  |   2          | (0x55, 0xAA) "Valid bootsector" signature bytes

Note that the BIOS doesn't necessarily pay any attention to or even know about the disk ID or the partition table.

enter image description here

Jordan Davis
  • 641
  • 2
  • 8
  • 16
8bittree
  • 2,900
  • 1
  • 17
  • 28
  • Well I know it doesn't load the entire disk into memory, but I know what you mean... but what is it checking for in bytes 511 and 512? I mean I know the boot signature is located there but what is the boot signiture declaring to the BIOS? – Jordan Davis Sep 21 '15 at 16:47
  • That link is really good by the way. – Jordan Davis Sep 21 '15 at 16:51
  • The BIOS simply assumes that if the boot signature is there, that there is bootloader code at the beginning of that sector. Note that it is an assumption. There is a 1/65536 chance that there is random garbage that just happens to put 0x55AA in the right spot. – 8bittree Sep 21 '15 at 16:55
  • Haha :D kk got it, and thats at the very end of the sector being that it's bytes (511,512) correct? – Jordan Davis Sep 21 '15 at 16:59
  • offsets `0x1FE` and `0x1FF` (510,511) and the boot signature two-byte hexadecimal sequence `0x55AA` (21930) what does this even mean? – Jordan Davis Sep 21 '15 at 17:12
  • That's the boot signature, in its proper place as we've been talking about. Remember that offsets start at 0, not 1, so offset 0 is the first, offset 1 is the second, offset n-1 is the nth. I'll admit I may have had some confusing (and technically incorrect terms) with an earlier edit of step 2, which is why I altered it to add the "th" after the numbers. – 8bittree Sep 21 '15 at 17:18
  • Ok yea, so executable is (0-445), then tables (446-509) which is 16/per table, then last but not least the signature (510-511), and the signature is literally hex 510(55) and 511(AA) representing decimal values 510(85) and 511(170), and so the BIOS goes to that two byte address and checks to see if 85 and 170 match? if, so it's a valid boot loader lol – Jordan Davis Sep 21 '15 at 17:25
  • That is correct, assuming you're skipping the optional, nonstandard disk ID (which would only affect the size of the executable). – 8bittree Sep 21 '15 at 17:28
  • Ok cool and yea skipping the diskID. Is there a reason why they chose the numbers 85,170 lol? – Jordan Davis Sep 21 '15 at 17:30
  • 1
    [This answer](http://stackoverflow.com/a/1125075/3342206) on Stack Overflow suggests some reasoning behind those numbers (alternating pattern in binary). But it still seems to boil down to just being [magic numbers](https://en.wikipedia.org/wiki/Magic_number_%28programming%29). – 8bittree Sep 21 '15 at 17:36
  • Haha `The alternating bit pattern was thought to be a protection against certain failures (drive or controller).` – Jordan Davis Sep 21 '15 at 17:38
  • When you write that it checks the last bytes and if they are 55aa then "start executing code at the beginning of this sector, thus passing control to (hopefully) a boot loader/manager." Which sector do you mean by "this sector"? Do you mean start executing code of the first sector(first stage boot loader)? And having run the first 446 bytes, will it then jump to address 55aa? Or are the last bytes of the boot sector a jump instruction to wherever the second level boot loader(e.g. GRUB/NTLDR) is? – barlop Sep 27 '20 at 00:13
  • @barlop It starts executing the code at byte zero of the first (i.e. boot) sector. Any jumps to other sectors will have to be handled by the code in that first sector. – 8bittree Sep 28 '20 at 15:23
  • In a system with BIOS/Legacy, and a hard drive with MBR, would execution typically go from the first stage boot loader of the MBR(that boot sector), to a volume boot record(also known as a partition boot sector), to a second stage boot loader? – barlop Sep 28 '20 at 15:26
  • @barlop It will depend on the bootloader. I'm pretty sure GRUB does that and I suspect most modern production bootloaders do as well, so typical is probably accurate. – 8bittree Sep 28 '20 at 16:43
1

BIOS code is in ROM (or EEPROM these days). It loads first sector from the disk (#0 in LBA notation or c=0,h=0,s=1 in CHS notation), verifies that last two bytes are 0x55 and 0xAA and transfers control to this sector.

So, MBR is actually identified by its address, #0. And 55 AA signature is just for verification. If first sector is zero-filled (as for new HDDs), BIOS can detect this by missing 55 AA signature and try to boot from another disk, or PXE, or ROM BASIC, or whatever.

0x55 0xAA is not an offset of MBR, actual offset is zero.

Mikhail Kupchik
  • 2,501
  • 15
  • 22