mNo edit summary |
mNo edit summary |
||
Line 11: | Line 11: | ||
*Use of custom ACPI methods and tables. | *Use of custom ACPI methods and tables. | ||
Lock-down mode can be disabled by pressing Alt-SysRq-x until the next boot. | Lock-down mode can be disabled by pressing Alt-SysRq-x until the next boot. | ||
This requries the SysRs keys to be enabled https://fedoraproject.org/wiki/QA/Sysrq | This requries the SysRs keys to be enabled https://fedoraproject.org/wiki/QA/Sysrq | ||
Line 28: | Line 28: | ||
*Fedora provides grub2, kernel and associated packages that are loaded by shim which is signed by Verisign (via Microsoft) | *Fedora provides grub2, kernel and associated packages that are loaded by shim which is signed by Verisign (via Microsoft) | ||
*Fedora releases prior to Fedora 18 will refuse to boot until the user disables secure boot in the firmware. | *Fedora releases prior to Fedora 18 will refuse to boot until the user disables secure boot in the firmware. | ||
*A Fedora | *A Fedora remix or Fedora based distribution can ship the Fedora shim, grub2 and kernel unchanged. A customisation of these packages may require signing these using pesign to be able to boot on secure boot enabled machines. | ||
= References = | = References = |
Revision as of 12:59, 24 December 2019
What is Secure boot?
Secure boot is a setup using UEFI firmware to check cryptographic signatures on the boot-loader and associated OS kernel to ensure they have not been tampered with or bypassed in the boot process. Secure boot activates a lock-down mode in the Linux kernel which disables various features kernel functionality:
- Loading kernel modules that are not signed by a trusted key.
- Using kexec to load an unsigned kernel image.
- Hibernation and resume from hibernation.
- User-space access to physical memory and I/O ports.
- Module parameters that allow setting memory and I/O port addresses.
- Writing to MSRs through /dev/cpu/*/msr.
- Use of custom ACPI methods and tables.
Lock-down mode can be disabled by pressing Alt-SysRq-x until the next boot. This requries the SysRs keys to be enabled https://fedoraproject.org/wiki/QA/Sysrq
Background
With the release of Windows 8, Microsoft has decided that all hardware that is marked "Windows 8 client ready" should:
- Have secure boot enabled by default.
- Allow a physically present user to disable secure boot in the firmware interface.
- Ship the Microsoft keys in firmware.
- Allow a physically present user to enrol their own keys in the firmware interface.
With the release of Windows 10, Microsoft has dropped this requirement secure boot to provide an option to be disabled and has turned it into a suggestion.
- Fedora provides grub2, kernel and associated packages that are loaded by shim which is signed by Verisign (via Microsoft)
- Fedora releases prior to Fedora 18 will refuse to boot until the user disables secure boot in the firmware.
- A Fedora remix or Fedora based distribution can ship the Fedora shim, grub2 and kernel unchanged. A customisation of these packages may require signing these using pesign to be able to boot on secure boot enabled machines.
References
- Free software Foundation on Secure boot: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement
- Miscrosoft intro to Secure boot tech paper: http://technet.microsoft.com/library/hh824987.aspx
- Microsoft Windows 8 requirements: http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256
- UEFI specs: http://www.uefi.org/specs/agreement
Related source code repositories:
- signing tools: https://github.com/vathpela/pesign
- bootloader shim: https://github.com/mjg59/shim
Historical discussion - Steering Committee as of 23-Jul-2012.
- Q: I think it would be much better if "Microsoft or UEFI or All hardware OEMs or The Government" would just "do X"
- A: Feel free to contact any of the above and ask them to change their plans. Sadly, we can only work with the plans as we know them.
- Q: Are you sure secure boot will be possible to disable in the firmware?
- A: Yes, the Microsoft Windows 8 ready requirements require that to be the case.
- Q: Can I remove the Microsoft key and use my own?
- A: YES. According to the UEFI and Microsoft Windows 8 ready requirements you can remove all the keys and enroll your own. You will need to sign and install the various components with your new keys.
- Q: Whats this about a $99 fee?
- A: There is a one time fee of $99 to access the Microsoft sysdev portal in order to get your binaries signed by the Microsoft key (shipped by default in all Windows 8 ready devices). The Fedora shim binary has been signed via the Microsoft service and the $99 fee has already been paid. Individual users do not need to pay $99 unless they wish to build their own UEFI applications and get them signed independently.
- Q: What if I want to build a custom kernel or load 3rd party kernel modules?
- A: You will need to disable Secure boot, or setup your own keys and sign everything with them.
- Q: What if I want to make a Fedora remix or distro based on Fedora?
- A: If you ship the Fedora boot shim, grub2 and kernel unchanged, your remix or distro will boot on secure boot enabled machines (if the proposed plan is approved).
- Q: what about ARM?
- A: On ARM Microsoft Windows 8 ready requirements say that Secure boot should be enabled by default and cannot be disabled. Fedora has no plans to support secure boot on that platform and suggests buying Non Windows 8 ready hardware.
- Q: What about the Fedora ARM folks, if UEFI cannot be disabled ? What will the impact be, if we ever are able to install Fedora on to mobile phone units ? Does this not limit users choice ?
- A: Fedora is not responsible for the Windows 8 ARM requirements. There is nothing we can do in this case. See the answer to the above question.
- Q: Does this apply to servers too?
- A: No. This is a Windows 8 client ready set of requirements. Servers will not have secure boot enabled by default.
- Q: If I disable Secure boot, and I have a dual boot setup with Fedora and Windows 8, will Windows 8 boot ok?
- A: Yes. Windows 8 will boot ok with Secure boot disabled.
- Q: What are all these secure boot databases that are talked about?
- A: There are a number of databases kept by Secure boot:
* (signature database (db) - signatures or image hashes of UEFI applications, operating system loaders, and UEFI drivers that can be loaded * revoked signatures database (dbx) - no longer trusted/loadable signers or image hashes. * Key Enrollment Key database (KEK) - database of keys that can be used to update the signature database and revoked signatures database. * platform key (PK) - Generated by OEM's, this database/key allows updating KEK or db's. * Machine Owner Keys (MoK) - A list similar to db above, but provided by shim itself. There is a userspace tool called 'mokutil' that allows for easier enrolment of keys from Linux userspace.
- Q: What are the supposed benefits to us all, if Secure Boot is used ? what exactly are they ? (Elaborate a little please)