linux-kernel - Re: efivarfs fails with `No such device` when EFI runtime is missing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 12 May 2021 00:06:48 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Paul Menzel <pmenzel@...gen.mpg.de>
Cc:     Matthew Garrett <matthew.garrett@...ula.com>,
        Jeremy Kerr <jk@...abs.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: efivarfs fails with `No such device` when EFI runtime is missing

On Tue, 11 May 2021 at 22:58, Paul Menzel <pmenzel@...gen.mpg.de> wrote:
>
> [Use Ard’s current email, and add other maintainers]
>
> Am 11.05.21 um 22:55 schrieb Paul Menzel:
> > Dear Linux folks,
> >
> >
> > I migrated a 32-bit GNU/Linux installation from BIOS to EFI. Trying to
> > edit the entries in UEFI’s Boot Manager with `efibootmgr`, I got the error:
> >
> >     EFI variables are not supported on this system
> >
> > `sudo modprobe efivarfs` fails with
> >
> >     No such device
> >
> > After several tries, I found
> >
> >     [    0.000000] efi: No EFI runtime due to 32/64-bit mismatch with
> > kernel
> >
> > logged by Linux, and then I found the Stack Overflow thread *How could
> > 32bit kernel read efivars from 64bit UEFI?* [1].
> >
> > I would have thought, setting EFI variables is just directly writing to
> > some storage. But probably not.
> >
> > Could the error message for the efivarfs load failure be improved, that
> > *device* means the runtime service (if I am not mistaken)?
> >

Not sure what you are asking for here. The efivarfs module fails with
-ENODEV if EFI runtime services are not supported by the kernel (for
whatever reason), and it is actually modprobe in user space that
prints glibc's default error string for ENODEV.

What we could do is print something to the kernel log when this
situation occurs, in addition to the current behavior of modprobe,
which is difficult to change.

Patches welcome.