Tag Archives: BIOS

What happens when you turn a computer on?

Working on a computer is so easy nowadays that we find even children handling them expertly. However, several things start to happen when we turn on the power to a computer, before it can present the nice user-friendly graphical user interface (GUI) screen that we call the desktop. In a UNIX-like operating system, the computer goes through a process of booting, BIOS, Master Boot Record, Bootstrap Loading, grub, init, before reaching the operating level.


As soon as you switch on the computer, the motherboard initializes its own firmware to get the CPU running. Some registers, such as the Instruction Pointer of the CPU, have permanent values that point to a fixed memory location in a read only memory (ROM) containing the basic input output system (BIOS) program. The CPU begins executing the BIOS from the ROM.


The BIOS program has several important functions, which begin with the power on self-test (POST) to ensure all the components present in the system are functioning properly. POST indicates any malfunction in the form of audible beeps. You have to refer to the Beep Codes of the motherboard to decipher them. If the computer passes the test for the video card, it displays the manufacturer’s logo on its screen.

After checking, BIOS initializes the various hardware devices. This allows them to operate without conflicts. Most BIOSs follow the ACPI create tables for initializing the devices in the computer.

In the next stage, the BIOS looks for an Operating System to load. The search sequence follows an order predefined by the manufacturer in the BIOS settings. However, the user can change this Boot Order to alter the actual search. In general, the search order starts with the hard disk, CD-ROMs, and thumb drives. If the BIOS does not find a suitable operating system, it displays an error. Otherwise, it reads the master boot record (MBR) to know where the operating system is located.

Master Boot Record

In most cases, the operating system resides in the hard disk. The first sector of the hard disk is the master boot record (MBR), and its structure is independent of the operating system. It consists of a special program, the bootstrap loader, and a partition table. The partition table is actually a list of all the partitions in the hard disk and their file system types. The bootstrap loader contains the code to start loading the operating system. Complex operating systems such as Linux use the grand unified boot loader (GRUB), which allows selecting of one of the several operating systems present on the hard disk. Booting an operating system using GRUB is a two-stage process.


Stage one of the GRUB is a tiny program and its only task is to call stage two, which contains the main code for loading the Linux Kernel and the file system into the RAM. The Kernel is the core component of the operating system, remains in the RAM throughout the session, and controls all aspects of the system through its drivers and modules. The last step of the kernel boot sequence is the init, which determines the initial run-level of the system. Unless otherwise instructed, it brings the computer to the graphical user interface (GUI) for the user to interact.

What are UEFI and Secure Boot?

When you first turn on the power button of a computer at the start of your day, your PC or laptop goes through a set of procedures before allowing you to log in. The first thing that happens is the reset signal generated sets the registers of the CPU to their pre-defined values. The reset vector within the CPU now points to the start address of the BIOS or Basic Input Output System.

BIOS is a small firmware stored in a flash memory on the motherboard of the computer. It functions as a startup process for setting up the various hardware peripherals attached to the motherboard. BIOS starts with the POST or Power-on Self-Test, which checks for the presence of basic stuff such as the monitor, keyboard, mouse and memory – primary and secondary. Next, it looks for the MBR or the Master Boot Record on the secondary memory storage – the hard disk or a Solid State Device.

The MBR contains the Primary Boot loader that redirects the CPU to the Secondary Boot loader. What you see on the screen as GRUB when booting into Linux is the Secondary Boot loader is responsible for loading the actual Operating System present on the memory device of the computer.

Hackers planning to usurp the control of your computer have been targeting some of the elements in this chain of the booting process. Malware planted in the computer can modify the boot loaders so that it first enables a sleeping Trojan horse (a form of virus), before actually loading the Operating System. That allows the virus to control whatever you are doing with the computer and report it back to its original master.

To prevent this from happening, members of the PC industry have modified the plain and simple BIOS to a UEFI secure boot type. When booted through UEFI or Unified Extensible Firmware Interface, the firmware ensures that the system boot loader has a cryptographic key as authorized by a database within the firmware. The next steps involve the boot loaders in a series of signature verification for the kernel and possibly of the user space. That prevents any unsigned code (the Trojan horse) from executing and compromising your computer.

The computer requires no specialized hardware to implement and operate UEFI Secure Boot. The firmware resides in the non-volatile flash storage on the motherboard. This storage also stores the UEFI implementation itself as well as the protected variables including the trusted root certificates of the UEFI.

Therefore, unless presented with a signed next-stage boot loader, the UEFI Secure Boot will prevent your computer from functioning, unless you disable or switch off the Secure Boot mode. Note that UEFI Secure Boot does not verify signatures when installing or changing the boot loaders. Signatures are verified only when booting up and any tampered boot path leads to a display of invalid signature, preventing further operations. Unlike web server certificates, there is no information as to who issued the certificate and the user has no way of overriding the decision to reject the signature of the boot loader.