Understanding MBR/BIOS and GPT/UEFI

Posted at Jan 20, 12:00h in di̇sk Jack Mansfield, Marketing Categories: di̇sk, filesystem, gpt, mbr, tech, technology, windows-internals

Master Boot Record (MBR) and GUID Partition Table (GPT), are two different ways of storing partition and boot information on a disk. Understanding these partitioning schemes is essential to understanding how information is stored on your storage devices and choosing the correct partitioning scheme for your scenario.

Background on Firmware, BIOS, and UEFI

Before we compare MBR and GPT directly, it’s helpful to get some context on why these two different standards exist. To answer this, we first have to discuss computer firmware. 

Firmware is software that provides low level control for a hardware device and is usually embedded in the device itself. For example, firmware that you find on a Smart TV, stored in a non-volatile memory within the TV itself. Using the firmware, you can change the TV’s settings, download applications and update the TV’s firmware. We are interested in motherboard firmware or “computer firmware”. Similarly, to the TV’s firmware, we can use the computer’s firmware to interact with the computer’s hardware on a low level, e.g. change storage mode, change fan speeds, overclock the CPU, and change storage and boot settings. 

There are two types of motherboard firmware which you will see, BIOS and UEFI. You may often hear BIOS and UEFI used interchangeably when talking about computer firmware, however, this is not correct. Both BIOS and UEFI are types of computer firmware, with some important distinctions between them. Your computer’s firmware will either be UEFI or BIOS. 

BIOS, the older of the two, was originally proprietary to the IBM Personal Computer. Following the success of the IBM PC, some companies began copying the IBM PC design and started manufacturing computers able to run the same software as the IBM PC. These are often referred to as IBM PC compatible. Many of these computers had their own version of the IBM BIOS. Other companies like Phoenix Technology used “clean room design” to create their own version of the BIOS which could then be licensed out to third-party OEMs like HP and AT&T. This was the beginning of BIOS becoming a de facto standard, with many OEMs and motherboard manufacturer’s using this third-party BIOS-like firmware.

Due to the age, and to some extent the ‘de facto’ nature of the standard, there were many limitations in BIOS. To address these shortcomings, Intel developed and published the Extensible Firmware Implementation (EFI) standard. In 2005, the Unified EFI forum was formed, designed to continue the development of the EFI specification and promote its adoption in the industry. Members of the forum include Intel, Microsoft, Apple, AMD, Dell, HP, American Megatrends, Phoenix technologies, and many more! Modern firmware is based on the UEFI specification and not the earlier EFI specification developed by Intel alone. Windows support for EFI started with Windows Server 2003 (EFI 1.1) in April 2003 and Windows XP 64-Bit Edition on the Intel Itanium platform in October 2001. Windows XP 64-Bit Edition should not be confused with Windows XP Professional x64 Edition which ran on the x86-64 platform and was released in April 2005. Itanium, unlike x86 and x86-64 CPUs, did not support x86 real mode. UEFI support then became more widespread with Windows 8 and Apple Macs switching to the Intel platform. Windows 11 mandates a series of hardware features to ensure a baseline for a secure system. As part of this, Windows11 will only support UEFI boot.

What are the limitations of BIOS and the strengths of UEFI?

So what are the limitations of BIOS firmware and how does UEFI improve on them? Due to BIOS firmware being designed to run on the IBM PC’s 16-bit 8086 processor, BIOS firmware is specific to the x86 CPU architecture and only supports 16-bit processor mode. 16-bit processor mode is commonly called ‘real mode’ due to the memory address directly corresponding to physical locations in the memory, and does not make use of paging and virtual memory.This means that BIOS can only use 1MB of addressable memory space; this limits addressable memory to 64KB, meaning that all pre-OS device drivers, like a RAID controller, must also run in 16-bit mode. 

Another limitation of BIOS is the lack of defined standard, as a result of this there are many different variations of BIOS firmware that can be found on computers. This can make supporting hardware more difficult, as multiple versions of the same driver may be needed for different versions of BIOS.

In contrast to this, UEFI is not specific to any one CPU architecture and can support 64-bit versions of any chipset, including support for ARM CPUs that do not use the x86-64 instruction set. UEFI boot performance is vastly quicker by overcoming the BIOS limitation of only being able to read a single sector per i/o operation.

The UEFI standard defines syntax and rules for how UEFI firmware is developed, meaning that all UEFI firmware is essentially the same. This simplifies developing standard drivers and UEFI applications (e.g. OS boot loaders like Windows Boot Manager), as they will work on all versions of UEFI firmware. UEFI also supports the verification of binary signatures of software involved in the boot process, including: firmware drivers, EFI applications and the Operating System. Verifying these boot components ensures that only software trusted by the OEM runs during boot, this is known as ‘Safe Boot’. This greatly increases the security of the system by mitigating a possible vector of attack. The majority of UEFI implementations also include a Compatibility Support Module (CSM) that allows the UEFI firmware to emulate earlier BIOS firmware. This enables UEFI firmware to boot older Operating Systems that only support BIOS and legacy booting.

MBR and GPT

When discussing MBR and GPT, it is important to clarify what a partition is. A partition is a logical section of a storage device made up of contiguous sectors, used to store information. File systems then format these partitions into volumes. Information about these partitions (e.g. number of partitions, start and end sectors of partitions, partition attributes, etc.) are stored in the partition table. This partition table is stored in the Master Boot Record on MBR disks and the GUID Partition Table on GPT disks.

Although we can think of firmware types and partitioning schemes being tightly coupled, it is important to note that they are separate concepts. We will be discussing MBR in terms of BIOS booting, and GPT in terms of UEFI booting. However, in principle it is possible to configure a system with BIOS firmware to boot using a GPT disk, and vice versa.

MBR disks are primarily BIOS booted, as a result BIOS firmware and MBR disks are linked and much like BIOS, MBR also has several limitations. MBR is limited to 4 primary partitions that can span no more than 2TB. The 2TB limit is due to the MBR having 32-bits to address sectors on the storage media, with a standard sector size of 512 bytes, the maximum size works out around 2.2 TB. Therefore, any storage beyond 2.2TB would require more bits to address, and cannot be addressed by the MBR’s 32-bit address space1. MBR disks only contain one copy of the MBR, which contains the partition table and boot information; any corruption of the MBR can prevent the Operating System from booting. 

The GPT partition scheme was developed by Intel in tandem with the EFI specification, this was later adopted by the UEFI forum, as a result, we can think of GPT disks being linked with UEFI firmware. GPT initialised disks have several advantages over MBR disks, GPT disks have a maximum number of 128 partitions and the disks have a theoretical limit of 18 exabytes, although this is limited by Windows file systems’ 256 terabyte volume size limit2. GPT disks also contain a redundant copy of the GUID Partition Table, which is used in the event of corruption of the primary GUID Partition Table. 

Conclusion, Macrium Reflect and partition schemes

Macrium Reflect fully supports both MBR and GPT disks. The Macrium Reflect rescue media can be booted in both UEFI and legacy mode, and can be used to repair boot problems for Operating Systems installed on both MBR and GPT disks. The article linked below contains the steps to fix Windows boot problems for both MBR and GPT disks using the Macrium Reflect rescue media:

https://knowledgebase.macrium.com/display/KNOW80/Fixing+Windows+boot+problems

We can expect to see GPT and UEFI continue becoming more widespread due to the many advantages that it has over MBR and BIOS, and maybe even accelerate due to Windows 11 only supporting UEFI systems. If you are planning to upgrade your older BIOS system to a UEFI system, then we recommend ensuring that you are using a GPT disk to make the most of these advantages. Macrium Reflect can be used to restore an MBR disk image to a GPT disk without data loss. The article linked below contains the steps to do this:

https://knowledgebase.macrium.com/display/KNOW80/Restoring+an+MBR+System+image+to+UEFI-GPT

Notes:

1Some USB/SATA devices translate to 4096-byte sectors instead of the standard 512 bytes. This allows the MBR to address up to 16TBs of storage instead of 2TB. More information can be read about this at the link below:

https://knowledgebase.macrium.com/display/KNOW80/Incompatible+Disk+Selected

2The maximum volume size limit is increased by the Resistant File System (ReFS) to 35 PB. ReFS is fully supported by Macrium Reflect Server and Server Plus editions.

https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overview


Previous Post

How has Manchester shaped science and technology?

Next Post

Macrium Software shortlisted — The Northern Tech 100 Awards 2021