As far as I know, enabled Secure Boot feature in UEFI stores signed keys in NVRAM for OSs' kernel images to check it's corruptness on boot level. But nothing prevents me to boot the Setup Menu and disable this feature, until the UEFI menu password-locked.

Since then, the only way to access kernel image and load my malicious code is Evil Maid attack via resetting UEFI's password. But if we can access the motherboard, why then we need Secure Boot specification?

  • 1
    @chzzh You should take a look at superuser.com/help/dont-ask Your specific question was "But if we can access the motherboard, why then we need Secure Boot specification?" Outside of chat this isn't really the place for discussion.
    – jdwolf
    Oct 21, 2018 at 16:01
  • 1
    @jdwolf That was the second part of my question, where Secure Boot stated as boot sequence locker, which, as it turned out, is not.
    – user631561
    Oct 21, 2018 at 18:39

3 Answers 3


Secure Boot is not about disallowing a physical attacker access to the system. It’s designed to prevent software from manipulating the boot process by checking the cryptographic integrity of the bootloader. Think Blue Pill.

Boot steps are responsible for verifying the next step code. Secure Boot itself is only concerned with the very first step.

A software attacker does not need to access UEFI setup or change anything about the boot configuration. They would just replace the UEFI executable that’s set to run. A password lock on UEFI setup does nothing about that.

Secure Boot on the other hand verifies the UEFI executable using cryptographic methods. It would detect this change and refuse to boot.

To ensure trusted boot and operating, all kernel-mode code must be signed. This is the case on 64-bit versions of Windows which also enforce signatures on device drivers.

Operating systems or the software they run are not secure. In most cases, it is impossible to achieve formally provable security. As such, attackers will always be able to achieve enough access to perform privileged operations such as replacing the bootloader.

  • 2
    That is actually a more pertinent way to put it. UEFI secures the software that will communicate with itself. (including things like option roms not just the bootloader). However I disagree its a blanket nothing to be done about physical attacks. It can certainly be part of a system that prevents that.
    – jdwolf
    Oct 21, 2018 at 15:42
  • 1
    You’re looking at the wrong attack vector. No operating system is secure. And they never will be. That’s why Secure Boot was made: To ensure software integrity.
    – Daniel B
    Oct 21, 2018 at 17:20
  • I believe you were responding to chzzh not myself correct?
    – jdwolf
    Oct 21, 2018 at 22:13
  • @jdwolf Yes, the other comments were deleted.
    – Daniel B
    Oct 22, 2018 at 4:32

UEFI specifies a way to store keys and how to use those keys to verify a digital signature as part of the EFI image loading process as well as authenticated UEFI variables that can be used by the OS.

It is entirely up the implementer to define how to allow a machine to be put into setup mode. That could be its set by the manufacture once and the user can never change it or it can be changed in the UEFI menu. In other cases the CMOS must be reset to reenter setup mode. Others require a password to enable secure boot. Other cases make entering setup mode part of an out of band management system.

How entering setup mode and reconfiguring secure boot is implemented is outside the scope of the specification.


If the OS isn't checking for the lock, then the lock is pointless.

What you should do, is have a OS that doesn't boot, unless it's all correct in the UEFI portion of the boot process.


You must log in to answer this question.