]>
Commit | Line | Data |
---|---|---|
1 | # SPDX-License-Identifier: GPL-2.0 | |
2 | # | |
3 | # General architecture dependent options | |
4 | # | |
5 | ||
6 | # | |
7 | # Note: arch/$(SRCARCH)/Kconfig needs to be included first so that it can | |
8 | # override the default values in this file. | |
9 | # | |
10 | source "arch/$(SRCARCH)/Kconfig" | |
11 | ||
12 | config ARCH_CONFIGURES_CPU_MITIGATIONS | |
13 | bool | |
14 | ||
15 | if !ARCH_CONFIGURES_CPU_MITIGATIONS | |
16 | config CPU_MITIGATIONS | |
17 | def_bool y | |
18 | endif | |
19 | ||
20 | menu "General architecture-dependent options" | |
21 | ||
22 | config ARCH_HAS_SUBPAGE_FAULTS | |
23 | bool | |
24 | help | |
25 | Select if the architecture can check permissions at sub-page | |
26 | granularity (e.g. arm64 MTE). The probe_user_*() functions | |
27 | must be implemented. | |
28 | ||
29 | config HOTPLUG_SMT | |
30 | bool | |
31 | ||
32 | config SMT_NUM_THREADS_DYNAMIC | |
33 | bool | |
34 | ||
35 | # Selected by HOTPLUG_CORE_SYNC_DEAD or HOTPLUG_CORE_SYNC_FULL | |
36 | config HOTPLUG_CORE_SYNC | |
37 | bool | |
38 | ||
39 | # Basic CPU dead synchronization selected by architecture | |
40 | config HOTPLUG_CORE_SYNC_DEAD | |
41 | bool | |
42 | select HOTPLUG_CORE_SYNC | |
43 | ||
44 | # Full CPU synchronization with alive state selected by architecture | |
45 | config HOTPLUG_CORE_SYNC_FULL | |
46 | bool | |
47 | select HOTPLUG_CORE_SYNC_DEAD if HOTPLUG_CPU | |
48 | select HOTPLUG_CORE_SYNC | |
49 | ||
50 | config HOTPLUG_SPLIT_STARTUP | |
51 | bool | |
52 | select HOTPLUG_CORE_SYNC_FULL | |
53 | ||
54 | config HOTPLUG_PARALLEL | |
55 | bool | |
56 | select HOTPLUG_SPLIT_STARTUP | |
57 | ||
58 | config GENERIC_ENTRY | |
59 | bool | |
60 | ||
61 | config KPROBES | |
62 | bool "Kprobes" | |
63 | depends on HAVE_KPROBES | |
64 | select KALLSYMS | |
65 | select EXECMEM | |
66 | select NEED_TASKS_RCU | |
67 | help | |
68 | Kprobes allows you to trap at almost any kernel address and | |
69 | execute a callback function. register_kprobe() establishes | |
70 | a probepoint and specifies the callback. Kprobes is useful | |
71 | for kernel debugging, non-intrusive instrumentation and testing. | |
72 | If in doubt, say "N". | |
73 | ||
74 | config JUMP_LABEL | |
75 | bool "Optimize very unlikely/likely branches" | |
76 | depends on HAVE_ARCH_JUMP_LABEL | |
77 | select OBJTOOL if HAVE_JUMP_LABEL_HACK | |
78 | help | |
79 | This option enables a transparent branch optimization that | |
80 | makes certain almost-always-true or almost-always-false branch | |
81 | conditions even cheaper to execute within the kernel. | |
82 | ||
83 | Certain performance-sensitive kernel code, such as trace points, | |
84 | scheduler functionality, networking code and KVM have such | |
85 | branches and include support for this optimization technique. | |
86 | ||
87 | If it is detected that the compiler has support for "asm goto", | |
88 | the kernel will compile such branches with just a nop | |
89 | instruction. When the condition flag is toggled to true, the | |
90 | nop will be converted to a jump instruction to execute the | |
91 | conditional block of instructions. | |
92 | ||
93 | This technique lowers overhead and stress on the branch prediction | |
94 | of the processor and generally makes the kernel faster. The update | |
95 | of the condition is slower, but those are always very rare. | |
96 | ||
97 | ( On 32-bit x86, the necessary options added to the compiler | |
98 | flags may increase the size of the kernel slightly. ) | |
99 | ||
100 | config STATIC_KEYS_SELFTEST | |
101 | bool "Static key selftest" | |
102 | depends on JUMP_LABEL | |
103 | help | |
104 | Boot time self-test of the branch patching code. | |
105 | ||
106 | config STATIC_CALL_SELFTEST | |
107 | bool "Static call selftest" | |
108 | depends on HAVE_STATIC_CALL | |
109 | help | |
110 | Boot time self-test of the call patching code. | |
111 | ||
112 | config OPTPROBES | |
113 | def_bool y | |
114 | depends on KPROBES && HAVE_OPTPROBES | |
115 | select NEED_TASKS_RCU | |
116 | ||
117 | config KPROBES_ON_FTRACE | |
118 | def_bool y | |
119 | depends on KPROBES && HAVE_KPROBES_ON_FTRACE | |
120 | depends on DYNAMIC_FTRACE_WITH_REGS | |
121 | help | |
122 | If function tracer is enabled and the arch supports full | |
123 | passing of pt_regs to function tracing, then kprobes can | |
124 | optimize on top of function tracing. | |
125 | ||
126 | config UPROBES | |
127 | def_bool n | |
128 | depends on ARCH_SUPPORTS_UPROBES | |
129 | help | |
130 | Uprobes is the user-space counterpart to kprobes: they | |
131 | enable instrumentation applications (such as 'perf probe') | |
132 | to establish unintrusive probes in user-space binaries and | |
133 | libraries, by executing handler functions when the probes | |
134 | are hit by user-space applications. | |
135 | ||
136 | ( These probes come in the form of single-byte breakpoints, | |
137 | managed by the kernel and kept transparent to the probed | |
138 | application. ) | |
139 | ||
140 | config HAVE_64BIT_ALIGNED_ACCESS | |
141 | def_bool 64BIT && !HAVE_EFFICIENT_UNALIGNED_ACCESS | |
142 | help | |
143 | Some architectures require 64 bit accesses to be 64 bit | |
144 | aligned, which also requires structs containing 64 bit values | |
145 | to be 64 bit aligned too. This includes some 32 bit | |
146 | architectures which can do 64 bit accesses, as well as 64 bit | |
147 | architectures without unaligned access. | |
148 | ||
149 | This symbol should be selected by an architecture if 64 bit | |
150 | accesses are required to be 64 bit aligned in this way even | |
151 | though it is not a 64 bit architecture. | |
152 | ||
153 | See Documentation/core-api/unaligned-memory-access.rst for | |
154 | more information on the topic of unaligned memory accesses. | |
155 | ||
156 | config HAVE_EFFICIENT_UNALIGNED_ACCESS | |
157 | bool | |
158 | help | |
159 | Some architectures are unable to perform unaligned accesses | |
160 | without the use of get_unaligned/put_unaligned. Others are | |
161 | unable to perform such accesses efficiently (e.g. trap on | |
162 | unaligned access and require fixing it up in the exception | |
163 | handler.) | |
164 | ||
165 | This symbol should be selected by an architecture if it can | |
166 | perform unaligned accesses efficiently to allow different | |
167 | code paths to be selected for these cases. Some network | |
168 | drivers, for example, could opt to not fix up alignment | |
169 | problems with received packets if doing so would not help | |
170 | much. | |
171 | ||
172 | See Documentation/core-api/unaligned-memory-access.rst for more | |
173 | information on the topic of unaligned memory accesses. | |
174 | ||
175 | config ARCH_USE_BUILTIN_BSWAP | |
176 | bool | |
177 | help | |
178 | Modern versions of GCC (since 4.4) have builtin functions | |
179 | for handling byte-swapping. Using these, instead of the old | |
180 | inline assembler that the architecture code provides in the | |
181 | __arch_bswapXX() macros, allows the compiler to see what's | |
182 | happening and offers more opportunity for optimisation. In | |
183 | particular, the compiler will be able to combine the byteswap | |
184 | with a nearby load or store and use load-and-swap or | |
185 | store-and-swap instructions if the architecture has them. It | |
186 | should almost *never* result in code which is worse than the | |
187 | hand-coded assembler in <asm/swab.h>. But just in case it | |
188 | does, the use of the builtins is optional. | |
189 | ||
190 | Any architecture with load-and-swap or store-and-swap | |
191 | instructions should set this. And it shouldn't hurt to set it | |
192 | on architectures that don't have such instructions. | |
193 | ||
194 | config KRETPROBES | |
195 | def_bool y | |
196 | depends on KPROBES && (HAVE_KRETPROBES || HAVE_RETHOOK) | |
197 | ||
198 | config KRETPROBE_ON_RETHOOK | |
199 | def_bool y | |
200 | depends on HAVE_RETHOOK | |
201 | depends on KRETPROBES | |
202 | select RETHOOK | |
203 | ||
204 | config USER_RETURN_NOTIFIER | |
205 | bool | |
206 | depends on HAVE_USER_RETURN_NOTIFIER | |
207 | help | |
208 | Provide a kernel-internal notification when a cpu is about to | |
209 | switch to user mode. | |
210 | ||
211 | config HAVE_IOREMAP_PROT | |
212 | bool | |
213 | ||
214 | config HAVE_KPROBES | |
215 | bool | |
216 | ||
217 | config HAVE_KRETPROBES | |
218 | bool | |
219 | ||
220 | config HAVE_OPTPROBES | |
221 | bool | |
222 | ||
223 | config HAVE_KPROBES_ON_FTRACE | |
224 | bool | |
225 | ||
226 | config ARCH_CORRECT_STACKTRACE_ON_KRETPROBE | |
227 | bool | |
228 | help | |
229 | Since kretprobes modifies return address on the stack, the | |
230 | stacktrace may see the kretprobe trampoline address instead | |
231 | of correct one. If the architecture stacktrace code and | |
232 | unwinder can adjust such entries, select this configuration. | |
233 | ||
234 | config HAVE_FUNCTION_ERROR_INJECTION | |
235 | bool | |
236 | ||
237 | config HAVE_NMI | |
238 | bool | |
239 | ||
240 | config HAVE_FUNCTION_DESCRIPTORS | |
241 | bool | |
242 | ||
243 | config TRACE_IRQFLAGS_SUPPORT | |
244 | bool | |
245 | ||
246 | config TRACE_IRQFLAGS_NMI_SUPPORT | |
247 | bool | |
248 | ||
249 | # | |
250 | # An arch should select this if it provides all these things: | |
251 | # | |
252 | # task_pt_regs() in asm/processor.h or asm/ptrace.h | |
253 | # arch_has_single_step() if there is hardware single-step support | |
254 | # arch_has_block_step() if there is hardware block-step support | |
255 | # asm/syscall.h supplying asm-generic/syscall.h interface | |
256 | # linux/regset.h user_regset interfaces | |
257 | # CORE_DUMP_USE_REGSET #define'd in linux/elf.h | |
258 | # TIF_SYSCALL_TRACE calls ptrace_report_syscall_{entry,exit} | |
259 | # TIF_NOTIFY_RESUME calls resume_user_mode_work() | |
260 | # | |
261 | config HAVE_ARCH_TRACEHOOK | |
262 | bool | |
263 | ||
264 | config HAVE_DMA_CONTIGUOUS | |
265 | bool | |
266 | ||
267 | config GENERIC_SMP_IDLE_THREAD | |
268 | bool | |
269 | ||
270 | config GENERIC_IDLE_POLL_SETUP | |
271 | bool | |
272 | ||
273 | config ARCH_HAS_FORTIFY_SOURCE | |
274 | bool | |
275 | help | |
276 | An architecture should select this when it can successfully | |
277 | build and run with CONFIG_FORTIFY_SOURCE. | |
278 | ||
279 | # | |
280 | # Select if the arch provides a historic keepinit alias for the retain_initrd | |
281 | # command line option | |
282 | # | |
283 | config ARCH_HAS_KEEPINITRD | |
284 | bool | |
285 | ||
286 | # Select if arch has all set_memory_ro/rw/x/nx() functions in asm/cacheflush.h | |
287 | config ARCH_HAS_SET_MEMORY | |
288 | bool | |
289 | ||
290 | # Select if arch has all set_direct_map_invalid/default() functions | |
291 | config ARCH_HAS_SET_DIRECT_MAP | |
292 | bool | |
293 | ||
294 | # | |
295 | # Select if the architecture provides the arch_dma_set_uncached symbol to | |
296 | # either provide an uncached segment alias for a DMA allocation, or | |
297 | # to remap the page tables in place. | |
298 | # | |
299 | config ARCH_HAS_DMA_SET_UNCACHED | |
300 | bool | |
301 | ||
302 | # | |
303 | # Select if the architectures provides the arch_dma_clear_uncached symbol | |
304 | # to undo an in-place page table remap for uncached access. | |
305 | # | |
306 | config ARCH_HAS_DMA_CLEAR_UNCACHED | |
307 | bool | |
308 | ||
309 | config ARCH_HAS_CPU_FINALIZE_INIT | |
310 | bool | |
311 | ||
312 | # The architecture has a per-task state that includes the mm's PASID | |
313 | config ARCH_HAS_CPU_PASID | |
314 | bool | |
315 | select IOMMU_MM_DATA | |
316 | ||
317 | config HAVE_ARCH_THREAD_STRUCT_WHITELIST | |
318 | bool | |
319 | help | |
320 | An architecture should select this to provide hardened usercopy | |
321 | knowledge about what region of the thread_struct should be | |
322 | whitelisted for copying to userspace. Normally this is only the | |
323 | FPU registers. Specifically, arch_thread_struct_whitelist() | |
324 | should be implemented. Without this, the entire thread_struct | |
325 | field in task_struct will be left whitelisted. | |
326 | ||
327 | # Select if arch wants to size task_struct dynamically via arch_task_struct_size: | |
328 | config ARCH_WANTS_DYNAMIC_TASK_STRUCT | |
329 | bool | |
330 | ||
331 | config ARCH_WANTS_NO_INSTR | |
332 | bool | |
333 | help | |
334 | An architecture should select this if the noinstr macro is being used on | |
335 | functions to denote that the toolchain should avoid instrumenting such | |
336 | functions and is required for correctness. | |
337 | ||
338 | config ARCH_32BIT_OFF_T | |
339 | bool | |
340 | depends on !64BIT | |
341 | help | |
342 | All new 32-bit architectures should have 64-bit off_t type on | |
343 | userspace side which corresponds to the loff_t kernel type. This | |
344 | is the requirement for modern ABIs. Some existing architectures | |
345 | still support 32-bit off_t. This option is enabled for all such | |
346 | architectures explicitly. | |
347 | ||
348 | # Selected by 64 bit architectures which have a 32 bit f_tinode in struct ustat | |
349 | config ARCH_32BIT_USTAT_F_TINODE | |
350 | bool | |
351 | ||
352 | config HAVE_ASM_MODVERSIONS | |
353 | bool | |
354 | help | |
355 | This symbol should be selected by an architecture if it provides | |
356 | <asm/asm-prototypes.h> to support the module versioning for symbols | |
357 | exported from assembly code. | |
358 | ||
359 | config HAVE_REGS_AND_STACK_ACCESS_API | |
360 | bool | |
361 | help | |
362 | This symbol should be selected by an architecture if it supports | |
363 | the API needed to access registers and stack entries from pt_regs, | |
364 | declared in asm/ptrace.h | |
365 | For example the kprobes-based event tracer needs this API. | |
366 | ||
367 | config HAVE_RSEQ | |
368 | bool | |
369 | depends on HAVE_REGS_AND_STACK_ACCESS_API | |
370 | help | |
371 | This symbol should be selected by an architecture if it | |
372 | supports an implementation of restartable sequences. | |
373 | ||
374 | config HAVE_RUST | |
375 | bool | |
376 | help | |
377 | This symbol should be selected by an architecture if it | |
378 | supports Rust. | |
379 | ||
380 | config HAVE_FUNCTION_ARG_ACCESS_API | |
381 | bool | |
382 | help | |
383 | This symbol should be selected by an architecture if it supports | |
384 | the API needed to access function arguments from pt_regs, | |
385 | declared in asm/ptrace.h | |
386 | ||
387 | config HAVE_HW_BREAKPOINT | |
388 | bool | |
389 | depends on PERF_EVENTS | |
390 | ||
391 | config HAVE_MIXED_BREAKPOINTS_REGS | |
392 | bool | |
393 | depends on HAVE_HW_BREAKPOINT | |
394 | help | |
395 | Depending on the arch implementation of hardware breakpoints, | |
396 | some of them have separate registers for data and instruction | |
397 | breakpoints addresses, others have mixed registers to store | |
398 | them but define the access type in a control register. | |
399 | Select this option if your arch implements breakpoints under the | |
400 | latter fashion. | |
401 | ||
402 | config HAVE_USER_RETURN_NOTIFIER | |
403 | bool | |
404 | ||
405 | config HAVE_PERF_EVENTS_NMI | |
406 | bool | |
407 | help | |
408 | System hardware can generate an NMI using the perf event | |
409 | subsystem. Also has support for calculating CPU cycle events | |
410 | to determine how many clock cycles in a given period. | |
411 | ||
412 | config HAVE_HARDLOCKUP_DETECTOR_PERF | |
413 | bool | |
414 | depends on HAVE_PERF_EVENTS_NMI | |
415 | help | |
416 | The arch chooses to use the generic perf-NMI-based hardlockup | |
417 | detector. Must define HAVE_PERF_EVENTS_NMI. | |
418 | ||
419 | config HAVE_HARDLOCKUP_DETECTOR_ARCH | |
420 | bool | |
421 | help | |
422 | The arch provides its own hardlockup detector implementation instead | |
423 | of the generic ones. | |
424 | ||
425 | It uses the same command line parameters, and sysctl interface, | |
426 | as the generic hardlockup detectors. | |
427 | ||
428 | config HAVE_PERF_REGS | |
429 | bool | |
430 | help | |
431 | Support selective register dumps for perf events. This includes | |
432 | bit-mapping of each registers and a unique architecture id. | |
433 | ||
434 | config HAVE_PERF_USER_STACK_DUMP | |
435 | bool | |
436 | help | |
437 | Support user stack dumps for perf event samples. This needs | |
438 | access to the user stack pointer which is not unified across | |
439 | architectures. | |
440 | ||
441 | config HAVE_ARCH_JUMP_LABEL | |
442 | bool | |
443 | ||
444 | config HAVE_ARCH_JUMP_LABEL_RELATIVE | |
445 | bool | |
446 | ||
447 | config MMU_GATHER_TABLE_FREE | |
448 | bool | |
449 | ||
450 | config MMU_GATHER_RCU_TABLE_FREE | |
451 | bool | |
452 | select MMU_GATHER_TABLE_FREE | |
453 | ||
454 | config MMU_GATHER_PAGE_SIZE | |
455 | bool | |
456 | ||
457 | config MMU_GATHER_NO_RANGE | |
458 | bool | |
459 | select MMU_GATHER_MERGE_VMAS | |
460 | ||
461 | config MMU_GATHER_NO_FLUSH_CACHE | |
462 | bool | |
463 | ||
464 | config MMU_GATHER_MERGE_VMAS | |
465 | bool | |
466 | ||
467 | config MMU_GATHER_NO_GATHER | |
468 | bool | |
469 | depends on MMU_GATHER_TABLE_FREE | |
470 | ||
471 | config ARCH_WANT_IRQS_OFF_ACTIVATE_MM | |
472 | bool | |
473 | help | |
474 | Temporary select until all architectures can be converted to have | |
475 | irqs disabled over activate_mm. Architectures that do IPI based TLB | |
476 | shootdowns should enable this. | |
477 | ||
478 | # Use normal mm refcounting for MMU_LAZY_TLB kernel thread references. | |
479 | # MMU_LAZY_TLB_REFCOUNT=n can improve the scalability of context switching | |
480 | # to/from kernel threads when the same mm is running on a lot of CPUs (a large | |
481 | # multi-threaded application), by reducing contention on the mm refcount. | |
482 | # | |
483 | # This can be disabled if the architecture ensures no CPUs are using an mm as a | |
484 | # "lazy tlb" beyond its final refcount (i.e., by the time __mmdrop frees the mm | |
485 | # or its kernel page tables). This could be arranged by arch_exit_mmap(), or | |
486 | # final exit(2) TLB flush, for example. | |
487 | # | |
488 | # To implement this, an arch *must*: | |
489 | # Ensure the _lazy_tlb variants of mmgrab/mmdrop are used when manipulating | |
490 | # the lazy tlb reference of a kthread's ->active_mm (non-arch code has been | |
491 | # converted already). | |
492 | config MMU_LAZY_TLB_REFCOUNT | |
493 | def_bool y | |
494 | depends on !MMU_LAZY_TLB_SHOOTDOWN | |
495 | ||
496 | # This option allows MMU_LAZY_TLB_REFCOUNT=n. It ensures no CPUs are using an | |
497 | # mm as a lazy tlb beyond its last reference count, by shooting down these | |
498 | # users before the mm is deallocated. __mmdrop() first IPIs all CPUs that may | |
499 | # be using the mm as a lazy tlb, so that they may switch themselves to using | |
500 | # init_mm for their active mm. mm_cpumask(mm) is used to determine which CPUs | |
501 | # may be using mm as a lazy tlb mm. | |
502 | # | |
503 | # To implement this, an arch *must*: | |
504 | # - At the time of the final mmdrop of the mm, ensure mm_cpumask(mm) contains | |
505 | # at least all possible CPUs in which the mm is lazy. | |
506 | # - It must meet the requirements for MMU_LAZY_TLB_REFCOUNT=n (see above). | |
507 | config MMU_LAZY_TLB_SHOOTDOWN | |
508 | bool | |
509 | ||
510 | config ARCH_HAVE_NMI_SAFE_CMPXCHG | |
511 | bool | |
512 | ||
513 | config ARCH_HAVE_EXTRA_ELF_NOTES | |
514 | bool | |
515 | help | |
516 | An architecture should select this in order to enable adding an | |
517 | arch-specific ELF note section to core files. It must provide two | |
518 | functions: elf_coredump_extra_notes_size() and | |
519 | elf_coredump_extra_notes_write() which are invoked by the ELF core | |
520 | dumper. | |
521 | ||
522 | config ARCH_HAS_NMI_SAFE_THIS_CPU_OPS | |
523 | bool | |
524 | ||
525 | config HAVE_ALIGNED_STRUCT_PAGE | |
526 | bool | |
527 | help | |
528 | This makes sure that struct pages are double word aligned and that | |
529 | e.g. the SLUB allocator can perform double word atomic operations | |
530 | on a struct page for better performance. However selecting this | |
531 | might increase the size of a struct page by a word. | |
532 | ||
533 | config HAVE_CMPXCHG_LOCAL | |
534 | bool | |
535 | ||
536 | config HAVE_CMPXCHG_DOUBLE | |
537 | bool | |
538 | ||
539 | config ARCH_WEAK_RELEASE_ACQUIRE | |
540 | bool | |
541 | ||
542 | config ARCH_WANT_IPC_PARSE_VERSION | |
543 | bool | |
544 | ||
545 | config ARCH_WANT_COMPAT_IPC_PARSE_VERSION | |
546 | bool | |
547 | ||
548 | config ARCH_WANT_OLD_COMPAT_IPC | |
549 | select ARCH_WANT_COMPAT_IPC_PARSE_VERSION | |
550 | bool | |
551 | ||
552 | config HAVE_ARCH_SECCOMP | |
553 | bool | |
554 | help | |
555 | An arch should select this symbol to support seccomp mode 1 (the fixed | |
556 | syscall policy), and must provide an overrides for __NR_seccomp_sigreturn, | |
557 | and compat syscalls if the asm-generic/seccomp.h defaults need adjustment: | |
558 | - __NR_seccomp_read_32 | |
559 | - __NR_seccomp_write_32 | |
560 | - __NR_seccomp_exit_32 | |
561 | - __NR_seccomp_sigreturn_32 | |
562 | ||
563 | config HAVE_ARCH_SECCOMP_FILTER | |
564 | bool | |
565 | select HAVE_ARCH_SECCOMP | |
566 | help | |
567 | An arch should select this symbol if it provides all of these things: | |
568 | - all the requirements for HAVE_ARCH_SECCOMP | |
569 | - syscall_get_arch() | |
570 | - syscall_get_arguments() | |
571 | - syscall_rollback() | |
572 | - syscall_set_return_value() | |
573 | - SIGSYS siginfo_t support | |
574 | - secure_computing is called from a ptrace_event()-safe context | |
575 | - secure_computing return value is checked and a return value of -1 | |
576 | results in the system call being skipped immediately. | |
577 | - seccomp syscall wired up | |
578 | - if !HAVE_SPARSE_SYSCALL_NR, have SECCOMP_ARCH_NATIVE, | |
579 | SECCOMP_ARCH_NATIVE_NR, SECCOMP_ARCH_NATIVE_NAME defined. If | |
580 | COMPAT is supported, have the SECCOMP_ARCH_COMPAT* defines too. | |
581 | ||
582 | config SECCOMP | |
583 | prompt "Enable seccomp to safely execute untrusted bytecode" | |
584 | def_bool y | |
585 | depends on HAVE_ARCH_SECCOMP | |
586 | help | |
587 | This kernel feature is useful for number crunching applications | |
588 | that may need to handle untrusted bytecode during their | |
589 | execution. By using pipes or other transports made available | |
590 | to the process as file descriptors supporting the read/write | |
591 | syscalls, it's possible to isolate those applications in their | |
592 | own address space using seccomp. Once seccomp is enabled via | |
593 | prctl(PR_SET_SECCOMP) or the seccomp() syscall, it cannot be | |
594 | disabled and the task is only allowed to execute a few safe | |
595 | syscalls defined by each seccomp mode. | |
596 | ||
597 | If unsure, say Y. | |
598 | ||
599 | config SECCOMP_FILTER | |
600 | def_bool y | |
601 | depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET | |
602 | help | |
603 | Enable tasks to build secure computing environments defined | |
604 | in terms of Berkeley Packet Filter programs which implement | |
605 | task-defined system call filtering polices. | |
606 | ||
607 | See Documentation/userspace-api/seccomp_filter.rst for details. | |
608 | ||
609 | config SECCOMP_CACHE_DEBUG | |
610 | bool "Show seccomp filter cache status in /proc/pid/seccomp_cache" | |
611 | depends on SECCOMP_FILTER && !HAVE_SPARSE_SYSCALL_NR | |
612 | depends on PROC_FS | |
613 | help | |
614 | This enables the /proc/pid/seccomp_cache interface to monitor | |
615 | seccomp cache data. The file format is subject to change. Reading | |
616 | the file requires CAP_SYS_ADMIN. | |
617 | ||
618 | This option is for debugging only. Enabling presents the risk that | |
619 | an adversary may be able to infer the seccomp filter logic. | |
620 | ||
621 | If unsure, say N. | |
622 | ||
623 | config HAVE_ARCH_STACKLEAK | |
624 | bool | |
625 | help | |
626 | An architecture should select this if it has the code which | |
627 | fills the used part of the kernel stack with the STACKLEAK_POISON | |
628 | value before returning from system calls. | |
629 | ||
630 | config HAVE_STACKPROTECTOR | |
631 | bool | |
632 | help | |
633 | An arch should select this symbol if: | |
634 | - it has implemented a stack canary (e.g. __stack_chk_guard) | |
635 | ||
636 | config STACKPROTECTOR | |
637 | bool "Stack Protector buffer overflow detection" | |
638 | depends on HAVE_STACKPROTECTOR | |
639 | depends on $(cc-option,-fstack-protector) | |
640 | default y | |
641 | help | |
642 | This option turns on the "stack-protector" GCC feature. This | |
643 | feature puts, at the beginning of functions, a canary value on | |
644 | the stack just before the return address, and validates | |
645 | the value just before actually returning. Stack based buffer | |
646 | overflows (that need to overwrite this return address) now also | |
647 | overwrite the canary, which gets detected and the attack is then | |
648 | neutralized via a kernel panic. | |
649 | ||
650 | Functions will have the stack-protector canary logic added if they | |
651 | have an 8-byte or larger character array on the stack. | |
652 | ||
653 | This feature requires gcc version 4.2 or above, or a distribution | |
654 | gcc with the feature backported ("-fstack-protector"). | |
655 | ||
656 | On an x86 "defconfig" build, this feature adds canary checks to | |
657 | about 3% of all kernel functions, which increases kernel code size | |
658 | by about 0.3%. | |
659 | ||
660 | config STACKPROTECTOR_STRONG | |
661 | bool "Strong Stack Protector" | |
662 | depends on STACKPROTECTOR | |
663 | depends on $(cc-option,-fstack-protector-strong) | |
664 | default y | |
665 | help | |
666 | Functions will have the stack-protector canary logic added in any | |
667 | of the following conditions: | |
668 | ||
669 | - local variable's address used as part of the right hand side of an | |
670 | assignment or function argument | |
671 | - local variable is an array (or union containing an array), | |
672 | regardless of array type or length | |
673 | - uses register local variables | |
674 | ||
675 | This feature requires gcc version 4.9 or above, or a distribution | |
676 | gcc with the feature backported ("-fstack-protector-strong"). | |
677 | ||
678 | On an x86 "defconfig" build, this feature adds canary checks to | |
679 | about 20% of all kernel functions, which increases the kernel code | |
680 | size by about 2%. | |
681 | ||
682 | config ARCH_SUPPORTS_SHADOW_CALL_STACK | |
683 | bool | |
684 | help | |
685 | An architecture should select this if it supports the compiler's | |
686 | Shadow Call Stack and implements runtime support for shadow stack | |
687 | switching. | |
688 | ||
689 | config SHADOW_CALL_STACK | |
690 | bool "Shadow Call Stack" | |
691 | depends on ARCH_SUPPORTS_SHADOW_CALL_STACK | |
692 | depends on DYNAMIC_FTRACE_WITH_ARGS || DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER | |
693 | depends on MMU | |
694 | help | |
695 | This option enables the compiler's Shadow Call Stack, which | |
696 | uses a shadow stack to protect function return addresses from | |
697 | being overwritten by an attacker. More information can be found | |
698 | in the compiler's documentation: | |
699 | ||
700 | - Clang: https://clang.llvm.org/docs/ShadowCallStack.html | |
701 | - GCC: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#Instrumentation-Options | |
702 | ||
703 | Note that security guarantees in the kernel differ from the | |
704 | ones documented for user space. The kernel must store addresses | |
705 | of shadow stacks in memory, which means an attacker capable of | |
706 | reading and writing arbitrary memory may be able to locate them | |
707 | and hijack control flow by modifying the stacks. | |
708 | ||
709 | config DYNAMIC_SCS | |
710 | bool | |
711 | help | |
712 | Set by the arch code if it relies on code patching to insert the | |
713 | shadow call stack push and pop instructions rather than on the | |
714 | compiler. | |
715 | ||
716 | config LTO | |
717 | bool | |
718 | help | |
719 | Selected if the kernel will be built using the compiler's LTO feature. | |
720 | ||
721 | config LTO_CLANG | |
722 | bool | |
723 | select LTO | |
724 | help | |
725 | Selected if the kernel will be built using Clang's LTO feature. | |
726 | ||
727 | config ARCH_SUPPORTS_LTO_CLANG | |
728 | bool | |
729 | help | |
730 | An architecture should select this option if it supports: | |
731 | - compiling with Clang, | |
732 | - compiling inline assembly with Clang's integrated assembler, | |
733 | - and linking with LLD. | |
734 | ||
735 | config ARCH_SUPPORTS_LTO_CLANG_THIN | |
736 | bool | |
737 | help | |
738 | An architecture should select this option if it can support Clang's | |
739 | ThinLTO mode. | |
740 | ||
741 | config HAS_LTO_CLANG | |
742 | def_bool y | |
743 | depends on CC_IS_CLANG && LD_IS_LLD && AS_IS_LLVM | |
744 | depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm) | |
745 | depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm) | |
746 | depends on ARCH_SUPPORTS_LTO_CLANG | |
747 | depends on !FTRACE_MCOUNT_USE_RECORDMCOUNT | |
748 | # https://github.com/ClangBuiltLinux/linux/issues/1721 | |
749 | depends on (!KASAN || KASAN_HW_TAGS || CLANG_VERSION >= 170000) || !DEBUG_INFO | |
750 | depends on (!KCOV || CLANG_VERSION >= 170000) || !DEBUG_INFO | |
751 | depends on !GCOV_KERNEL | |
752 | help | |
753 | The compiler and Kconfig options support building with Clang's | |
754 | LTO. | |
755 | ||
756 | choice | |
757 | prompt "Link Time Optimization (LTO)" | |
758 | default LTO_NONE | |
759 | help | |
760 | This option enables Link Time Optimization (LTO), which allows the | |
761 | compiler to optimize binaries globally. | |
762 | ||
763 | If unsure, select LTO_NONE. Note that LTO is very resource-intensive | |
764 | so it's disabled by default. | |
765 | ||
766 | config LTO_NONE | |
767 | bool "None" | |
768 | help | |
769 | Build the kernel normally, without Link Time Optimization (LTO). | |
770 | ||
771 | config LTO_CLANG_FULL | |
772 | bool "Clang Full LTO (EXPERIMENTAL)" | |
773 | depends on HAS_LTO_CLANG | |
774 | depends on !COMPILE_TEST | |
775 | select LTO_CLANG | |
776 | help | |
777 | This option enables Clang's full Link Time Optimization (LTO), which | |
778 | allows the compiler to optimize the kernel globally. If you enable | |
779 | this option, the compiler generates LLVM bitcode instead of ELF | |
780 | object files, and the actual compilation from bitcode happens at | |
781 | the LTO link step, which may take several minutes depending on the | |
782 | kernel configuration. More information can be found from LLVM's | |
783 | documentation: | |
784 | ||
785 | https://llvm.org/docs/LinkTimeOptimization.html | |
786 | ||
787 | During link time, this option can use a large amount of RAM, and | |
788 | may take much longer than the ThinLTO option. | |
789 | ||
790 | config LTO_CLANG_THIN | |
791 | bool "Clang ThinLTO (EXPERIMENTAL)" | |
792 | depends on HAS_LTO_CLANG && ARCH_SUPPORTS_LTO_CLANG_THIN | |
793 | select LTO_CLANG | |
794 | help | |
795 | This option enables Clang's ThinLTO, which allows for parallel | |
796 | optimization and faster incremental compiles compared to the | |
797 | CONFIG_LTO_CLANG_FULL option. More information can be found | |
798 | from Clang's documentation: | |
799 | ||
800 | https://clang.llvm.org/docs/ThinLTO.html | |
801 | ||
802 | If unsure, say Y. | |
803 | endchoice | |
804 | ||
805 | config ARCH_SUPPORTS_CFI_CLANG | |
806 | bool | |
807 | help | |
808 | An architecture should select this option if it can support Clang's | |
809 | Control-Flow Integrity (CFI) checking. | |
810 | ||
811 | config ARCH_USES_CFI_TRAPS | |
812 | bool | |
813 | ||
814 | config CFI_CLANG | |
815 | bool "Use Clang's Control Flow Integrity (CFI)" | |
816 | depends on ARCH_SUPPORTS_CFI_CLANG | |
817 | depends on $(cc-option,-fsanitize=kcfi) | |
818 | help | |
819 | This option enables Clang's forward-edge Control Flow Integrity | |
820 | (CFI) checking, where the compiler injects a runtime check to each | |
821 | indirect function call to ensure the target is a valid function with | |
822 | the correct static type. This restricts possible call targets and | |
823 | makes it more difficult for an attacker to exploit bugs that allow | |
824 | the modification of stored function pointers. More information can be | |
825 | found from Clang's documentation: | |
826 | ||
827 | https://clang.llvm.org/docs/ControlFlowIntegrity.html | |
828 | ||
829 | config CFI_PERMISSIVE | |
830 | bool "Use CFI in permissive mode" | |
831 | depends on CFI_CLANG | |
832 | help | |
833 | When selected, Control Flow Integrity (CFI) violations result in a | |
834 | warning instead of a kernel panic. This option should only be used | |
835 | for finding indirect call type mismatches during development. | |
836 | ||
837 | If unsure, say N. | |
838 | ||
839 | config HAVE_ARCH_WITHIN_STACK_FRAMES | |
840 | bool | |
841 | help | |
842 | An architecture should select this if it can walk the kernel stack | |
843 | frames to determine if an object is part of either the arguments | |
844 | or local variables (i.e. that it excludes saved return addresses, | |
845 | and similar) by implementing an inline arch_within_stack_frames(), | |
846 | which is used by CONFIG_HARDENED_USERCOPY. | |
847 | ||
848 | config HAVE_CONTEXT_TRACKING_USER | |
849 | bool | |
850 | help | |
851 | Provide kernel/user boundaries probes necessary for subsystems | |
852 | that need it, such as userspace RCU extended quiescent state. | |
853 | Syscalls need to be wrapped inside user_exit()-user_enter(), either | |
854 | optimized behind static key or through the slow path using TIF_NOHZ | |
855 | flag. Exceptions handlers must be wrapped as well. Irqs are already | |
856 | protected inside ct_irq_enter/ct_irq_exit() but preemption or signal | |
857 | handling on irq exit still need to be protected. | |
858 | ||
859 | config HAVE_CONTEXT_TRACKING_USER_OFFSTACK | |
860 | bool | |
861 | help | |
862 | Architecture neither relies on exception_enter()/exception_exit() | |
863 | nor on schedule_user(). Also preempt_schedule_notrace() and | |
864 | preempt_schedule_irq() can't be called in a preemptible section | |
865 | while context tracking is CONTEXT_USER. This feature reflects a sane | |
866 | entry implementation where the following requirements are met on | |
867 | critical entry code, ie: before user_exit() or after user_enter(): | |
868 | ||
869 | - Critical entry code isn't preemptible (or better yet: | |
870 | not interruptible). | |
871 | - No use of RCU read side critical sections, unless ct_nmi_enter() | |
872 | got called. | |
873 | - No use of instrumentation, unless instrumentation_begin() got | |
874 | called. | |
875 | ||
876 | config HAVE_TIF_NOHZ | |
877 | bool | |
878 | help | |
879 | Arch relies on TIF_NOHZ and syscall slow path to implement context | |
880 | tracking calls to user_enter()/user_exit(). | |
881 | ||
882 | config HAVE_VIRT_CPU_ACCOUNTING | |
883 | bool | |
884 | ||
885 | config HAVE_VIRT_CPU_ACCOUNTING_IDLE | |
886 | bool | |
887 | help | |
888 | Architecture has its own way to account idle CPU time and therefore | |
889 | doesn't implement vtime_account_idle(). | |
890 | ||
891 | config ARCH_HAS_SCALED_CPUTIME | |
892 | bool | |
893 | ||
894 | config HAVE_VIRT_CPU_ACCOUNTING_GEN | |
895 | bool | |
896 | default y if 64BIT | |
897 | help | |
898 | With VIRT_CPU_ACCOUNTING_GEN, cputime_t becomes 64-bit. | |
899 | Before enabling this option, arch code must be audited | |
900 | to ensure there are no races in concurrent read/write of | |
901 | cputime_t. For example, reading/writing 64-bit cputime_t on | |
902 | some 32-bit arches may require multiple accesses, so proper | |
903 | locking is needed to protect against concurrent accesses. | |
904 | ||
905 | config HAVE_IRQ_TIME_ACCOUNTING | |
906 | bool | |
907 | help | |
908 | Archs need to ensure they use a high enough resolution clock to | |
909 | support irq time accounting and then call enable_sched_clock_irqtime(). | |
910 | ||
911 | config HAVE_MOVE_PUD | |
912 | bool | |
913 | help | |
914 | Architectures that select this are able to move page tables at the | |
915 | PUD level. If there are only 3 page table levels, the move effectively | |
916 | happens at the PGD level. | |
917 | ||
918 | config HAVE_MOVE_PMD | |
919 | bool | |
920 | help | |
921 | Archs that select this are able to move page tables at the PMD level. | |
922 | ||
923 | config HAVE_ARCH_TRANSPARENT_HUGEPAGE | |
924 | bool | |
925 | ||
926 | config HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD | |
927 | bool | |
928 | ||
929 | config HAVE_ARCH_HUGE_VMAP | |
930 | bool | |
931 | ||
932 | # | |
933 | # Archs that select this would be capable of PMD-sized vmaps (i.e., | |
934 | # arch_vmap_pmd_supported() returns true). The VM_ALLOW_HUGE_VMAP flag | |
935 | # must be used to enable allocations to use hugepages. | |
936 | # | |
937 | config HAVE_ARCH_HUGE_VMALLOC | |
938 | depends on HAVE_ARCH_HUGE_VMAP | |
939 | bool | |
940 | ||
941 | config ARCH_WANT_HUGE_PMD_SHARE | |
942 | bool | |
943 | ||
944 | # Archs that want to use pmd_mkwrite on kernel memory need it defined even | |
945 | # if there are no userspace memory management features that use it | |
946 | config ARCH_WANT_KERNEL_PMD_MKWRITE | |
947 | bool | |
948 | ||
949 | config ARCH_WANT_PMD_MKWRITE | |
950 | def_bool TRANSPARENT_HUGEPAGE || ARCH_WANT_KERNEL_PMD_MKWRITE | |
951 | ||
952 | config HAVE_ARCH_SOFT_DIRTY | |
953 | bool | |
954 | ||
955 | config HAVE_MOD_ARCH_SPECIFIC | |
956 | bool | |
957 | help | |
958 | The arch uses struct mod_arch_specific to store data. Many arches | |
959 | just need a simple module loader without arch specific data - those | |
960 | should not enable this. | |
961 | ||
962 | config MODULES_USE_ELF_RELA | |
963 | bool | |
964 | help | |
965 | Modules only use ELF RELA relocations. Modules with ELF REL | |
966 | relocations will give an error. | |
967 | ||
968 | config MODULES_USE_ELF_REL | |
969 | bool | |
970 | help | |
971 | Modules only use ELF REL relocations. Modules with ELF RELA | |
972 | relocations will give an error. | |
973 | ||
974 | config ARCH_WANTS_MODULES_DATA_IN_VMALLOC | |
975 | bool | |
976 | help | |
977 | For architectures like powerpc/32 which have constraints on module | |
978 | allocation and need to allocate module data outside of module area. | |
979 | ||
980 | config ARCH_WANTS_EXECMEM_LATE | |
981 | bool | |
982 | help | |
983 | For architectures that do not allocate executable memory early on | |
984 | boot, but rather require its initialization late when there is | |
985 | enough entropy for module space randomization, for instance | |
986 | arm64. | |
987 | ||
988 | config HAVE_IRQ_EXIT_ON_IRQ_STACK | |
989 | bool | |
990 | help | |
991 | Architecture doesn't only execute the irq handler on the irq stack | |
992 | but also irq_exit(). This way we can process softirqs on this irq | |
993 | stack instead of switching to a new one when we call __do_softirq() | |
994 | in the end of an hardirq. | |
995 | This spares a stack switch and improves cache usage on softirq | |
996 | processing. | |
997 | ||
998 | config HAVE_SOFTIRQ_ON_OWN_STACK | |
999 | bool | |
1000 | help | |
1001 | Architecture provides a function to run __do_softirq() on a | |
1002 | separate stack. | |
1003 | ||
1004 | config SOFTIRQ_ON_OWN_STACK | |
1005 | def_bool HAVE_SOFTIRQ_ON_OWN_STACK && !PREEMPT_RT | |
1006 | ||
1007 | config ALTERNATE_USER_ADDRESS_SPACE | |
1008 | bool | |
1009 | help | |
1010 | Architectures set this when the CPU uses separate address | |
1011 | spaces for kernel and user space pointers. In this case, the | |
1012 | access_ok() check on a __user pointer is skipped. | |
1013 | ||
1014 | config PGTABLE_LEVELS | |
1015 | int | |
1016 | default 2 | |
1017 | ||
1018 | config ARCH_HAS_ELF_RANDOMIZE | |
1019 | bool | |
1020 | help | |
1021 | An architecture supports choosing randomized locations for | |
1022 | stack, mmap, brk, and ET_DYN. Defined functions: | |
1023 | - arch_mmap_rnd() | |
1024 | - arch_randomize_brk() | |
1025 | ||
1026 | config HAVE_ARCH_MMAP_RND_BITS | |
1027 | bool | |
1028 | help | |
1029 | An arch should select this symbol if it supports setting a variable | |
1030 | number of bits for use in establishing the base address for mmap | |
1031 | allocations, has MMU enabled and provides values for both: | |
1032 | - ARCH_MMAP_RND_BITS_MIN | |
1033 | - ARCH_MMAP_RND_BITS_MAX | |
1034 | ||
1035 | config HAVE_EXIT_THREAD | |
1036 | bool | |
1037 | help | |
1038 | An architecture implements exit_thread. | |
1039 | ||
1040 | config ARCH_MMAP_RND_BITS_MIN | |
1041 | int | |
1042 | ||
1043 | config ARCH_MMAP_RND_BITS_MAX | |
1044 | int | |
1045 | ||
1046 | config ARCH_MMAP_RND_BITS_DEFAULT | |
1047 | int | |
1048 | ||
1049 | config ARCH_MMAP_RND_BITS | |
1050 | int "Number of bits to use for ASLR of mmap base address" if EXPERT | |
1051 | range ARCH_MMAP_RND_BITS_MIN ARCH_MMAP_RND_BITS_MAX | |
1052 | default ARCH_MMAP_RND_BITS_DEFAULT if ARCH_MMAP_RND_BITS_DEFAULT | |
1053 | default ARCH_MMAP_RND_BITS_MIN | |
1054 | depends on HAVE_ARCH_MMAP_RND_BITS | |
1055 | help | |
1056 | This value can be used to select the number of bits to use to | |
1057 | determine the random offset to the base address of vma regions | |
1058 | resulting from mmap allocations. This value will be bounded | |
1059 | by the architecture's minimum and maximum supported values. | |
1060 | ||
1061 | This value can be changed after boot using the | |
1062 | /proc/sys/vm/mmap_rnd_bits tunable | |
1063 | ||
1064 | config HAVE_ARCH_MMAP_RND_COMPAT_BITS | |
1065 | bool | |
1066 | help | |
1067 | An arch should select this symbol if it supports running applications | |
1068 | in compatibility mode, supports setting a variable number of bits for | |
1069 | use in establishing the base address for mmap allocations, has MMU | |
1070 | enabled and provides values for both: | |
1071 | - ARCH_MMAP_RND_COMPAT_BITS_MIN | |
1072 | - ARCH_MMAP_RND_COMPAT_BITS_MAX | |
1073 | ||
1074 | config ARCH_MMAP_RND_COMPAT_BITS_MIN | |
1075 | int | |
1076 | ||
1077 | config ARCH_MMAP_RND_COMPAT_BITS_MAX | |
1078 | int | |
1079 | ||
1080 | config ARCH_MMAP_RND_COMPAT_BITS_DEFAULT | |
1081 | int | |
1082 | ||
1083 | config ARCH_MMAP_RND_COMPAT_BITS | |
1084 | int "Number of bits to use for ASLR of mmap base address for compatible applications" if EXPERT | |
1085 | range ARCH_MMAP_RND_COMPAT_BITS_MIN ARCH_MMAP_RND_COMPAT_BITS_MAX | |
1086 | default ARCH_MMAP_RND_COMPAT_BITS_DEFAULT if ARCH_MMAP_RND_COMPAT_BITS_DEFAULT | |
1087 | default ARCH_MMAP_RND_COMPAT_BITS_MIN | |
1088 | depends on HAVE_ARCH_MMAP_RND_COMPAT_BITS | |
1089 | help | |
1090 | This value can be used to select the number of bits to use to | |
1091 | determine the random offset to the base address of vma regions | |
1092 | resulting from mmap allocations for compatible applications This | |
1093 | value will be bounded by the architecture's minimum and maximum | |
1094 | supported values. | |
1095 | ||
1096 | This value can be changed after boot using the | |
1097 | /proc/sys/vm/mmap_rnd_compat_bits tunable | |
1098 | ||
1099 | config HAVE_ARCH_COMPAT_MMAP_BASES | |
1100 | bool | |
1101 | help | |
1102 | This allows 64bit applications to invoke 32-bit mmap() syscall | |
1103 | and vice-versa 32-bit applications to call 64-bit mmap(). | |
1104 | Required for applications doing different bitness syscalls. | |
1105 | ||
1106 | config HAVE_PAGE_SIZE_4KB | |
1107 | bool | |
1108 | ||
1109 | config HAVE_PAGE_SIZE_8KB | |
1110 | bool | |
1111 | ||
1112 | config HAVE_PAGE_SIZE_16KB | |
1113 | bool | |
1114 | ||
1115 | config HAVE_PAGE_SIZE_32KB | |
1116 | bool | |
1117 | ||
1118 | config HAVE_PAGE_SIZE_64KB | |
1119 | bool | |
1120 | ||
1121 | config HAVE_PAGE_SIZE_256KB | |
1122 | bool | |
1123 | ||
1124 | choice | |
1125 | prompt "MMU page size" | |
1126 | ||
1127 | config PAGE_SIZE_4KB | |
1128 | bool "4KiB pages" | |
1129 | depends on HAVE_PAGE_SIZE_4KB | |
1130 | help | |
1131 | This option select the standard 4KiB Linux page size and the only | |
1132 | available option on many architectures. Using 4KiB page size will | |
1133 | minimize memory consumption and is therefore recommended for low | |
1134 | memory systems. | |
1135 | Some software that is written for x86 systems makes incorrect | |
1136 | assumptions about the page size and only runs on 4KiB pages. | |
1137 | ||
1138 | config PAGE_SIZE_8KB | |
1139 | bool "8KiB pages" | |
1140 | depends on HAVE_PAGE_SIZE_8KB | |
1141 | help | |
1142 | This option is the only supported page size on a few older | |
1143 | processors, and can be slightly faster than 4KiB pages. | |
1144 | ||
1145 | config PAGE_SIZE_16KB | |
1146 | bool "16KiB pages" | |
1147 | depends on HAVE_PAGE_SIZE_16KB | |
1148 | help | |
1149 | This option is usually a good compromise between memory | |
1150 | consumption and performance for typical desktop and server | |
1151 | workloads, often saving a level of page table lookups compared | |
1152 | to 4KB pages as well as reducing TLB pressure and overhead of | |
1153 | per-page operations in the kernel at the expense of a larger | |
1154 | page cache. | |
1155 | ||
1156 | config PAGE_SIZE_32KB | |
1157 | bool "32KiB pages" | |
1158 | depends on HAVE_PAGE_SIZE_32KB | |
1159 | help | |
1160 | Using 32KiB page size will result in slightly higher performance | |
1161 | kernel at the price of higher memory consumption compared to | |
1162 | 16KiB pages. This option is available only on cnMIPS cores. | |
1163 | Note that you will need a suitable Linux distribution to | |
1164 | support this. | |
1165 | ||
1166 | config PAGE_SIZE_64KB | |
1167 | bool "64KiB pages" | |
1168 | depends on HAVE_PAGE_SIZE_64KB | |
1169 | help | |
1170 | Using 64KiB page size will result in slightly higher performance | |
1171 | kernel at the price of much higher memory consumption compared to | |
1172 | 4KiB or 16KiB pages. | |
1173 | This is not suitable for general-purpose workloads but the | |
1174 | better performance may be worth the cost for certain types of | |
1175 | supercomputing or database applications that work mostly with | |
1176 | large in-memory data rather than small files. | |
1177 | ||
1178 | config PAGE_SIZE_256KB | |
1179 | bool "256KiB pages" | |
1180 | depends on HAVE_PAGE_SIZE_256KB | |
1181 | help | |
1182 | 256KiB pages have little practical value due to their extreme | |
1183 | memory usage. The kernel will only be able to run applications | |
1184 | that have been compiled with '-zmax-page-size' set to 256KiB | |
1185 | (the default is 64KiB or 4KiB on most architectures). | |
1186 | ||
1187 | endchoice | |
1188 | ||
1189 | config PAGE_SIZE_LESS_THAN_64KB | |
1190 | def_bool y | |
1191 | depends on !PAGE_SIZE_64KB | |
1192 | depends on PAGE_SIZE_LESS_THAN_256KB | |
1193 | ||
1194 | config PAGE_SIZE_LESS_THAN_256KB | |
1195 | def_bool y | |
1196 | depends on !PAGE_SIZE_256KB | |
1197 | ||
1198 | config PAGE_SHIFT | |
1199 | int | |
1200 | default 12 if PAGE_SIZE_4KB | |
1201 | default 13 if PAGE_SIZE_8KB | |
1202 | default 14 if PAGE_SIZE_16KB | |
1203 | default 15 if PAGE_SIZE_32KB | |
1204 | default 16 if PAGE_SIZE_64KB | |
1205 | default 18 if PAGE_SIZE_256KB | |
1206 | ||
1207 | # This allows to use a set of generic functions to determine mmap base | |
1208 | # address by giving priority to top-down scheme only if the process | |
1209 | # is not in legacy mode (compat task, unlimited stack size or | |
1210 | # sysctl_legacy_va_layout). | |
1211 | # Architecture that selects this option can provide its own version of: | |
1212 | # - STACK_RND_MASK | |
1213 | config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT | |
1214 | bool | |
1215 | depends on MMU | |
1216 | select ARCH_HAS_ELF_RANDOMIZE | |
1217 | ||
1218 | config HAVE_OBJTOOL | |
1219 | bool | |
1220 | ||
1221 | config HAVE_JUMP_LABEL_HACK | |
1222 | bool | |
1223 | ||
1224 | config HAVE_NOINSTR_HACK | |
1225 | bool | |
1226 | ||
1227 | config HAVE_NOINSTR_VALIDATION | |
1228 | bool | |
1229 | ||
1230 | config HAVE_UACCESS_VALIDATION | |
1231 | bool | |
1232 | select OBJTOOL | |
1233 | ||
1234 | config HAVE_STACK_VALIDATION | |
1235 | bool | |
1236 | help | |
1237 | Architecture supports objtool compile-time frame pointer rule | |
1238 | validation. | |
1239 | ||
1240 | config HAVE_RELIABLE_STACKTRACE | |
1241 | bool | |
1242 | help | |
1243 | Architecture has either save_stack_trace_tsk_reliable() or | |
1244 | arch_stack_walk_reliable() function which only returns a stack trace | |
1245 | if it can guarantee the trace is reliable. | |
1246 | ||
1247 | config HAVE_ARCH_HASH | |
1248 | bool | |
1249 | default n | |
1250 | help | |
1251 | If this is set, the architecture provides an <asm/hash.h> | |
1252 | file which provides platform-specific implementations of some | |
1253 | functions in <linux/hash.h> or fs/namei.c. | |
1254 | ||
1255 | config HAVE_ARCH_NVRAM_OPS | |
1256 | bool | |
1257 | ||
1258 | config ISA_BUS_API | |
1259 | def_bool ISA | |
1260 | ||
1261 | # | |
1262 | # ABI hall of shame | |
1263 | # | |
1264 | config CLONE_BACKWARDS | |
1265 | bool | |
1266 | help | |
1267 | Architecture has tls passed as the 4th argument of clone(2), | |
1268 | not the 5th one. | |
1269 | ||
1270 | config CLONE_BACKWARDS2 | |
1271 | bool | |
1272 | help | |
1273 | Architecture has the first two arguments of clone(2) swapped. | |
1274 | ||
1275 | config CLONE_BACKWARDS3 | |
1276 | bool | |
1277 | help | |
1278 | Architecture has tls passed as the 3rd argument of clone(2), | |
1279 | not the 5th one. | |
1280 | ||
1281 | config ODD_RT_SIGACTION | |
1282 | bool | |
1283 | help | |
1284 | Architecture has unusual rt_sigaction(2) arguments | |
1285 | ||
1286 | config OLD_SIGSUSPEND | |
1287 | bool | |
1288 | help | |
1289 | Architecture has old sigsuspend(2) syscall, of one-argument variety | |
1290 | ||
1291 | config OLD_SIGSUSPEND3 | |
1292 | bool | |
1293 | help | |
1294 | Even weirder antique ABI - three-argument sigsuspend(2) | |
1295 | ||
1296 | config OLD_SIGACTION | |
1297 | bool | |
1298 | help | |
1299 | Architecture has old sigaction(2) syscall. Nope, not the same | |
1300 | as OLD_SIGSUSPEND | OLD_SIGSUSPEND3 - alpha has sigsuspend(2), | |
1301 | but fairly different variant of sigaction(2), thanks to OSF/1 | |
1302 | compatibility... | |
1303 | ||
1304 | config COMPAT_OLD_SIGACTION | |
1305 | bool | |
1306 | ||
1307 | config COMPAT_32BIT_TIME | |
1308 | bool "Provide system calls for 32-bit time_t" | |
1309 | default !64BIT || COMPAT | |
1310 | help | |
1311 | This enables 32 bit time_t support in addition to 64 bit time_t support. | |
1312 | This is relevant on all 32-bit architectures, and 64-bit architectures | |
1313 | as part of compat syscall handling. | |
1314 | ||
1315 | config ARCH_NO_PREEMPT | |
1316 | bool | |
1317 | ||
1318 | config ARCH_SUPPORTS_RT | |
1319 | bool | |
1320 | ||
1321 | config CPU_NO_EFFICIENT_FFS | |
1322 | def_bool n | |
1323 | ||
1324 | config HAVE_ARCH_VMAP_STACK | |
1325 | def_bool n | |
1326 | help | |
1327 | An arch should select this symbol if it can support kernel stacks | |
1328 | in vmalloc space. This means: | |
1329 | ||
1330 | - vmalloc space must be large enough to hold many kernel stacks. | |
1331 | This may rule out many 32-bit architectures. | |
1332 | ||
1333 | - Stacks in vmalloc space need to work reliably. For example, if | |
1334 | vmap page tables are created on demand, either this mechanism | |
1335 | needs to work while the stack points to a virtual address with | |
1336 | unpopulated page tables or arch code (switch_to() and switch_mm(), | |
1337 | most likely) needs to ensure that the stack's page table entries | |
1338 | are populated before running on a possibly unpopulated stack. | |
1339 | ||
1340 | - If the stack overflows into a guard page, something reasonable | |
1341 | should happen. The definition of "reasonable" is flexible, but | |
1342 | instantly rebooting without logging anything would be unfriendly. | |
1343 | ||
1344 | config VMAP_STACK | |
1345 | default y | |
1346 | bool "Use a virtually-mapped stack" | |
1347 | depends on HAVE_ARCH_VMAP_STACK | |
1348 | depends on !KASAN || KASAN_HW_TAGS || KASAN_VMALLOC | |
1349 | help | |
1350 | Enable this if you want the use virtually-mapped kernel stacks | |
1351 | with guard pages. This causes kernel stack overflows to be | |
1352 | caught immediately rather than causing difficult-to-diagnose | |
1353 | corruption. | |
1354 | ||
1355 | To use this with software KASAN modes, the architecture must support | |
1356 | backing virtual mappings with real shadow memory, and KASAN_VMALLOC | |
1357 | must be enabled. | |
1358 | ||
1359 | config HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET | |
1360 | def_bool n | |
1361 | help | |
1362 | An arch should select this symbol if it can support kernel stack | |
1363 | offset randomization with calls to add_random_kstack_offset() | |
1364 | during syscall entry and choose_random_kstack_offset() during | |
1365 | syscall exit. Careful removal of -fstack-protector-strong and | |
1366 | -fstack-protector should also be applied to the entry code and | |
1367 | closely examined, as the artificial stack bump looks like an array | |
1368 | to the compiler, so it will attempt to add canary checks regardless | |
1369 | of the static branch state. | |
1370 | ||
1371 | config RANDOMIZE_KSTACK_OFFSET | |
1372 | bool "Support for randomizing kernel stack offset on syscall entry" if EXPERT | |
1373 | default y | |
1374 | depends on HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET | |
1375 | depends on INIT_STACK_NONE || !CC_IS_CLANG || CLANG_VERSION >= 140000 | |
1376 | help | |
1377 | The kernel stack offset can be randomized (after pt_regs) by | |
1378 | roughly 5 bits of entropy, frustrating memory corruption | |
1379 | attacks that depend on stack address determinism or | |
1380 | cross-syscall address exposures. | |
1381 | ||
1382 | The feature is controlled via the "randomize_kstack_offset=on/off" | |
1383 | kernel boot param, and if turned off has zero overhead due to its use | |
1384 | of static branches (see JUMP_LABEL). | |
1385 | ||
1386 | If unsure, say Y. | |
1387 | ||
1388 | config RANDOMIZE_KSTACK_OFFSET_DEFAULT | |
1389 | bool "Default state of kernel stack offset randomization" | |
1390 | depends on RANDOMIZE_KSTACK_OFFSET | |
1391 | help | |
1392 | Kernel stack offset randomization is controlled by kernel boot param | |
1393 | "randomize_kstack_offset=on/off", and this config chooses the default | |
1394 | boot state. | |
1395 | ||
1396 | config ARCH_OPTIONAL_KERNEL_RWX | |
1397 | def_bool n | |
1398 | ||
1399 | config ARCH_OPTIONAL_KERNEL_RWX_DEFAULT | |
1400 | def_bool n | |
1401 | ||
1402 | config ARCH_HAS_STRICT_KERNEL_RWX | |
1403 | def_bool n | |
1404 | ||
1405 | config STRICT_KERNEL_RWX | |
1406 | bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX | |
1407 | depends on ARCH_HAS_STRICT_KERNEL_RWX | |
1408 | default !ARCH_OPTIONAL_KERNEL_RWX || ARCH_OPTIONAL_KERNEL_RWX_DEFAULT | |
1409 | help | |
1410 | If this is set, kernel text and rodata memory will be made read-only, | |
1411 | and non-text memory will be made non-executable. This provides | |
1412 | protection against certain security exploits (e.g. executing the heap | |
1413 | or modifying text) | |
1414 | ||
1415 | These features are considered standard security practice these days. | |
1416 | You should say Y here in almost all cases. | |
1417 | ||
1418 | config ARCH_HAS_STRICT_MODULE_RWX | |
1419 | def_bool n | |
1420 | ||
1421 | config STRICT_MODULE_RWX | |
1422 | bool "Set loadable kernel module data as NX and text as RO" if ARCH_OPTIONAL_KERNEL_RWX | |
1423 | depends on ARCH_HAS_STRICT_MODULE_RWX && MODULES | |
1424 | default !ARCH_OPTIONAL_KERNEL_RWX || ARCH_OPTIONAL_KERNEL_RWX_DEFAULT | |
1425 | help | |
1426 | If this is set, module text and rodata memory will be made read-only, | |
1427 | and non-text memory will be made non-executable. This provides | |
1428 | protection against certain security exploits (e.g. writing to text) | |
1429 | ||
1430 | # select if the architecture provides an asm/dma-direct.h header | |
1431 | config ARCH_HAS_PHYS_TO_DMA | |
1432 | bool | |
1433 | ||
1434 | config HAVE_ARCH_COMPILER_H | |
1435 | bool | |
1436 | help | |
1437 | An architecture can select this if it provides an | |
1438 | asm/compiler.h header that should be included after | |
1439 | linux/compiler-*.h in order to override macro definitions that those | |
1440 | headers generally provide. | |
1441 | ||
1442 | config HAVE_ARCH_PREL32_RELOCATIONS | |
1443 | bool | |
1444 | help | |
1445 | May be selected by an architecture if it supports place-relative | |
1446 | 32-bit relocations, both in the toolchain and in the module loader, | |
1447 | in which case relative references can be used in special sections | |
1448 | for PCI fixup, initcalls etc which are only half the size on 64 bit | |
1449 | architectures, and don't require runtime relocation on relocatable | |
1450 | kernels. | |
1451 | ||
1452 | config ARCH_USE_MEMREMAP_PROT | |
1453 | bool | |
1454 | ||
1455 | config LOCK_EVENT_COUNTS | |
1456 | bool "Locking event counts collection" | |
1457 | depends on DEBUG_FS | |
1458 | help | |
1459 | Enable light-weight counting of various locking related events | |
1460 | in the system with minimal performance impact. This reduces | |
1461 | the chance of application behavior change because of timing | |
1462 | differences. The counts are reported via debugfs. | |
1463 | ||
1464 | # Select if the architecture has support for applying RELR relocations. | |
1465 | config ARCH_HAS_RELR | |
1466 | bool | |
1467 | ||
1468 | config RELR | |
1469 | bool "Use RELR relocation packing" | |
1470 | depends on ARCH_HAS_RELR && TOOLS_SUPPORT_RELR | |
1471 | default y | |
1472 | help | |
1473 | Store the kernel's dynamic relocations in the RELR relocation packing | |
1474 | format. Requires a compatible linker (LLD supports this feature), as | |
1475 | well as compatible NM and OBJCOPY utilities (llvm-nm and llvm-objcopy | |
1476 | are compatible). | |
1477 | ||
1478 | config ARCH_HAS_MEM_ENCRYPT | |
1479 | bool | |
1480 | ||
1481 | config ARCH_HAS_CC_PLATFORM | |
1482 | bool | |
1483 | ||
1484 | config HAVE_SPARSE_SYSCALL_NR | |
1485 | bool | |
1486 | help | |
1487 | An architecture should select this if its syscall numbering is sparse | |
1488 | to save space. For example, MIPS architecture has a syscall array with | |
1489 | entries at 4000, 5000 and 6000 locations. This option turns on syscall | |
1490 | related optimizations for a given architecture. | |
1491 | ||
1492 | config ARCH_HAS_VDSO_DATA | |
1493 | bool | |
1494 | ||
1495 | config HAVE_STATIC_CALL | |
1496 | bool | |
1497 | ||
1498 | config HAVE_STATIC_CALL_INLINE | |
1499 | bool | |
1500 | depends on HAVE_STATIC_CALL | |
1501 | select OBJTOOL | |
1502 | ||
1503 | config HAVE_PREEMPT_DYNAMIC | |
1504 | bool | |
1505 | ||
1506 | config HAVE_PREEMPT_DYNAMIC_CALL | |
1507 | bool | |
1508 | depends on HAVE_STATIC_CALL | |
1509 | select HAVE_PREEMPT_DYNAMIC | |
1510 | help | |
1511 | An architecture should select this if it can handle the preemption | |
1512 | model being selected at boot time using static calls. | |
1513 | ||
1514 | Where an architecture selects HAVE_STATIC_CALL_INLINE, any call to a | |
1515 | preemption function will be patched directly. | |
1516 | ||
1517 | Where an architecture does not select HAVE_STATIC_CALL_INLINE, any | |
1518 | call to a preemption function will go through a trampoline, and the | |
1519 | trampoline will be patched. | |
1520 | ||
1521 | It is strongly advised to support inline static call to avoid any | |
1522 | overhead. | |
1523 | ||
1524 | config HAVE_PREEMPT_DYNAMIC_KEY | |
1525 | bool | |
1526 | depends on HAVE_ARCH_JUMP_LABEL | |
1527 | select HAVE_PREEMPT_DYNAMIC | |
1528 | help | |
1529 | An architecture should select this if it can handle the preemption | |
1530 | model being selected at boot time using static keys. | |
1531 | ||
1532 | Each preemption function will be given an early return based on a | |
1533 | static key. This should have slightly lower overhead than non-inline | |
1534 | static calls, as this effectively inlines each trampoline into the | |
1535 | start of its callee. This may avoid redundant work, and may | |
1536 | integrate better with CFI schemes. | |
1537 | ||
1538 | This will have greater overhead than using inline static calls as | |
1539 | the call to the preemption function cannot be entirely elided. | |
1540 | ||
1541 | config ARCH_WANT_LD_ORPHAN_WARN | |
1542 | bool | |
1543 | help | |
1544 | An arch should select this symbol once all linker sections are explicitly | |
1545 | included, size-asserted, or discarded in the linker scripts. This is | |
1546 | important because we never want expected sections to be placed heuristically | |
1547 | by the linker, since the locations of such sections can change between linker | |
1548 | versions. | |
1549 | ||
1550 | config HAVE_ARCH_PFN_VALID | |
1551 | bool | |
1552 | ||
1553 | config ARCH_SUPPORTS_DEBUG_PAGEALLOC | |
1554 | bool | |
1555 | ||
1556 | config ARCH_SUPPORTS_PAGE_TABLE_CHECK | |
1557 | bool | |
1558 | ||
1559 | config ARCH_SPLIT_ARG64 | |
1560 | bool | |
1561 | help | |
1562 | If a 32-bit architecture requires 64-bit arguments to be split into | |
1563 | pairs of 32-bit arguments, select this option. | |
1564 | ||
1565 | config ARCH_HAS_ELFCORE_COMPAT | |
1566 | bool | |
1567 | ||
1568 | config ARCH_HAS_PARANOID_L1D_FLUSH | |
1569 | bool | |
1570 | ||
1571 | config ARCH_HAVE_TRACE_MMIO_ACCESS | |
1572 | bool | |
1573 | ||
1574 | config DYNAMIC_SIGFRAME | |
1575 | bool | |
1576 | ||
1577 | # Select, if arch has a named attribute group bound to NUMA device nodes. | |
1578 | config HAVE_ARCH_NODE_DEV_GROUP | |
1579 | bool | |
1580 | ||
1581 | config ARCH_HAS_HW_PTE_YOUNG | |
1582 | bool | |
1583 | help | |
1584 | Architectures that select this option are capable of setting the | |
1585 | accessed bit in PTE entries when using them as part of linear address | |
1586 | translations. Architectures that require runtime check should select | |
1587 | this option and override arch_has_hw_pte_young(). | |
1588 | ||
1589 | config ARCH_HAS_NONLEAF_PMD_YOUNG | |
1590 | bool | |
1591 | help | |
1592 | Architectures that select this option are capable of setting the | |
1593 | accessed bit in non-leaf PMD entries when using them as part of linear | |
1594 | address translations. Page table walkers that clear the accessed bit | |
1595 | may use this capability to reduce their search space. | |
1596 | ||
1597 | config ARCH_HAS_KERNEL_FPU_SUPPORT | |
1598 | bool | |
1599 | help | |
1600 | Architectures that select this option can run floating-point code in | |
1601 | the kernel, as described in Documentation/core-api/floating-point.rst. | |
1602 | ||
1603 | source "kernel/gcov/Kconfig" | |
1604 | ||
1605 | source "scripts/gcc-plugins/Kconfig" | |
1606 | ||
1607 | config FUNCTION_ALIGNMENT_4B | |
1608 | bool | |
1609 | ||
1610 | config FUNCTION_ALIGNMENT_8B | |
1611 | bool | |
1612 | ||
1613 | config FUNCTION_ALIGNMENT_16B | |
1614 | bool | |
1615 | ||
1616 | config FUNCTION_ALIGNMENT_32B | |
1617 | bool | |
1618 | ||
1619 | config FUNCTION_ALIGNMENT_64B | |
1620 | bool | |
1621 | ||
1622 | config FUNCTION_ALIGNMENT | |
1623 | int | |
1624 | default 64 if FUNCTION_ALIGNMENT_64B | |
1625 | default 32 if FUNCTION_ALIGNMENT_32B | |
1626 | default 16 if FUNCTION_ALIGNMENT_16B | |
1627 | default 8 if FUNCTION_ALIGNMENT_8B | |
1628 | default 4 if FUNCTION_ALIGNMENT_4B | |
1629 | default 0 | |
1630 | ||
1631 | config CC_HAS_MIN_FUNCTION_ALIGNMENT | |
1632 | # Detect availability of the GCC option -fmin-function-alignment which | |
1633 | # guarantees minimal alignment for all functions, unlike | |
1634 | # -falign-functions which the compiler ignores for cold functions. | |
1635 | def_bool $(cc-option, -fmin-function-alignment=8) | |
1636 | ||
1637 | config CC_HAS_SANE_FUNCTION_ALIGNMENT | |
1638 | # Set if the guaranteed alignment with -fmin-function-alignment is | |
1639 | # available or extra care is required in the kernel. Clang provides | |
1640 | # strict alignment always, even with -falign-functions. | |
1641 | def_bool CC_HAS_MIN_FUNCTION_ALIGNMENT || CC_IS_CLANG | |
1642 | ||
1643 | config ARCH_NEED_CMPXCHG_1_EMU | |
1644 | bool | |
1645 | ||
1646 | endmenu |