| 48be1364 | 08-Dec-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efivarfs: Free s_fs_info on unmount
[ Upstream commit 547713d502f7b4b8efccd409cff84d731a23853b ]
Now that we allocate a s_fs_info struct on fs context creation, we
should ensure that we free it aga
efivarfs: Free s_fs_info on unmount
[ Upstream commit 547713d502f7b4b8efccd409cff84d731a23853b ]
Now that we allocate a s_fs_info struct on fs context creation, we
should ensure that we free it again when the superblock goes away.
Fixes: 5329aa5101f7 ("efivarfs: Add uid/gid mount options")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
| 301de9a2 | 19-Jan-2023 |
Johan Hovold <johan+linaro@kernel.org> |
efivarfs: always register filesystem
The efivar ops are typically registered at subsys init time so that
they are available when efivarfs is registered at module init time.
Other efivars implementa
efivarfs: always register filesystem
The efivar ops are typically registered at subsys init time so that
they are available when efivarfs is registered at module init time.
Other efivars implementations, such as Google SMI, exist and can
currently be built as modules which means that efivar may not be
available when efivarfs is initialised.
Move the efivar availability check from module init to when the
filesystem is mounted to allow late registration of efivars.
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
| 2d82e622 | 20-Jun-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: vars: Move efivar caching layer into efivarfs
Move the fiddly bits of the efivar layer into its only remaining user,
efivarfs, and confine its use to that particular module. All other uses
of t
efi: vars: Move efivar caching layer into efivarfs
Move the fiddly bits of the efivar layer into its only remaining user,
efivarfs, and confine its use to that particular module. All other uses
of the EFI variable store have no need for this additional layer of
complexity, given that they either only read variables, or read and
write variables into a separate GUIDed namespace, and cannot be used to
manipulate EFI variables that are covered by the EFI spec and/or affect
the boot flow.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
| 3a75f9f2 | 21-Jun-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: vars: Use locking version to iterate over efivars linked lists
Both efivars and efivarfs uses __efivar_entry_iter() to go over the
linked list that shadows the list of EFI variables held by the
efi: vars: Use locking version to iterate over efivars linked lists
Both efivars and efivarfs uses __efivar_entry_iter() to go over the
linked list that shadows the list of EFI variables held by the firmware,
but fail to call the begin/end helpers that are documented as a
prerequisite.
So switch to the proper version, which is efivar_entry_iter(). Given
that in both cases, efivar_entry_remove() is invoked with the lock held
already, don't take the lock there anymore.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
| ff04f3b6 | 25-Nov-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efivarfs: revert "fix memory leak in efivarfs_create()"
The memory leak addressed by commit fe5186cf12e3 is a false positive:
all allocations are recorded in a linked list, and freed when the
filesy
efivarfs: revert "fix memory leak in efivarfs_create()"
The memory leak addressed by commit fe5186cf12e3 is a false positive:
all allocations are recorded in a linked list, and freed when the
filesystem is unmounted. This leads to double frees, and as reported
by David, leads to crashes if SLUB is configured to self destruct when
double frees occur.
So drop the redundant kfree() again, and instead, mark the offending
pointer variable so the allocation is ignored by kmemleak.
Cc: Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@gmail.com>
Fixes: fe5186cf12e3 ("efivarfs: fix memory leak in efivarfs_create()")
Reported-by: David Laight <David.Laight@aculab.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
| f88814cc | 08-Jul-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/efivars: Expose RT service availability via efivars abstraction
Commit
bf67fad19e493b ("efi: Use more granular check for availability for variable services")
introduced a check into the efiv
efi/efivars: Expose RT service availability via efivars abstraction
Commit
bf67fad19e493b ("efi: Use more granular check for availability for variable services")
introduced a check into the efivarfs, efi-pstore and other drivers that
aborts loading of the module if not all three variable runtime services
(GetVariable, SetVariable and GetNextVariable) are supported. However, this
results in efivarfs being unavailable entirely if only SetVariable support
is missing, which is only needed if you want to make any modifications.
Also, efi-pstore and the sysfs EFI variable interface could be backed by
another implementation of the 'efivars' abstraction, in which case it is
completely irrelevant which services are supported by the EFI firmware.
So make the generic 'efivars' abstraction dependent on the availibility of
the GetVariable and GetNextVariable EFI runtime services, and add a helper
'efivar_supports_writes()' to find out whether the currently active efivars
abstraction supports writes (and wire it up to the availability of
SetVariable for the generic one).
Then, use the efivar_supports_writes() helper to decide whether to permit
efivarfs to be mounted read-write, and whether to enable efi-pstore or the
sysfs EFI variable interface altogether.
Fixes: bf67fad19e493b ("efi: Use more granular check for availability for variable services")
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|