xref: /openbmc/linux/drivers/firmware/efi/Kconfig (revision 8bdc2a19)
1# SPDX-License-Identifier: GPL-2.0-only
2menu "EFI (Extensible Firmware Interface) Support"
3	depends on EFI
4
5config EFI_VARS
6	tristate "EFI Variable Support via sysfs"
7	depends on EFI && (X86 || IA64)
8	default n
9	help
10	  If you say Y here, you are able to get EFI (Extensible Firmware
11	  Interface) variable information via sysfs.  You may read,
12	  write, create, and destroy EFI variables through this interface.
13	  Note that this driver is only retained for compatibility with
14	  legacy users: new users should use the efivarfs filesystem
15	  instead.
16
17config EFI_ESRT
18	bool
19	depends on EFI && !IA64
20	default y
21
22config EFI_VARS_PSTORE
23	tristate "Register efivars backend for pstore"
24	depends on PSTORE
25	default y
26	help
27	  Say Y here to enable use efivars as a backend to pstore. This
28	  will allow writing console messages, crash dumps, or anything
29	  else supported by pstore to EFI variables.
30
31config EFI_VARS_PSTORE_DEFAULT_DISABLE
32	bool "Disable using efivars as a pstore backend by default"
33	depends on EFI_VARS_PSTORE
34	default n
35	help
36	  Saying Y here will disable the use of efivars as a storage
37	  backend for pstore by default. This setting can be overridden
38	  using the efivars module's pstore_disable parameter.
39
40config EFI_RUNTIME_MAP
41	bool "Export efi runtime maps to sysfs"
42	depends on X86 && EFI && KEXEC_CORE
43	default y
44	help
45	  Export efi runtime memory maps to /sys/firmware/efi/runtime-map.
46	  That memory map is used for example by kexec to set up efi virtual
47	  mapping the 2nd kernel, but can also be used for debugging purposes.
48
49	  See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
50
51config EFI_FAKE_MEMMAP
52	bool "Enable EFI fake memory map"
53	depends on EFI && X86
54	default n
55	help
56	  Saying Y here will enable "efi_fake_mem" boot option.
57	  By specifying this parameter, you can add arbitrary attribute
58	  to specific memory range by updating original (firmware provided)
59	  EFI memmap.
60	  This is useful for debugging of EFI memmap related feature.
61	  e.g. Address Range Mirroring feature.
62
63config EFI_MAX_FAKE_MEM
64	int "maximum allowable number of ranges in efi_fake_mem boot option"
65	depends on EFI_FAKE_MEMMAP
66	range 1 128
67	default 8
68	help
69	  Maximum allowable number of ranges in efi_fake_mem boot option.
70	  Ranges can be set up to this value using comma-separated list.
71	  The default value is 8.
72
73config EFI_SOFT_RESERVE
74	bool "Reserve EFI Specific Purpose Memory"
75	depends on EFI && EFI_STUB && ACPI_HMAT
76	default ACPI_HMAT
77	help
78	  On systems that have mixed performance classes of memory EFI
79	  may indicate specific purpose memory with an attribute (See
80	  EFI_MEMORY_SP in UEFI 2.8). A memory range tagged with this
81	  attribute may have unique performance characteristics compared
82	  to the system's general purpose "System RAM" pool. On the
83	  expectation that such memory has application specific usage,
84	  and its base EFI memory type is "conventional" answer Y to
85	  arrange for the kernel to reserve it as a "Soft Reserved"
86	  resource, and set aside for direct-access (device-dax) by
87	  default. The memory range can later be optionally assigned to
88	  the page allocator by system administrator policy via the
89	  device-dax kmem facility. Say N to have the kernel treat this
90	  memory as "System RAM" by default.
91
92	  If unsure, say Y.
93
94config EFI_DXE_MEM_ATTRIBUTES
95	bool "Adjust memory attributes in EFISTUB"
96	depends on EFI && EFI_STUB && X86
97	default y
98	help
99	  UEFI specification does not guarantee all memory to be
100	  accessible for both write and execute as the kernel expects
101	  it to be.
102	  Use DXE services to check and alter memory protection
103	  attributes during boot via EFISTUB to ensure that memory
104	  ranges used by the kernel are writable and executable.
105
106config EFI_PARAMS_FROM_FDT
107	bool
108	help
109	  Select this config option from the architecture Kconfig if
110	  the EFI runtime support gets system table address, memory
111          map address, and other parameters from the device tree.
112
113config EFI_RUNTIME_WRAPPERS
114	bool
115
116config EFI_GENERIC_STUB
117	bool
118
119config EFI_ARMSTUB_DTB_LOADER
120	bool "Enable the DTB loader"
121	depends on EFI_GENERIC_STUB && !RISCV
122	default y
123	help
124	  Select this config option to add support for the dtb= command
125	  line parameter, allowing a device tree blob to be loaded into
126	  memory from the EFI System Partition by the stub.
127
128	  If the device tree is provided by the platform or by
129	  the bootloader this option may not be needed.
130	  But, for various development reasons and to maintain existing
131	  functionality for bootloaders that do not have such support
132	  this option is necessary.
133
134config EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
135	bool "Enable the command line initrd loader" if !X86
136	depends on EFI_STUB && (EFI_GENERIC_STUB || X86)
137	default y if X86
138	depends on !RISCV
139	help
140	  Select this config option to add support for the initrd= command
141	  line parameter, allowing an initrd that resides on the same volume
142	  as the kernel image to be loaded into memory.
143
144	  This method is deprecated.
145
146config EFI_BOOTLOADER_CONTROL
147	tristate "EFI Bootloader Control"
148	default n
149	help
150	  This module installs a reboot hook, such that if reboot() is
151	  invoked with a string argument NNN, "NNN" is copied to the
152	  "LoaderEntryOneShot" EFI variable, to be read by the
153	  bootloader. If the string matches one of the boot labels
154	  defined in its configuration, the bootloader will boot once
155	  to that label. The "LoaderEntryRebootReason" EFI variable is
156	  set with the reboot reason: "reboot" or "shutdown". The
157	  bootloader reads this reboot reason and takes particular
158	  action according to its policy.
159
160config EFI_CAPSULE_LOADER
161	tristate "EFI capsule loader"
162	depends on EFI && !IA64
163	help
164	  This option exposes a loader interface "/dev/efi_capsule_loader" for
165	  users to load EFI capsules. This driver requires working runtime
166	  capsule support in the firmware, which many OEMs do not provide.
167
168	  Most users should say N.
169
170config EFI_CAPSULE_QUIRK_QUARK_CSH
171	bool "Add support for Quark capsules with non-standard headers"
172	depends on X86 && !64BIT
173	select EFI_CAPSULE_LOADER
174	default y
175	help
176	  Add support for processing Quark X1000 EFI capsules, whose header
177	  layout deviates from the layout mandated by the UEFI specification.
178
179config EFI_TEST
180	tristate "EFI Runtime Service Tests Support"
181	depends on EFI
182	default n
183	help
184	  This driver uses the efi.<service> function pointers directly instead
185	  of going through the efivar API, because it is not trying to test the
186	  kernel subsystem, just for testing the UEFI runtime service
187	  interfaces which are provided by the firmware. This driver is used
188	  by the Firmware Test Suite (FWTS) for testing the UEFI runtime
189	  interfaces readiness of the firmware.
190	  Details for FWTS are available from:
191	  <https://wiki.ubuntu.com/FirmwareTestSuite>
192
193	  Say Y here to enable the runtime services support via /dev/efi_test.
194	  If unsure, say N.
195
196config APPLE_PROPERTIES
197	bool "Apple Device Properties"
198	depends on EFI_STUB && X86
199	select EFI_DEV_PATH_PARSER
200	select UCS2_STRING
201	help
202	  Retrieve properties from EFI on Apple Macs and assign them to
203	  devices, allowing for improved support of Apple hardware.
204	  Properties that would otherwise be missing include the
205	  Thunderbolt Device ROM and GPU configuration data.
206
207	  If unsure, say Y if you have a Mac.  Otherwise N.
208
209config RESET_ATTACK_MITIGATION
210	bool "Reset memory attack mitigation"
211	depends on EFI_STUB
212	help
213	  Request that the firmware clear the contents of RAM after a reboot
214	  using the TCG Platform Reset Attack Mitigation specification. This
215	  protects against an attacker forcibly rebooting the system while it
216	  still contains secrets in RAM, booting another OS and extracting the
217	  secrets. This should only be enabled when userland is configured to
218	  clear the MemoryOverwriteRequest flag on clean shutdown after secrets
219	  have been evicted, since otherwise it will trigger even on clean
220	  reboots.
221
222config EFI_RCI2_TABLE
223	bool "EFI Runtime Configuration Interface Table Version 2 Support"
224	depends on X86 || COMPILE_TEST
225	help
226	  Displays the content of the Runtime Configuration Interface
227	  Table version 2 on Dell EMC PowerEdge systems as a binary
228	  attribute 'rci2' under /sys/firmware/efi/tables directory.
229
230	  RCI2 table contains BIOS HII in XML format and is used to populate
231	  BIOS setup page in Dell EMC OpenManage Server Administrator tool.
232	  The BIOS setup page contains BIOS tokens which can be configured.
233
234	  Say Y here for Dell EMC PowerEdge systems.
235
236config EFI_DISABLE_PCI_DMA
237       bool "Clear Busmaster bit on PCI bridges during ExitBootServices()"
238       help
239	  Disable the busmaster bit in the control register on all PCI bridges
240	  while calling ExitBootServices() and passing control to the runtime
241	  kernel. System firmware may configure the IOMMU to prevent malicious
242	  PCI devices from being able to attack the OS via DMA. However, since
243	  firmware can't guarantee that the OS is IOMMU-aware, it will tear
244	  down IOMMU configuration when ExitBootServices() is called. This
245	  leaves a window between where a hostile device could still cause
246	  damage before Linux configures the IOMMU again.
247
248	  If you say Y here, the EFI stub will clear the busmaster bit on all
249	  PCI bridges before ExitBootServices() is called. This will prevent
250	  any malicious PCI devices from being able to perform DMA until the
251	  kernel reenables busmastering after configuring the IOMMU.
252
253	  This option will cause failures with some poorly behaved hardware
254	  and should not be enabled without testing. The kernel commandline
255	  options "efi=disable_early_pci_dma" or "efi=no_disable_early_pci_dma"
256	  may be used to override this option.
257
258endmenu
259
260config EFI_EMBEDDED_FIRMWARE
261	bool
262	depends on EFI
263	select CRYPTO_LIB_SHA256
264
265config UEFI_CPER
266	bool
267
268config UEFI_CPER_ARM
269	bool
270	depends on UEFI_CPER && ( ARM || ARM64 )
271	default y
272
273config UEFI_CPER_X86
274	bool
275	depends on UEFI_CPER && X86
276	default y
277
278config EFI_DEV_PATH_PARSER
279	bool
280	depends on ACPI
281	default n
282
283config EFI_EARLYCON
284	def_bool y
285	depends on EFI && SERIAL_EARLYCON && !ARM && !IA64
286	select FONT_SUPPORT
287	select ARCH_USE_MEMREMAP_PROT
288
289config EFI_CUSTOM_SSDT_OVERLAYS
290	bool "Load custom ACPI SSDT overlay from an EFI variable"
291	depends on EFI && ACPI
292	default ACPI_TABLE_UPGRADE
293	help
294	  Allow loading of an ACPI SSDT overlay from an EFI variable specified
295	  by a kernel command line option.
296
297	  See Documentation/admin-guide/acpi/ssdt-overlays.rst for more
298	  information.
299
300config EFI_DISABLE_RUNTIME
301	bool "Disable EFI runtime services support by default"
302	default y if PREEMPT_RT
303	help
304	  Allow to disable the EFI runtime services support by default. This can
305	  already be achieved by using the efi=noruntime option, but it could be
306	  useful to have this default without any kernel command line parameter.
307
308	  The EFI runtime services are disabled by default when PREEMPT_RT is
309	  enabled, because measurements have shown that some EFI functions calls
310	  might take too much time to complete, causing large latencies which is
311	  an issue for Real-Time kernels.
312
313	  This default can be overridden by using the efi=runtime option.
314
315config EFI_COCO_SECRET
316	bool "EFI Confidential Computing Secret Area Support"
317	depends on EFI
318	help
319	  Confidential Computing platforms (such as AMD SEV) allow the
320	  Guest Owner to securely inject secrets during guest VM launch.
321	  The secrets are placed in a designated EFI reserved memory area.
322
323	  In order to use the secrets in the kernel, the location of the secret
324	  area (as published in the EFI config table) must be kept.
325
326	  If you say Y here, the address of the EFI secret area will be kept
327	  for usage inside the kernel.  This will allow the
328	  virt/coco/efi_secret module to access the secrets, which in turn
329	  allows userspace programs to access the injected secrets.
330