Restrictions Imposed by UEFI Secure Boot

Updated

When UEFI Secure Boot is enabled, all loadable kernel modules (device drivers) must be signed and authenticated with a key that is on the system keyring. Kernel modules that are not authenticated will not load. That is, the system behaves as if the kernel parameter module.sig_enforce is set.

When UEFI Secure Boot is enabled, GRUB 2 module loading is disabled. Since there is no infrastructure for signing and verification of GRUB 2 modules, allowing them to be loaded would constitute execution of untrusted code inside the security perimeter that Secure Boot defines. Instead, Red Hat provides a signed GRUB 2 binary that has all the modules supported on Red Hat Enterprise Linux 7 already included.

In addition, the Red Hat Enterprise Linux 7 kernel disables the use of mechanisms that could be used to modify the resident kernel with unauthenticated code. The following operations are disabled even for root:

  • The use of the kexec_load system call is not allowed.[1]

  • User mode direct hardware access is not allowed. This prevents access to PCI resources, DMA, and read-write operations to ports.

  • Write access to /dev/mem/ and /dev/kmem/ is not allowed.[2]

  • Hibernation and the user space software suspend interface are disabled.

  • User space is prevented from passing a request to the kernel to execute an ACPI "custom method" and the acpi_rsdp kernel parameter is ignored.

  • The Asus WMI debugfs interface is disabled.

    Important applications have been enhanced to avoid these restrictions:

    [1] The new kexec_file_load system call supports the loading of signed and authenticated kernels:

    - kdump has been enhanced to use this new system call and kdump now works with secure boot enabled.
    
    - The kexec shell command uses the new system call when the `--kexec-file-syscall` option is specified. Note that the kernel must be signed and authenticated with a key on the system keyring in order to be loaded.
    

    [2] SystemTap has been updated such that it no longer depends on write access to /dev/mem and /dev/kmem and now works with secure boot enabled.

Category
Tags
Article Type