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]
Message-ID: <CAMj1kXFoEU-ZA9=QunkBM+i1rOLnNnruo8OLF-aAjO3k8GFJtg@mail.gmail.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ