26 KiB

Raw Blame History

Kernel booting process. Part 1.

From the bootloader to the kernel

If you have been reading my previous blog posts, then you can see that, for some time, I have been starting to get involved in low-level programming. I have written some posts about x86_64 assembly programming for Linux and, at the same time, I have also started to dive into the Linux source code. I have a great interest in understanding how low-level things work, how programs run on my computer, how are they located in memory, how the kernel manages processes & memory, how the network stack works at a low level, and many many other things. So, I have decided to write yet another series of posts about the Linux kernel for x86_64.

Note that I'm not a professional kernel hacker and I don't write code for the kernel at work. It's just a hobby. I just like low-level stuff, and it is interesting for me to see how these things work. So if you notice anything confusing, or if you have any questions/remarks, ping me on twitter 0xAX, drop me an email or just create an issue. I appreciate it. All posts will also be accessible at linux-insides and, if you find something wrong with my English or the post content, feel free to send a pull request.

Note that this isn't official documentation, just learning and sharing knowledge.

Required knowledge

Understanding C code
Understanding assembly code (AT&T syntax)

Anyway, if you just start to learn some tools, I will try to explain some parts during this and the following posts. Alright, this is the end of the simple introduction, and now we can start to dive into the kernel and low-level stuff.

All code is actually for the 3.18 kernel. If there are changes, I will update the posts accordingly.

The Magical Power Button, What happens next?

Although this is a series of posts about the Linux kernel, we will not be starting from the kernel code - at least not, in this paragraph. As soon as you press the magical power button on your laptop or desktop computer, it starts working. The motherboard sends a signal to the power supply. After receiving the signal, the power supply provides the proper amount of electricity to the computer. Once the motherboard receives the power good signal, it tries to start the CPU. The CPU resets all leftover data in its registers and sets up predefined values for each of them.

80386 and later CPUs define the following predefined data in CPU registers after the computer resets:

IP          0xfff0
CS selector 0xf000
CS base     0xffff0000

The processor starts working in real mode. Let's back up a little and try to understand memory segmentation in this mode. Real mode is supported on all x86-compatible processors, from the 8086 all the way to the modern Intel 64-bit CPUs. The 8086 processor has a 20-bit address bus, which means that it could work with a 0-0x100000 address space (1 megabyte). But it only has 16-bit registers, which have a maximum address of 2^16 - 1 or 0xffff (64 kilobytes). Memory segmentation is used to make use of all the address space available. All memory is divided into small, fixed-size segments of 65536 bytes (64 KB). Since we cannot address memory above 64 KB with 16 bit registers, an alternate method is devised. An address consists of two parts: a segment selector, which has a base address, and an offset from this base address. In real mode, the associated base address of a segment selector is Segment Selector * 16. Thus, to get a physical address in memory, we need to multiply the segment selector part by 16 and add the offset:

PhysicalAddress = Segment Selector * 16 + Offset

For example, if CS:IP is 0x2000:0x0010, then the corresponding physical address will be:

>>> hex((0x2000 << 4) + 0x0010)
'0x20010'

But, if we take the largest segment selector and offset, 0xffff:0xffff, then the resulting address will be:

>>> hex((0xffff << 4) + 0xffff)
'0x10ffef'

which is 65520 bytes past the first megabyte. Since only one megabyte is accessible in real mode, 0x10ffef becomes 0x00ffef with disabled A20.

Ok, now we know about real mode and memory addressing. Let's get back to discussing register values after reset:

The CS register consists of two parts: the visible segment selector, and the hidden base address. While the base address is normally formed by multiplying the segment selector value by 16, during a hardware reset the segment selector in the CS register is loaded with 0xf000 and the base address is loaded with 0xffff0000; the processor uses this special base address until CS is changed.

The starting address is formed by adding the base address to the value in the EIP register:

>>> 0xffff0000 + 0xfff0
'0xfffffff0'

We get 0xfffffff0, which is 4GB (16 bytes). This point is called the Reset vector. This is the memory location at which the CPU expects to find the first instruction to execute after reset. It contains a jump (jmp) instruction that usually points to the BIOS entry point. For example, if we look in the coreboot source code, we see:

    .section ".reset"
    .code16
.globl  reset_vector
reset_vector:
    .byte  0xe9
    .int   _start - ( . + 2 )
    ...

Here we can see the jmp instruction opcode, which is 0xe9, and its destination address at _start - ( . + 2). We can also see that the reset section is 16 bytes, and that it starts at 0xfffffff0:

SECTIONS {
    _ROMTOP = 0xfffffff0;
    . = _ROMTOP;
    .reset . : {
        *(.reset)
        . = 15 ;
        BYTE(0x00);
    }
}

Now the BIOS starts; after initializing and checking the hardware, the BIOS needs to find a bootable device. A boot order is stored in the BIOS configuration, controlling which devices the BIOS attempts to boot from. When attempting to boot from a hard drive, the BIOS tries to find a boot sector. On hard drives partitioned with an MBR partition layout, the boot sector is stored in the first 446 bytes of the first sector, where each sectoris 512 bytes. The final two bytes of the first sector are 0x55 and 0xaa, which designates to the BIOS that this device is bootable. For example:

;
; Note: this example is written in Intel Assembly syntax
;
[BITS 16]
[ORG  0x7c00]

boot:
    mov al, '!'
    mov ah, 0x0e
    mov bh, 0x00
    mov bl, 0x07

    int 0x10
    jmp $

times 510-($-$$) db 0

db 0x55
db 0xaa

Build and run this with:

nasm -f bin boot.nasm && qemu-system-x86_64 boot

This will instruct QEMU to use the boot binary that we just built as a disk image. Since the binary generated by the assembly code above fulfills the requirements of the boot sector (the origin is set to 0x7c00 and we end with the magic sequence), QEMU will treat the binary as the master boot record (MBR) of a disk image.

You will see:

In this example we can see that the code will be executed in 16 bit real mode and will start at 0x7c00 in memory. After starting, it calls the 0x10 interrupt, which just prints the ! symbol; it fills the remaining 510 bytes with zeros and finishes with the two magic bytes 0xaa and 0x55.

You can see a binary dump of this using the objdump utility:

nasm -f bin boot.nasm
objdump -D -b binary -mi386 -Maddr16,data16,intel boot

A real-world boot sector has code for continuing the boot process and a partition table instead of a bunch of 0's and an exclamation mark :) From this point onwards, the BIOS hands over control to the bootloader.

NOTE: As explained above, the CPU is in real mode; in real mode, calculating the physical address in memory is done as follows:

PhysicalAddress = Segment Selector * 16 + Offset

just as explained before. We have only 16 bit general purpose registers; the maximum value of a 16 bit register is 0xffff, so if we take the largest values, the result will be:

>>> hex((0xffff * 16) + 0xffff)
'0x10ffef'

where 0x10ffef is equal to 1MB + 64KB - 16b. A 8086 processor (which was the first processor with real mode), in contrast, has a 20 bit address line. Since 2^20 = 1048576 is 1MB, this means that the actual available memory is 1MB.

General real mode's memory map is as follows:

0x00000000 - 0x000003FF - Real Mode Interrupt Vector Table
0x00000400 - 0x000004FF - BIOS Data Area
0x00000500 - 0x00007BFF - Unused
0x00007C00 - 0x00007DFF - Our Bootloader
0x00007E00 - 0x0009FFFF - Unused
0x000A0000 - 0x000BFFFF - Video RAM (VRAM) Memory
0x000B0000 - 0x000B7777 - Monochrome Video Memory
0x000B8000 - 0x000BFFFF - Color Video Memory
0x000C0000 - 0x000C7FFF - Video ROM BIOS
0x000C8000 - 0x000EFFFF - BIOS Shadow Area
0x000F0000 - 0x000FFFFF - System BIOS

In the beginning of this post, I wrote that the first instruction executed by the CPU is located at address 0xFFFFFFF0, which is much larger than 0xFFFFF (1MB). How can the CPU access this address in real mode? The answer is in the coreboot documentation:

0xFFFE_0000 - 0xFFFF_FFFF: 128 kilobyte ROM mapped into address space

At the start of execution, the BIOS is not in RAM, but in ROM.

Bootloader

There are a number of bootloaders that can boot Linux, such as GRUB 2 and syslinux. The Linux kernel has a Boot protocol which specifies the requirements for a bootloader to implement Linux support. This example will describe GRUB 2.

Continuing from before, now that the BIOS has chosen a boot device and transferred control to the boot sector code, execution starts from boot.img. This code is very simple, due to the limited amount of space available, and contains a pointer which is used to jump to the location of GRUB 2's core image. The core image begins with diskboot.img, which is usually stored immediately after the first sector in the unused space before the first partition. The above code loads the rest of the core image, which contains GRUB 2's kernel and drivers for handling filesystems, into memory. After loading the rest of the core image, it executes grub_main.

grub_main initializes the console, gets the base address for modules, sets the root device, loads/parses the grub configuration file, loads modules, etc. At the end of execution, grub_main moves grub to normal mode. grub_normal_execute (from grub-core/normal/main.c) completes the final preparations and shows a menu to select an operating system. When we select one of the grub menu entries, grub_menu_execute_entry runs, executing the grub boot command and booting the selected operating system.

As we can read in the kernel boot protocol, the bootloader must read and fill some fields of the kernel setup header, which starts at the 0x01f1 offset from the kernel setup code. The kernel header arch/x86/boot/header.S starts from:

    .globl hdr
hdr:
    setup_sects: .byte 0
    root_flags:  .word ROOT_RDONLY
    syssize:     .long 0
    ram_size:    .word 0
    vid_mode:    .word SVGA_MODE
    root_dev:    .word 0
    boot_flag:   .word 0xAA55

The bootloader must fill this and the rest of the headers (which are only marked as being type write in the Linux boot protocol, such as in this example) with values which it has either received from the command line or calculated. (We will not go over full descriptions and explanations for all fields of the kernel setup header now but instead when the discuss how kernel uses them; you can find a description of all fields in the boot protocol.)

As we can see in the kernel boot protocol, the memory map will be the following after loading the kernel:

         | Protected-mode kernel  |
100000   +------------------------+
         | I/O memory hole        |
0A0000   +------------------------+
         | Reserved for BIOS      | Leave as much as possible unused
         ~                        ~
         | Command line           | (Can also be below the X+10000 mark)
X+10000  +------------------------+
         | Stack/heap             | For use by the kernel real-mode code.
X+08000  +------------------------+
         | Kernel setup           | The kernel real-mode code.
         | Kernel boot sector     | The kernel legacy boot sector.
       X +------------------------+
         | Boot loader            | <- Boot sector entry point 0x7C00
001000   +------------------------+
         | Reserved for MBR/BIOS  |
000800   +------------------------+
         | Typically used by MBR  |
000600   +------------------------+
         | BIOS use only          |
000000   +------------------------+

So, when the bootloader transfers control to the kernel, it starts at:

0x1000 + X + sizeof(KernelBootSector) + 1

where X is the address of the kernel boot sector being loaded. In my case, X is 0x10000, as we can see in a memory dump:

The bootloader has now loaded the Linux kernel into memory, filled the header fields, and then jumped to the corresponding memory address. We can now move directly to the kernel setup code.

Start of Kernel Setup

Finally, we are in the kernel! Technically, the kernel hasn't run yet; first, we need to set up the kernel, memory manager, process manager, etc. Kernel setup execution starts from arch/x86/boot/header.S at _start. It is a little strange at first sight, as there are several instructions before it.

A long time ago, the Linux kernel used to have its own bootloader. Now, however, if you run, for example,

qemu-system-x86_64 vmlinuz-3.18-generic

then you will see:

Actually, header.S starts from MZ (see image above), the error message printing and following the PE header:

#ifdef CONFIG_EFI_STUB
# "MZ", MS-DOS header
.byte 0x4d
.byte 0x5a
#endif
...
...
...
pe_header:
    .ascii "PE"
    .word 0

It needs this to load an operating system with UEFI. We won't be looking into its inner workings right now and will cover it in upcoming chapters.

The actual kernel setup entry point is:

// header.S line 292
.globl _start
_start:

The bootloader (grub2 and others) knows about this point (0x200 offset from MZ) and makes a jump directly to it, despite the fact that header.S starts from the .bstext section, which prints an error message:

//
// arch/x86/boot/setup.ld
//
. = 0;                    // current position
.bstext : { *(.bstext) }  // put .bstext section to position 0
.bsdata : { *(.bsdata) }

The kernel setup entry point is:

    .globl _start
_start:
    .byte  0xeb
    .byte  start_of_setup-1f
1:
    //
    // rest of the header
    //

Here we can see a jmp instruction opcode (0xeb) that jumps to the start_of_setup-1f point. In Nf notation, 2f refers to the following local 2: label; in our case, it is label 1 that is present right after jump, and it contains the rest of the setup header. Right after the setup header, we see the .entrytext section, which starts at the start_of_setup label.

This is the first code that actually runs (aside from the previous jump instructions, of course). After the kernel setup received control from the bootloader, the first jmp instruction is located at the 0x200 offset from the start of the kernel real mode, i.e., after the first 512 bytes. This we can both read in the Linux kernel boot protocol and see in the grub2 source code:

segment = grub_linux_real_target >> 4;
state.gs = state.fs = state.es = state.ds = state.ss = segment;
state.cs = segment + 0x20;

This means that segment registers will have the following values after kernel setup starts:

gs = fs = es = ds = ss = 0x1000
cs = 0x1020

In my case, the kernel is loaded at 0x10000.

After the jump to start_of_setup, the kernel needs to do the following:

Make sure that all segment register values are equal
Set up a correct stack, if needed
Set up bss
Jump to the C code in main.c

Let's look at the implementation.

Segment registers align

First of all, the kernel ensures that ds and es segment registers point to the same address. Next, it clears the direction flag using the cld instruction:

    movw    %ds, %ax
    movw    %ax, %es
    cld

As I wrote earlier, grub2 loads kernel setup code at address 0x10000 and cs at 0x1020 because execution doesn't start from the start of file, but from

_start:
    .byte 0xeb
    .byte start_of_setup-1f

jump, which is at a 512 byte offset from 4d 5a. It also needs to align cs from 0x10200 to 0x10000, as well as all other segment registers. After that, we set up the stack:

    pushw   %ds
    pushw   $6f
    lretw

which pushes the value of ds to the stack with the address of the 6 label and executes the lretw instruction. When the lretw instruction is called, it loads the address of label 6 into the instruction pointer register and loads cs with the value of ds. Afterwards, ds and cs will have the same values.

Stack Setup

Almost all of the setup code is in preparation for the C language environment in real mode. The next step is checking the ss register value and making a correct stack if ss is wrong:

    movw    %ss, %dx
    cmpw    %ax, %dx
    movw    %sp, %dx
    je      2f

This can lead to 3 different scenarios:

ss has valid value 0x10000 (as do all other segment registers beside cs)
ss is invalid and CAN_USE_HEAP flag is set (see below)
ss is invalid and CAN_USE_HEAP flag is not set (see below)

Let's look at all three of these scenarios in turn:

ss has a correct address (0x10000). In this case, we go to label 2:

2:  andw    $~3, %dx
    jnz     3f
    movw    $0xfffc, %dx
3:  movw    %ax, %ss
    movzwl  %dx, %esp
    sti

Here we can see the alignment of dx (contains sp given by bootloader) to 4 bytes and a check for whether or not it is zero. If it is zero, we put 0xfffc (4 byte aligned address before the maximum segment size of 64 KB) in dx. If it is not zero, we continue to use sp, given by the bootloader (0xf7f4 in my case). After this, we put the ax value into ss, which stores the correct segment address of 0x10000 and sets up a correct sp. We now have a correct stack:

In the second scenario, (ss != ds). First, we put the value of _end (the address of the end of the setup code) into dx and check the loadflags header field using the testb instruction to see whether we can use the heap. loadflags is a bitmask header which is defined as:

#define LOADED_HIGH     (1<<0)
#define QUIET_FLAG      (1<<5)
#define KEEP_SEGMENTS   (1<<6)
#define CAN_USE_HEAP    (1<<7)

and, as we can read in the boot protocol,

Field name: loadflags

  This field is a bitmask.

  Bit 7 (write): CAN_USE_HEAP
    Set this bit to 1 to indicate that the value entered in the
    heap_end_ptr is valid.  If this field is clear, some setup code
    functionality will be disabled.

If the CAN_USE_HEAP bit is set, we put heap_end_ptr into dx (which points to _end) and add STACK_SIZE (minimum stack size, 512 bytes) to it. After this, if dx is not carried (it will not be carried, dx = _end + 512), jump to label 2 (as in the previous case) and make a correct stack.

When CAN_USE_HEAP is not set, we just use a minimal stack from _end to _end + STACK_SIZE:

BSS Setup

The last two steps that need to happen before we can jump to the main C code are setting up the BSS area and checking the "magic" signature. First, signature checking:

    cmpl    $0x5a5aaa55, setup_sig
    jne     setup_bad

This simply compares the setup_sig with the magic number 0x5a5aaa55. If they are not equal, a fatal error is reported.

If the magic number matches, knowing we have a set of correct segment registers and a stack, we only need to set up the BSS section before jumping into the C code.

The BSS section is used to store statically allocated, uninitialized data. Linux carefully ensures this area of memory is first zeroed using the following code:

    movw    $__bss_start, %di
    movw    $_end+3, %cx
    xorl    %eax, %eax
    subw    %di, %cx
    shrw    $2, %cx
    rep; stosl

First, the __bss_start address is moved into di. Next, the _end + 3 address (+3 - aligns to 4 bytes) is moved into cx. The eax register is cleared (using a xor instruction), and the bss section size (cx-di) is calculated and put into cx. Then, cx is divided by four (the size of a 'word'), and the stosl instruction is used repeatedly, storing the value of eax (zero) into the address pointed to by di, automatically increasing di by four, repeating until cx reaches zero). The net effect of this code is that zeros are written through all words in memory from __bss_start to _end:

Jump to main

That's all - we have the stack and BSS, so we can jump to the main() C function:

    calll main

The main() function is located in arch/x86/boot/main.c. You can read about what this does in the next part.

Conclusion

This is the end of the first part about Linux kernel insides. If you have questions or suggestions, ping me on twitter 0xAX, drop me an email, or just create an issue. In the next part, we will see the first C code that executes in the Linux kernel setup, the implementation of memory routines such as memset, memcpy, earlyprintk, early console implementation and initialization, and much more.

Please note that English is not my first language and I am really sorry for any inconvenience. If you find any mistakes please send me PR to linux-insides.

26 KiB Raw Blame History