xref: /linux/arch/x86/Kconfig.debug (revision 4ddd32741da87657113d964588ce13ee64b34820)
1menu "Kernel hacking"
2
3config TRACE_IRQFLAGS_SUPPORT
4	def_bool y
5
6source "lib/Kconfig.debug"
7
8config STRICT_DEVMEM
9	bool "Filter access to /dev/mem"
10	---help---
11	  If this option is disabled, you allow userspace (root) access to all
12	  of memory, including kernel and userspace memory. Accidental
13	  access to this is obviously disastrous, but specific access can
14	  be used by people debugging the kernel. Note that with PAT support
15	  enabled, even in this case there are restrictions on /dev/mem
16	  use due to the cache aliasing requirements.
17
18	  If this option is switched on, the /dev/mem file only allows
19	  userspace access to PCI space and the BIOS code and data regions.
20	  This is sufficient for dosemu and X and all common users of
21	  /dev/mem.
22
23	  If in doubt, say Y.
24
25config X86_VERBOSE_BOOTUP
26	bool "Enable verbose x86 bootup info messages"
27	default y
28	---help---
29	  Enables the informational output from the decompression stage
30	  (e.g. bzImage) of the boot. If you disable this you will still
31	  see errors. Disable this if you want silent bootup.
32
33config EARLY_PRINTK
34	bool "Early printk" if EXPERT
35	default y
36	---help---
37	  Write kernel log output directly into the VGA buffer or to a serial
38	  port.
39
40	  This is useful for kernel debugging when your machine crashes very
41	  early before the console code is initialized. For normal operation
42	  it is not recommended because it looks ugly and doesn't cooperate
43	  with klogd/syslogd or the X server. You should normally N here,
44	  unless you want to debug such a crash.
45
46config EARLY_PRINTK_DBGP
47	bool "Early printk via EHCI debug port"
48	depends on EARLY_PRINTK && PCI
49	---help---
50	  Write kernel log output directly into the EHCI debug port.
51
52	  This is useful for kernel debugging when your machine crashes very
53	  early before the console code is initialized. For normal operation
54	  it is not recommended because it looks ugly and doesn't cooperate
55	  with klogd/syslogd or the X server. You should normally N here,
56	  unless you want to debug such a crash. You need usb debug device.
57
58config EARLY_PRINTK_EFI
59	bool "Early printk via the EFI framebuffer"
60	depends on EFI && EARLY_PRINTK
61	select FONT_SUPPORT
62	---help---
63	  Write kernel log output directly into the EFI framebuffer.
64
65	  This is useful for kernel debugging when your machine crashes very
66	  early before the console code is initialized.
67
68config X86_PTDUMP_CORE
69	def_bool n
70
71config X86_PTDUMP
72	bool "Export kernel pagetable layout to userspace via debugfs"
73	depends on DEBUG_KERNEL
74	select DEBUG_FS
75	select X86_PTDUMP_CORE
76	---help---
77	  Say Y here if you want to show the kernel pagetable layout in a
78	  debugfs file. This information is only useful for kernel developers
79	  who are working in architecture specific areas of the kernel.
80	  It is probably not a good idea to enable this feature in a production
81	  kernel.
82	  If in doubt, say "N"
83
84config EFI_PGT_DUMP
85	bool "Dump the EFI pagetable"
86	depends on EFI
87	select X86_PTDUMP_CORE
88	---help---
89	  Enable this if you want to dump the EFI page table before
90	  enabling virtual mode. This can be used to debug miscellaneous
91	  issues with the mapping of the EFI runtime regions into that
92	  table.
93
94config DEBUG_RODATA
95	bool "Write protect kernel read-only data structures"
96	default y
97	depends on DEBUG_KERNEL
98	---help---
99	  Mark the kernel read-only data as write-protected in the pagetables,
100	  in order to catch accidental (and incorrect) writes to such const
101	  data. This is recommended so that we can catch kernel bugs sooner.
102	  If in doubt, say "Y".
103
104config DEBUG_RODATA_TEST
105	bool "Testcase for the DEBUG_RODATA feature"
106	depends on DEBUG_RODATA
107	default y
108	---help---
109	  This option enables a testcase for the DEBUG_RODATA
110	  feature as well as for the change_page_attr() infrastructure.
111	  If in doubt, say "N"
112
113config DEBUG_WX
114	bool "Warn on W+X mappings at boot"
115	depends on DEBUG_RODATA
116	default y
117	select X86_PTDUMP_CORE
118	---help---
119	  Generate a warning if any W+X mappings are found at boot.
120
121	  This is useful for discovering cases where the kernel is leaving
122	  W+X mappings after applying NX, as such mappings are a security risk.
123
124	  Look for a message in dmesg output like this:
125
126	    x86/mm: Checked W+X mappings: passed, no W+X pages found.
127
128	  or like this, if the check failed:
129
130	    x86/mm: Checked W+X mappings: FAILED, <N> W+X pages found.
131
132	  Note that even if the check fails, your kernel is possibly
133	  still fine, as W+X mappings are not a security hole in
134	  themselves, what they do is that they make the exploitation
135	  of other unfixed kernel bugs easier.
136
137	  There is no runtime or memory usage effect of this option
138	  once the kernel has booted up - it's a one time check.
139
140	  If in doubt, say "Y".
141
142config DEBUG_SET_MODULE_RONX
143	bool "Set loadable kernel module data as NX and text as RO"
144	depends on MODULES
145	---help---
146	  This option helps catch unintended modifications to loadable
147	  kernel module's text and read-only data. It also prevents execution
148	  of module data. Such protection may interfere with run-time code
149	  patching and dynamic kernel tracing - and they might also protect
150	  against certain classes of kernel exploits.
151	  If in doubt, say "N".
152
153config DEBUG_NX_TEST
154	tristate "Testcase for the NX non-executable stack feature"
155	depends on DEBUG_KERNEL && m
156	---help---
157	  This option enables a testcase for the CPU NX capability
158	  and the software setup of this feature.
159	  If in doubt, say "N"
160
161config DOUBLEFAULT
162	default y
163	bool "Enable doublefault exception handler" if EXPERT
164	---help---
165	  This option allows trapping of rare doublefault exceptions that
166	  would otherwise cause a system to silently reboot. Disabling this
167	  option saves about 4k and might cause you much additional grey
168	  hair.
169
170config DEBUG_TLBFLUSH
171	bool "Set upper limit of TLB entries to flush one-by-one"
172	depends on DEBUG_KERNEL
173	---help---
174
175	X86-only for now.
176
177	This option allows the user to tune the amount of TLB entries the
178	kernel flushes one-by-one instead of doing a full TLB flush. In
179	certain situations, the former is cheaper. This is controlled by the
180	tlb_flushall_shift knob under /sys/kernel/debug/x86. If you set it
181	to -1, the code flushes the whole TLB unconditionally. Otherwise,
182	for positive values of it, the kernel will use single TLB entry
183	invalidating instructions according to the following formula:
184
185	flush_entries <= active_tlb_entries / 2^tlb_flushall_shift
186
187	If in doubt, say "N".
188
189config IOMMU_DEBUG
190	bool "Enable IOMMU debugging"
191	depends on GART_IOMMU && DEBUG_KERNEL
192	depends on X86_64
193	---help---
194	  Force the IOMMU to on even when you have less than 4GB of
195	  memory and add debugging code. On overflow always panic. And
196	  allow to enable IOMMU leak tracing. Can be disabled at boot
197	  time with iommu=noforce. This will also enable scatter gather
198	  list merging.  Currently not recommended for production
199	  code. When you use it make sure you have a big enough
200	  IOMMU/AGP aperture.  Most of the options enabled by this can
201	  be set more finegrained using the iommu= command line
202	  options. See Documentation/x86/x86_64/boot-options.txt for more
203	  details.
204
205config IOMMU_STRESS
206	bool "Enable IOMMU stress-test mode"
207	---help---
208	  This option disables various optimizations in IOMMU related
209	  code to do real stress testing of the IOMMU code. This option
210	  will cause a performance drop and should only be enabled for
211	  testing.
212
213config IOMMU_LEAK
214	bool "IOMMU leak tracing"
215	depends on IOMMU_DEBUG && DMA_API_DEBUG
216	---help---
217	  Add a simple leak tracer to the IOMMU code. This is useful when you
218	  are debugging a buggy device driver that leaks IOMMU mappings.
219
220config HAVE_MMIOTRACE_SUPPORT
221	def_bool y
222
223config X86_DECODER_SELFTEST
224	bool "x86 instruction decoder selftest"
225	depends on DEBUG_KERNEL && KPROBES
226	depends on !COMPILE_TEST
227	---help---
228	 Perform x86 instruction decoder selftests at build time.
229	 This option is useful for checking the sanity of x86 instruction
230	 decoder code.
231	 If unsure, say "N".
232
233#
234# IO delay types:
235#
236
237config IO_DELAY_TYPE_0X80
238	int
239	default "0"
240
241config IO_DELAY_TYPE_0XED
242	int
243	default "1"
244
245config IO_DELAY_TYPE_UDELAY
246	int
247	default "2"
248
249config IO_DELAY_TYPE_NONE
250	int
251	default "3"
252
253choice
254	prompt "IO delay type"
255	default IO_DELAY_0X80
256
257config IO_DELAY_0X80
258	bool "port 0x80 based port-IO delay [recommended]"
259	---help---
260	  This is the traditional Linux IO delay used for in/out_p.
261	  It is the most tested hence safest selection here.
262
263config IO_DELAY_0XED
264	bool "port 0xed based port-IO delay"
265	---help---
266	  Use port 0xed as the IO delay. This frees up port 0x80 which is
267	  often used as a hardware-debug port.
268
269config IO_DELAY_UDELAY
270	bool "udelay based port-IO delay"
271	---help---
272	  Use udelay(2) as the IO delay method. This provides the delay
273	  while not having any side-effect on the IO port space.
274
275config IO_DELAY_NONE
276	bool "no port-IO delay"
277	---help---
278	  No port-IO delay. Will break on old boxes that require port-IO
279	  delay for certain operations. Should work on most new machines.
280
281endchoice
282
283if IO_DELAY_0X80
284config DEFAULT_IO_DELAY_TYPE
285	int
286	default IO_DELAY_TYPE_0X80
287endif
288
289if IO_DELAY_0XED
290config DEFAULT_IO_DELAY_TYPE
291	int
292	default IO_DELAY_TYPE_0XED
293endif
294
295if IO_DELAY_UDELAY
296config DEFAULT_IO_DELAY_TYPE
297	int
298	default IO_DELAY_TYPE_UDELAY
299endif
300
301if IO_DELAY_NONE
302config DEFAULT_IO_DELAY_TYPE
303	int
304	default IO_DELAY_TYPE_NONE
305endif
306
307config DEBUG_BOOT_PARAMS
308	bool "Debug boot parameters"
309	depends on DEBUG_KERNEL
310	depends on DEBUG_FS
311	---help---
312	  This option will cause struct boot_params to be exported via debugfs.
313
314config CPA_DEBUG
315	bool "CPA self-test code"
316	depends on DEBUG_KERNEL
317	---help---
318	  Do change_page_attr() self-tests every 30 seconds.
319
320config OPTIMIZE_INLINING
321	bool "Allow gcc to uninline functions marked 'inline'"
322	---help---
323	  This option determines if the kernel forces gcc to inline the functions
324	  developers have marked 'inline'. Doing so takes away freedom from gcc to
325	  do what it thinks is best, which is desirable for the gcc 3.x series of
326	  compilers. The gcc 4.x series have a rewritten inlining algorithm and
327	  enabling this option will generate a smaller kernel there. Hopefully
328	  this algorithm is so good that allowing gcc 4.x and above to make the
329	  decision will become the default in the future. Until then this option
330	  is there to test gcc for this.
331
332	  If unsure, say N.
333
334config DEBUG_ENTRY
335	bool "Debug low-level entry code"
336	depends on DEBUG_KERNEL
337	---help---
338	  This option enables sanity checks in x86's low-level entry code.
339	  Some of these sanity checks may slow down kernel entries and
340	  exits or otherwise impact performance.
341
342	  This is currently used to help test NMI code.
343
344	  If unsure, say N.
345
346config DEBUG_NMI_SELFTEST
347	bool "NMI Selftest"
348	depends on DEBUG_KERNEL && X86_LOCAL_APIC
349	---help---
350	  Enabling this option turns on a quick NMI selftest to verify
351	  that the NMI behaves correctly.
352
353	  This might help diagnose strange hangs that rely on NMI to
354	  function properly.
355
356	  If unsure, say N.
357
358config DEBUG_IMR_SELFTEST
359	bool "Isolated Memory Region self test"
360	default n
361	depends on INTEL_IMR
362	---help---
363	  This option enables automated sanity testing of the IMR code.
364	  Some simple tests are run to verify IMR bounds checking, alignment
365	  and overlapping. This option is really only useful if you are
366	  debugging an IMR memory map or are modifying the IMR code and want to
367	  test your changes.
368
369	  If unsure say N here.
370
371config X86_DEBUG_STATIC_CPU_HAS
372	bool "Debug alternatives"
373	depends on DEBUG_KERNEL
374	---help---
375	  This option causes additional code to be generated which
376	  fails if static_cpu_has() is used before alternatives have
377	  run.
378
379	  If unsure, say N.
380
381config X86_DEBUG_FPU
382	bool "Debug the x86 FPU code"
383	depends on DEBUG_KERNEL
384	default y
385	---help---
386	  If this option is enabled then there will be extra sanity
387	  checks and (boot time) debug printouts added to the kernel.
388	  This debugging adds some small amount of runtime overhead
389	  to the kernel.
390
391	  If unsure, say N.
392
393config PUNIT_ATOM_DEBUG
394	tristate "ATOM Punit debug driver"
395	select DEBUG_FS
396	select IOSF_MBI
397	---help---
398	  This is a debug driver, which gets the power states
399	  of all Punit North Complex devices. The power states of
400	  each device is exposed as part of the debugfs interface.
401	  The current power state can be read from
402	  /sys/kernel/debug/punit_atom/dev_power_state
403
404endmenu
405