UEFI secure boot

UEFI secure boot

According to Wikipedia UEFI - Unified Extensible Firmware Interface (EFI) - the interface between the operating system and the firmware that controls the low-level functions of the equipment, its main purpose: to correctly initialize the equipment when the system is turned on and transfer control to the operating system loader. EFI is designed to replace the BIOS - the interface that is traditionally used by all IBM PC-compatible personal computers.

Most likely, many will soon have questions on this topic:

UEFI's Secure Download Protocol is part of the latest UEFI release specification. It allows you to install one or more signed keys in the system firmware. Once enabled, the “secure boot” UEFI prevents the download of executable files or drivers if they are not signed by one of the pre-installed keys. Another set of keys (Pkek) allows you to maintain communication between the OS and the firmware. An OS together with a set of Pkek matching keys that communicate with the keys installed in the firmware can add additional keys to the so-called “white list” in the firmware. Naturally, in addition, she can add keys to the “black list”. Naturally, binaries marked in the black list of keys will not work at boot.

At the moment there is no centralized mechanism for signing UEFI keys. If the manufacturer's system contains a key, then the only way to get the code signed by this key is to contact the manufacturer to sign. There may be several keys stitched into the system, but if you cannot use any of them to sign your binaries, they will not be installable.
')
This certainly has an impact on both software and hardware vendors. OS manufacturers will not be able to download their software in the system until it is signed with a key that is included in the firmware system. The hardware manufacturer will not be able to run its hardware inside the EFI environment until its drivers are signed by the same keys in the system firmware. For example, when installing a new video card that has unsigned drivers that naturally were not found in your system firmware, you cannot make it work in this environment.

Microsoft's requirement is that Windows-compatible systems and systems with the client version of Windows 8 come with “safe boot” enabled. Two alternatives are suggested. The first is that each copy of Windows must be signed with a key from Microsoft, and its public part is sewn into all systems, or alternatively, the second method suggests for each OEM manufacturer to place its key in the system and sign a pre-installed copy of Windows with it. The second method will make it impossible to launch a boxed copy of Windows OS on Windows-compatible systems, it will also be impossible to install new versions of Windows until your OEM-manufacturer signs the new version. The first option seems more likely.

A system that comes only with OEM keys and Microsoft will not be able to download copies of Linux.

Now, most likely, we can provide signed versions of Linux. But it is not so easy and there will be several problems. First, you need a non-GPL bootloader. Grub 2 is released under GPLv3, which clearly states that we provide signature keys. Grub, which is released under GPLv2, which lacks an explicit key requirement, but may contain a request for scripts used to control the compilation, which may contain this requirement. This is a “gray area”, and using exploits will show the bad faith of the parties quite well. Secondly, in the near future, the core design will become part of the bootloader. This means that the kernel will also have to be signed. This will make it almost impossible for users or developers to create (assemble) their own kernels. Finally, if we provide the signature to ourselves, it is still necessary that our keys be included in the OEM list.

In principle, there is no indication that Microsoft will not allow equipment suppliers to provide an “ON / OFF” function for this kind of firmware so that the user can still run unsigned code. Nevertheless, experience shows that many software manufacturers and OEMs are interested in providing the minimum firmware functionality necessary for their market. It is almost certain that some systems will be supplied with the ability to disable this feature, but on the other hand as a result of certain agreements, it may turn out that most manufacturers will not leave the right to users.

This article should not make you panic, just think about it ...

PS From myself I want to add that most likely in the future, two lines from the manufacturer may appear, more expensively with the support of disabling signature verification, and cheaper, i.e. with limited functionality, especially it seems to me to affect mobile computers (laptops, netbooks, etc.)
The original article can be found at the link: ORIGINAL

PPS Translated in tandem with a friend, KoPBuH thanks, unfortunately, as long as it is not Habre, but I hope it will appear soon.