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 ...
|