Bug 1759325 - please set CONFIG_EFI_TEST to "m"
Summary: please set CONFIG_EFI_TEST to "m"
Keywords:
Status: POST
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-07 20:36 UTC by Laszlo Ersek
Modified: 2019-10-10 14:54 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Laszlo Ersek 2019-10-07 20:36:50 UTC
Feature request: please apply

[PATCH] efi/efi_test: require CAP_SYS_ADMIN to open the chardev
http://mid.mail-archive.com/20191003100712.31045-1-javierm@redhat.com
https://www.spinics.net/lists/linux-efi/msg16593.html

to the Fedora kernel, and then please enable building the "efi_test" driver as a module.

Use case (excerpt from the patch linked above):

"""
Currently the GetVariable() UEFI runtime service is used (through the
efivar sysfs interface) to test that OVMF is able to enter into SMM.

But there's a proposal to add a UEFI variable cache outside of SMM, to
speedup GetVariable() calls. So the plan is to call QueryVariableInfo()
instead that's also read-only and sufficiently infrequently called that
is not planned to be cached anytime soon.

Building the efi_test module will allow us to call this EFI service by
using the fwts uefivarinfo test.
"""

fwts is packaged for Fedora, and it would rely on the "efi_test" driver -- but the kernel driver is currently unavailable.

CONFIG_EFI_TEST makes sense wherever EFI does ("depends on EFI"). i686, x86_64, and aarch64 seem relevant.

Also, it would be nice if the module were available for production kernels (not just for debug kernels). It's not expected that the module is going to be auto-loaded (it has no modalias).

Thanks!

Comment 1 Matthew Garrett 2019-10-07 21:03:20 UTC
I think allowing userland to pass arbitrary arguments to firmware calls is probably something that should be lockdown gated. I'll write a patch for upstream.

Comment 2 Javier Martinez Canillas 2019-10-08 07:33:06 UTC
(In reply to Matthew Garrett from comment #1)
> I think allowing userland to pass arbitrary arguments to firmware calls is
> probably something that should be lockdown gated. I'll write a patch for
> upstream.

I can post a v2 of that patch that also locks down the module besides requiring the CAP_SYS_ADMIN capability.

Comment 3 Javier Martinez Canillas 2019-10-08 10:57:54 UTC
I've posted a v2 of the patch that also locks down access to the chardev as suggested by Matthew:

https://lkml.org/lkml/2019/10/8/309


Note You need to log in before you can comment on or make changes to this bug.