Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <b075e45e-365a-dafb-503c-615c41168b0d@molgen.mpg.de> <706be699-7f79-391c-bbac-a4b3820511d8@molgen.mpg.de>
In-Reply-To: <706be699-7f79-391c-bbac-a4b3820511d8@molgen.mpg.de>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Wed, 12 May 2021 00:06:48 +0200
Message-ID: <CAMj1kXFoEU-ZA9=QunkBM+i1rOLnNnruo8OLF-aAjO3k8GFJtg@mail.gmail.com>
Subject: Re: efivarfs fails with `No such device` when EFI runtime is missing
To:     Paul Menzel <pmenzel@molgen.mpg.de>
Cc:     Matthew Garrett <matthew.garrett@nebula.com>,
        Jeremy Kerr <jk@ozlabs.org>,
        linux-efi <linux-efi@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, 11 May 2021 at 22:58, Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>
> [Use Ard=E2=80=99s 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=E2=80=99s Boot Manager with `efibootmgr`, I go=
t 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.