Why the UEFI Secure boot is a challenge for Linux
A recent publication on Habré on the limitations of UEFI caused a wide discussion, in continuation of the topic, I want to share a translation of the current post from the blog of Matthew Garrett, one of the developers of RedHat.
I wrote about the technical details of the Linux support for the UEFI Secure boot specification. Despite the fact that I explicitly stated that it ignores licensing issues and key distribution, however, relying on it, people say that Secure boot support can be added to Linux with minimal effort. In a sense, they are right. The technical details of the implementation are quite simple. But the difficulties are not in them.
Currently, if you can execute an untrusted code before booting the OS, you can do whatever you want with the OS. Secure boot provides a mechanism that allows you to be sure that you run only trusted code, which is designed to protect against such scenarios. So, your UEFI drivers are digitally signed, the bootloader is also digitally signed and can only download the signed kernel. If you used only trusted code to boot, then you can be sure that your OS is safe. But, unlike downloading trusted code, Secure boot does not give you the opportunity to be sure that only trusted code is executed. This should be provided by OS policies.
')
At first glance, this is not a big problem. But really is her. Imagine that you have a signed Linux bootloader and a signed Linux kernel and these signatures are made using a global trusted key. They will be loaded on any hardware using Secure boot. Now imagine that an attacker writes a kernel module that creates a fake UEFI environment, interrupts the code execution by the kernel, and calls the Windows bootloader — something like kexec, but a bit more complicated. The Windows loader is sure that it is running in Secure boot, but in fact, everything that in his opinion is trustworthy is a fake UEFI code written by an attacker. The user's encryption key is recorded, the Windows kernel is modified to hide the Linux code, and despite the fact that everything looks great, your credit card details are already on the way to China. In this scenario, the signed Linux kernel is simply used as a malware loader. The only sign that something is wrong is a slightly longer OS load.
A signed kernel is not enough. A signed Linux kernel should prevent the loading of any unsigned kernel modules. Virtualbox in Linux? Goodbye. Binary Nvidia Drivers? Goodbye. Anything beyond the standard kernel modules? Also to new meetings. Self build new drivers? Next time. All this obviously will not make people happier.
(The same applies, of course, to Windows. Windows 7 allows you to disable digital signature verification of drivers, but Windows 8 will not allow this if the system uses the Secure boot mechanism).
GPLv3 has different requirements for the availability of keys used for signing. According to the new Microsoft requirements, the system must support the installation of user keys, which will allow users to use their own OS loaders, which may well be enough to comply with the license requirements. But we become addicted to Microsoft - if they remove this requirement, then users lose their freedom and we find ourselves in an awkward position with the question of licensing. Discussions about what exactly we can do in this case are still ongoing, but at the current moment this problem has not been solved.
The UEFI specification does not define who will be the central certification authority. Microsoft insists everyone have their own key. Of course, we can generate our own keys, but not everything is so simple with equipment manufacturers. There is no way to ensure that all iron producers support them. And, obviously, if we generate a key, we cannot simply transfer its private part to third parties. This means that it will be impossible for people to release their own distributions based on others without obtaining their private key. To obtain the key, some identification verification procedure will be required, which is likely to be costly, and it is also likely that a legally registered organization may be required to ensure verification of identification data. I think these will be certificates of Extended Validation, not Startssl Free. Thus, Linux distributions created by enthusiasts will be in the past.
Microsoft's certification requirements indicate that all systems must support Custom mode; the implementation of this feature should allow users to set their own keys. Linux vendors will be able to supply their own keys along with the distribution and install their own policies. Everyone is happy. In fact, everything is not so good. People have to spend an incredible amount of time and effort to install Linux, instead of just inserting a CD into the drive. The need to change the firmware and reconfigure it adds an additional barrier and limits the ability to install Linux only by more technically competent users. And this is even worse. Here is a complete description of the requirements for Custom mode:
1. For a user physically located behind the device, it should be possible to use the Custom mode, to modify the contents of the Secure boot and PK signature database (for example, the translator: PK is a private key) .
2. If the user removes PK, then when leaving the Custom mode, the system will function in the Setup Mode with the Secure Boot disabled by default.
3. The firmware setup menu should notify you when the Secure boot is enabled, as well as about the Standard or Custom mode. The setup menu should also provide the ability to return from Custom to Standard mode, with restoring the factory default settings.
Something is missing here, for example:
- Any description of UI. This makes it virtually impossible to document the Linux installation process when the first step (a) is confused and (b) depends on the manufacturer. Iron producers are trying to isolate themselves by offering their own unique firmware interfaces. Custom mode in them may look completely different.
- Any description of the key format. Simple binary key representation? Or structure EFI_SIGNATURE_DATA? The key is encoded in base64, then protected by ROT13? We just don't know.
- Any way to use the Custom mode when unattended-installation options of the OS. The firmware interface requires the physical presence of the user. Do you want to install the OS on several thousand machines over the network? This is not a scalable approach.
- ... and one trifle, in fact, there are no requirements anywhere that the user could add the key himself, iron producers can take advantage of this, allowing only to delete the keys. This is not bad as long as users can delete the PK, because then they will return back to Setup mode and will be able to install our keys from the installer, but in practice this will still cause problems.
All the same, Custom mode does not solve all the problems. Custom mode with a strictly defined UI and key format would be much better, but still does not solve the problem with the automatic unattended-installation option of the OS.
We can write the code required to support Secure boot in Linux in a short time — in fact, most of it has already been completed. But significant practical problems remain, and to date we do not have a working solution for any of them.
I wrote about the technical details of the Linux support for the UEFI Secure boot specification. Despite the fact that I explicitly stated that it ignores licensing issues and key distribution, however, relying on it, people say that Secure boot support can be added to Linux with minimal effort. In a sense, they are right. The technical details of the implementation are quite simple. But the difficulties are not in them.
Safe boot requires that all code that interacts with hardware is trusted.
Currently, if you can execute an untrusted code before booting the OS, you can do whatever you want with the OS. Secure boot provides a mechanism that allows you to be sure that you run only trusted code, which is designed to protect against such scenarios. So, your UEFI drivers are digitally signed, the bootloader is also digitally signed and can only download the signed kernel. If you used only trusted code to boot, then you can be sure that your OS is safe. But, unlike downloading trusted code, Secure boot does not give you the opportunity to be sure that only trusted code is executed. This should be provided by OS policies.
')
At first glance, this is not a big problem. But really is her. Imagine that you have a signed Linux bootloader and a signed Linux kernel and these signatures are made using a global trusted key. They will be loaded on any hardware using Secure boot. Now imagine that an attacker writes a kernel module that creates a fake UEFI environment, interrupts the code execution by the kernel, and calls the Windows bootloader — something like kexec, but a bit more complicated. The Windows loader is sure that it is running in Secure boot, but in fact, everything that in his opinion is trustworthy is a fake UEFI code written by an attacker. The user's encryption key is recorded, the Windows kernel is modified to hide the Linux code, and despite the fact that everything looks great, your credit card details are already on the way to China. In this scenario, the signed Linux kernel is simply used as a malware loader. The only sign that something is wrong is a slightly longer OS load.
A signed kernel is not enough. A signed Linux kernel should prevent the loading of any unsigned kernel modules. Virtualbox in Linux? Goodbye. Binary Nvidia Drivers? Goodbye. Anything beyond the standard kernel modules? Also to new meetings. Self build new drivers? Next time. All this obviously will not make people happier.
(The same applies, of course, to Windows. Windows 7 allows you to disable digital signature verification of drivers, but Windows 8 will not allow this if the system uses the Secure boot mechanism).
Licensing
GPLv3 has different requirements for the availability of keys used for signing. According to the new Microsoft requirements, the system must support the installation of user keys, which will allow users to use their own OS loaders, which may well be enough to comply with the license requirements. But we become addicted to Microsoft - if they remove this requirement, then users lose their freedom and we find ourselves in an awkward position with the question of licensing. Discussions about what exactly we can do in this case are still ongoing, but at the current moment this problem has not been solved.
Key distribution
The UEFI specification does not define who will be the central certification authority. Microsoft insists everyone have their own key. Of course, we can generate our own keys, but not everything is so simple with equipment manufacturers. There is no way to ensure that all iron producers support them. And, obviously, if we generate a key, we cannot simply transfer its private part to third parties. This means that it will be impossible for people to release their own distributions based on others without obtaining their private key. To obtain the key, some identification verification procedure will be required, which is likely to be costly, and it is also likely that a legally registered organization may be required to ensure verification of identification data. I think these will be certificates of Extended Validation, not Startssl Free. Thus, Linux distributions created by enthusiasts will be in the past.
Doesn't Custom mode solve this problem?
Microsoft's certification requirements indicate that all systems must support Custom mode; the implementation of this feature should allow users to set their own keys. Linux vendors will be able to supply their own keys along with the distribution and install their own policies. Everyone is happy. In fact, everything is not so good. People have to spend an incredible amount of time and effort to install Linux, instead of just inserting a CD into the drive. The need to change the firmware and reconfigure it adds an additional barrier and limits the ability to install Linux only by more technically competent users. And this is even worse. Here is a complete description of the requirements for Custom mode:
1. For a user physically located behind the device, it should be possible to use the Custom mode, to modify the contents of the Secure boot and PK signature database (for example, the translator: PK is a private key) .
2. If the user removes PK, then when leaving the Custom mode, the system will function in the Setup Mode with the Secure Boot disabled by default.
3. The firmware setup menu should notify you when the Secure boot is enabled, as well as about the Standard or Custom mode. The setup menu should also provide the ability to return from Custom to Standard mode, with restoring the factory default settings.
Something is missing here, for example:
- Any description of UI. This makes it virtually impossible to document the Linux installation process when the first step (a) is confused and (b) depends on the manufacturer. Iron producers are trying to isolate themselves by offering their own unique firmware interfaces. Custom mode in them may look completely different.
- Any description of the key format. Simple binary key representation? Or structure EFI_SIGNATURE_DATA? The key is encoded in base64, then protected by ROT13? We just don't know.
- Any way to use the Custom mode when unattended-installation options of the OS. The firmware interface requires the physical presence of the user. Do you want to install the OS on several thousand machines over the network? This is not a scalable approach.
- ... and one trifle, in fact, there are no requirements anywhere that the user could add the key himself, iron producers can take advantage of this, allowing only to delete the keys. This is not bad as long as users can delete the PK, because then they will return back to Setup mode and will be able to install our keys from the installer, but in practice this will still cause problems.
All the same, Custom mode does not solve all the problems. Custom mode with a strictly defined UI and key format would be much better, but still does not solve the problem with the automatic unattended-installation option of the OS.
Conclusion
We can write the code required to support Secure boot in Linux in a short time — in fact, most of it has already been completed. But significant practical problems remain, and to date we do not have a working solution for any of them.
Source: https://habr.com/ru/post/136504/
All Articles