Age | Commit message (Collapse) | Author |
|
commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741
Author: Ard Biesheuvel <ardb@kernel.org>
Date: Mon Jun 20 13:34:03 2022 +0200
efi: vars: Remove deprecated 'efivars' sysfs interface
Commit 5d9db883761a ("efi: Add support for a UEFI variable filesystem")
dated Oct 5, 2012, introduced a new efivarfs pseudo-filesystem to
replace the efivars sysfs interface that was used up to that point to
expose EFI variables to user space.
The main problem with the sysfs interface was that it only supported up
to 1024 bytes of payload per file, whereas the underlying variables
themselves are only bounded by a platform specific per-variable and
global limit that is typically much higher than 1024 bytes.
The deprecated sysfs interface is only enabled on x86 and Itanium, other
EFI enabled architectures only support the efivarfs pseudo-filesystem.
So let's finally rip off the band aid, and drop the old interface
entirely. This will make it easier to refactor and clean up the
underlying infrastructure that is shared between efivars, efivarfs and
efi-pstore, and is long overdue for a makeover.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Yann CARDAILLAC <ycnakajsph@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Linux kernel exposes EFI variables data to userspace via 2 interfaces:
- old sysfs-efivars interface (CONFIG_EFI_VARS), populated at /sys/firmware/efi/vars,
1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support
and not recommended anymore.
- new efivarfs interface (CONFIG_EFIVAR_FS), typically mounted like this:
mount -t efivarfs efivarfs /sys/firmware/efi/efivar
It was added in 3.8 intended as a replacement for the sysfs-efivars interface,
has no maximum per-variable size limitation and supports UEFI Secure Boot variables.
It also allows creating new vars easily, a very useful trick:
printf "\x07\x00\x00\x00\x00" > /sys/firmware/efi/efivar/myvar-12345678-1234-1234-1234-123456789abc
I find CONFIG_EFIVAR_FS very useful for EFI images and I'd like to have it
enabled by default. For example with gummiboot you can use the
LoaderEntryOneShot to tell it the entry identifier to select at the next
and only the next bootup, and I plan to use that in automated testing.
They both can co-exist - but they shouldn't both be
active / mounted (the problem isn't the mount point but data
inconsistency) so we enable them as modules and have the new one as the
default and the old one around for anyone that needs it.
Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
A number of bsps (intel-common, fri2, minnow) include the efi config.
Some boot loaders (such as gummiboot, recently added to OE-core)
require the kernel to be built with CONFIG_EFI_STUB.
I think it would be useful to have that enabled by default instead
of having to build your kernel with efi-ext added to KERNEL_FEATURES.
Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
This options enables linux kernel containing a built-in
EFI boot loader. Such a kind of linux kernel acts as
a EFI application and the built-in boot loader can boot
linux kernel through EFI shell commandline with proper
kernel commandline.
Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
|
|
Basic EFI support only requires CONFIG_EFI=y, this is sufficient for
some boards, and desirable for small configs. This is done with efi.scc.
Additional support for CONFIG_EFI_VARS, CONFIG_EFI_PARTITION, and CONFIG_FB_EFI
is provided via efi-ext.scc (extended) as this pulls in the block layer,
framebuffer support, and virtual terminals.
I'd like EFI_VARS to be part of the base config, but I have received
reports of it failing in some situations. Keeping it separate ensures
basic boot can work with the fragments as defined.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|