📜 ⬆️ ⬇️

A little about UEFI and Secure Boot

UEFI


UEFI (Unified Extensible Firmware Interface) - replacing the outdated BIOS. This specification was invented by Intel for Itanium, then it was also called EFI (Extensible Firmware Interface), and then ported to x86, x64 and ARM. It is strikingly different from the BIOS as the boot procedure itself, and how to interact with the OS. If you bought a computer in 2010 and later, then most likely you have a UEFI.

The main differences between UEFI and BIOS:


GPT is a new markup method, replacing the MBR. Unlike the MBR, GPT supports disks larger than 2TB and an unlimited number of partitions, while the MBR only supports crutches 4. UEFI supports FAT32 by default with GPT partitions. The UEFI MBR itself does not support, support and downloading from the MBR is done by the extension CSM (Compatibility Support Module).


There are two types of services in UEFI: boot services and runtime services. The first ones work only until the OS loads and provide interaction with graphic and text terminals, buses, block devices, etc., and runtime services can use the OS. One example of runtime services is the variable service, which stores values ​​in NVRAM. Linux uses a variable service to store crash dumps that can be pulled out after a computer restart.
')

You can use your applications in UEFI. You can upload your drivers to UEFI. No, really! There is such a thing as UEFI Shell. Some manufacturers include it in their UEFI, but on my laptop (Lenovo Thinkpad X220) it is not. But you can simply download it from the Internet and put it on a USB flash drive or hard drive. There are also drivers for ReiserFS, ext2 / 3/4 and maybe some other ones, I didn’t get too deep. They can be downloaded from the UEFI Shell and walk across the expanses of their file system directly from UEFI.
UEFI also supports the network, so if you find a UEFI driver for your network card, or if it is enabled by the motherboard manufacturer, you can ping 8.8.8.8 from Shell.
In general, the UEFI specification provides for interaction between UEFI drivers from the OS, i.e. if you don’t have a driver on the network card in the OS, and it is loaded in UEFI, then the OS can use the network card through UEFI, but I haven’t seen such implementations.


In general, for UEFI you do not need to install a bootloader if you want multiboot. You can add your own menu items, and they will appear in the UEFI boot menu, right next to the disks and flash drives. This is very convenient and allows you to load Linux without a boot loader at all, and immediately the kernel. Thus, you can install Windows and Linux without third-party downloaders.

How is loading in UEFI?

From the GPT partition with the identifier EF00 and the FAT32 file system, by default the file \ efi \ boot \ boot [architecture name] .efi is loaded and launched, for example \ efi \ boot \ bootx64.efi
Those. for example, to create a bootable USB flash drive with Windows, simply mark the USB flash drive in GPT, create a FAT32 partition on it and simply copy all the files from the ISO image. Boot sectors are no more, forget about them.
Downloading to UEFI is much faster, for example, loading my laptop with ArchLinux from pressing the power button to a fully operational state is only 30 seconds. As far as I know, Windows 8 also has very good optimizations for download speeds in UEFI mode.

Secure boot


I saw a lot of questions on the Internet, like:
“I heard that Microsoft is implementing Secure Boot in Windows 8. This technology does not allow unauthorized code to run, for example, bootloaders, to protect the user from malware. And there is a campaign from the Free Software Foundation against Secure Boot, and many people were against it. If I buy a computer with Windows 8, can I install Linux or another OS? Or does this technology allow you to run only Windows? ”

Let's start with the fact that this technology was not invented by Microsoft, but it is included in the UEFI 2.2 specification. The included Secure Boot does not mean that you can not run an OS other than Windows. In fact, computers and laptops that are certified to run Windows 8 must have the ability to disable Secure Boot and the ability to manage keys, so there’s nothing to worry about. Non-switchable Secure Boot is only available on ARM tablets with Windows preinstalled!

What does Secure Boot provide? It protects against the execution of unsigned code not only at boot time, but also at run time of the OS, for example, both in Windows and Linux, the signatures of kernel drivers / modules are checked, thus, the malicious code in kernel mode cannot be executed. But this is only valid if there is no physical access to the computer , because, in most cases, with physical access, the keys can be replaced with their own.

Secure Boot has 2 modes: Setup and User. The first mode is used for configuration, from it you can replace PK (Platform Key, default is from OEM), KEK (Key Exchange Keys), db (base of allowed keys) and dbx (base of recalled keys). KEK may not be, and everything can be signed by PK, but no one does this, it seems like. PK is the main key with which KEK is signed, in turn, the keys from KEK (there may be several of them) are signed by db and dbx. To be able to run some kind of signed .efi-file from under the User-mode, it must be signed by the key, which is in db, and not in dbx.

For Linux, there are 2 pre-bootloaders that support Secure Boot: Shim and PRELoader. They are similar, but there are small nuances.
There are 3 types of keys in Shim: Secure Boot keys (those in UEFI), Shim keys (which you can generate yourself and specify when compiling), and MOK (Machine Owner Key) are stored in NVRAM. Shim does not use the UEFI boot mechanism, so a bootloader that does not support Shim and does not know anything about MOK will not be able to execute the code (thus, the gummiboot bootloader will not work). PRELoader, by contrast, embeds its authentication mechanisms in UEFI, and there are no problems.
Shim is MOK dependent, i.e. Binaries must be changed (signed) before they are executed. The PRELoader “remembers” the correct binaries, you tell it whether you trust them or not.
Both pre-bootloaders are compiled with a valid signature from Microsoft, so changing the UEFI keys is not necessary.

Secure Boot is designed to protect against bootkits, from attacks like Evil Maid, and, in my opinion, it does this effectively.
Thanks for attention!

Source: https://habr.com/ru/post/185492/


All Articles