How To Get UEFI Setting By Shell?

Home » CentOS » How To Get UEFI Setting By Shell?
CentOS 17 Comments

Hi,

CentOS7.1, Dell PowerEdge R730xd.

How to check/get UEFI information by shell/bash terminal ? example:if UEFI is enabled? if secure boot is enabled?

Thanks.

17 thoughts on - How To Get UEFI Setting By Shell?

  • Systems that boot via UEFI will have /sys/firmware/efi.

    You may have access to your secure boot setting in
    /sys/firmware/efi/efivars/, or in the output of “bootctl –path
    /boot/efi status”

  • Hi,
    another question.With secure boot on,
    I make a kernel module test.ko
    Then insmod test.ko:
    [root@localhost linux]# insmod test.ko
    insmod: ERROR: could not insert module test.ko: Required key not available

    How can I sign my test.ko for CentOS7.1?

    If I set secure boot off, insmod test.ko will be successful. w.k.

    —————— Original —————-

  • It works on linux, it can’t be secure?

    :)

    Eero
    22.1.2016 8.54 ip. “John R Pierce” kirjoitti:

  • if you can insert a custom Machine Owner Key into this keyring, then anyone with sufficient ingenuity can, too. which renders the whole signature thing moot, other than as another step to be cracked.

  • I’m not sure you understand mokutil. You do know that in order to enroll a key you must be physically present at the console before the kernel boots, right? In order to enroll a key, you must have admin access in the OS, and physical access to the hardware.

    Outside of an immutable key database, I think that’s nearly as secure as it’s possible to get.

  • in order to install a kernel module without signing, you still need root level access to the OS, so thats nothing new.

    Most all servers I run have remote KVM via IPMI, or are VM’s, so this can be done without physical presence, unless somehow mokutil disables KVM (keyboard/video/mouse, not kernel virtualization) AND refuses to run in a VM. Sure, if someone has penetrated my IPMI and/or virtualization management, I’m already in a world of hurt, but no physical presence is required.

  • Exactly. IPMI should be on a dedicated VLAN with a bastion host. No other systems should have access to it at all. The servers, especially, should not have access to their own IPMI network. Otherwise, you risk creating exactly that kind of hole, where tasks that are supposed to require console access don’t.

    Having said that, I have no idea whether or not the virtual console is locked during the secure boot path. Anybody who uses IPMI and secure boot?

  • You should find an early kernel message that secure boot is enabled. Just
    ‘dmesg | grep -i secure’

    You can also use ‘mokutil –sb-state’

    Chris Murphy

  • for that matter, what about a VM running on a service like Amazon AWS
    (or pick your virtual server environment) ? AWS provides a remote console, doesn’t it?

  • AWS doesn’t offer UEFI Secure Boot, so I’m not sure how that’s relevant.

    It seems like you’re reaching for criticisms of mokutil because you don’t like it, rather than because there is a demonstrable problem with it.

  • yeah, I just realized, duh, secureboot on a VM is not an issue at all, so never mind all that.

    I do think the whole secureboot thing is a bad idea on a general purpose computer system, seems like an attempt at creating product lock in and turning the x86 PC into an appliance, which it really isn’t.

  • mokutil is designed to address that concern, specifically. It ensures that you can add your own keys, so that you can run your own OS and modules, while retaining the security aspects of Secure Boot. So mocking mokutil seems very odd, don’t you think?

  • It is an issue. Hyper V gen 2 has supported UEFI with Secure Boot enabled by default for a few years.

    It’s precisely general purpose computers that are most susceptible to what Secure Boot prevents. What the alternative?

    Chris Murphy