AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-24 00:37:13 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
e8c6226d48
linux_dsm_epyc7002/arch/parisc/Kconfig
Josh Poimboeuf 0d025d271e mm/usercopy: get rid of CONFIG_DEBUG_STRICT_USER_COPY_CHECKS 
There are three usercopy warnings which are currently being silenced for
gcc 4.6 and newer:

1) "copy_from_user() buffer size is too small" compile warning/error

   This is a static warning which happens when object size and copy size
   are both const, and copy size > object size.  I didn't see any false
   positives for this one.  So the function warning attribute seems to
   be working fine here.

   Note this scenario is always a bug and so I think it should be
   changed to *always* be an error, regardless of
   CONFIG_DEBUG_STRICT_USER_COPY_CHECKS.

2) "copy_from_user() buffer size is not provably correct" compile warning

   This is another static warning which happens when I enable
   __compiletime_object_size() for new compilers (and
   CONFIG_DEBUG_STRICT_USER_COPY_CHECKS).  It happens when object size
   is const, but copy size is *not*.  In this case there's no way to
   compare the two at build time, so it gives the warning.  (Note the
   warning is a byproduct of the fact that gcc has no way of knowing
   whether the overflow function will be called, so the call isn't dead
   code and the warning attribute is activated.)

   So this warning seems to only indicate "this is an unusual pattern,
   maybe you should check it out" rather than "this is a bug".

   I get 102(!) of these warnings with allyesconfig and the
   __compiletime_object_size() gcc check removed.  I don't know if there
   are any real bugs hiding in there, but from looking at a small
   sample, I didn't see any.  According to Kees, it does sometimes find
   real bugs.  But the false positive rate seems high.

3) "Buffer overflow detected" runtime warning

   This is a runtime warning where object size is const, and copy size >
   object size.

All three warnings (both static and runtime) were completely disabled
for gcc 4.6 with the following commit:

  2fb0815c9e ("gcc4: disable __compiletime_object_size for GCC 4.6+")

That commit mistakenly assumed that the false positives were caused by a
gcc bug in __compiletime_object_size().  But in fact,
__compiletime_object_size() seems to be working fine.  The false
positives were instead triggered by #2 above.  (Though I don't have an
explanation for why the warnings supposedly only started showing up in
gcc 4.6.)

So remove warning #2 to get rid of all the false positives, and re-enable
warnings #1 and #3 by reverting the above commit.

Furthermore, since #1 is a real bug which is detected at compile time,
upgrade it to always be an error.

Having done all that, CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is no longer
needed.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Byungchul Park <byungchul.park@lge.com>
Cc: Nilay Vaish <nilayvaish@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-08-30 10:10:21 -07:00

353 lines
8.1 KiB
Plaintext
Raw Blame History

config PARISC
def_bool y
select ARCH_MIGHT_HAVE_PC_PARPORT
select HAVE_IDE
select HAVE_OPROFILE
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_SYSCALL_TRACEPOINTS
select ARCH_WANT_FRAME_POINTERS
select RTC_CLASS
select RTC_DRV_GENERIC
select INIT_ALL_POSSIBLE
select BUG
select BUILDTIME_EXTABLE_SORT
select HAVE_PERF_EVENTS
select GENERIC_ATOMIC64 if !64BIT
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select BROKEN_RODATA
select GENERIC_IRQ_PROBE
select GENERIC_PCI_IOMAP
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select GENERIC_SMP_IDLE_THREAD
select GENERIC_STRNCPY_FROM_USER
select SYSCTL_ARCH_UNALIGN_ALLOW
select SYSCTL_EXCEPTION_TRACE
select HAVE_MOD_ARCH_SPECIFIC
select VIRT_TO_BUS
select MODULES_USE_ELF_RELA
select CLONE_BACKWARDS
select TTY # Needed for pdc_cons.c
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_HASH
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
select HAVE_UNSTABLE_SCHED_CLOCK if (SMP || !64BIT)
select ARCH_NO_COHERENT_DMA_MMAP
select CPU_NO_EFFICIENT_FFS
help
The PA-RISC microprocessor is designed by Hewlett-Packard and used
in many of their workstations & servers (HP9000 700 and 800 series,
and later HP3000 series). The PA-RISC Linux project home page is
at <http://www.parisc-linux.org/>.
config MMU
def_bool y
config STACK_GROWSUP
def_bool y
config GENERIC_LOCKBREAK
bool
default y
depends on SMP && PREEMPT
config RWSEM_GENERIC_SPINLOCK
def_bool y
config RWSEM_XCHGADD_ALGORITHM
bool
config ARCH_HAS_ILOG2_U32
bool
default n
config ARCH_HAS_ILOG2_U64
bool
default n
config GENERIC_BUG
bool
default y
depends on BUG
config GENERIC_HWEIGHT
bool
default y
config GENERIC_CALIBRATE_DELAY
bool
default y
config TIME_LOW_RES
bool
depends on SMP
default y
# unless you want to implement ACPI on PA-RISC ... ;-)
config PM
bool
config STACKTRACE_SUPPORT
def_bool y
config NEED_DMA_MAP_STATE
def_bool y
config NEED_SG_DMA_LENGTH
def_bool y
config ISA_DMA_API
bool
config ARCH_MAY_HAVE_PC_FDC
bool
depends on BROKEN
default y
config PGTABLE_LEVELS
int
default 3 if 64BIT && PARISC_PAGE_SIZE_4KB
default 2
config SYS_SUPPORTS_HUGETLBFS
def_bool y if PA20
source "init/Kconfig"
source "kernel/Kconfig.freezer"
menu "Processor type and features"
choice
prompt "Processor type"
default PA7000
config PA7000
bool "PA7000/PA7100"
---help---
This is the processor type of your CPU. This information is
used for optimizing purposes. In order to compile a kernel
that can run on all 32-bit PA CPUs (albeit not optimally fast),
you can specify "PA7000" here.
Specifying "PA8000" here will allow you to select a 64-bit kernel
which is required on some machines.
config PA7100LC
bool "PA7100LC"
help
Select this option for the PCX-L processor, as used in the
712, 715/64, 715/80, 715/100, 715/100XC, 725/100, 743, 748,
D200, D210, D300, D310 and E-class
config PA7200
bool "PA7200"
help
Select this option for the PCX-T' processor, as used in the
C100, C110, J100, J110, J210XC, D250, D260, D350, D360,
K100, K200, K210, K220, K400, K410 and K420
config PA7300LC
bool "PA7300LC"
help
Select this option for the PCX-L2 processor, as used in the
744, A180, B132L, B160L, B180L, C132L, C160L, C180L,
D220, D230, D320 and D330.
config PA8X00
bool "PA8000 and up"
help
Select this option for PCX-U to PCX-W2 processors.
endchoice
# Define implied options from the CPU selection here
config PA20
def_bool y
depends on PA8X00
config PA11
def_bool y
depends on PA7000 || PA7100LC || PA7200 || PA7300LC
config PREFETCH
def_bool y
depends on PA8X00 || PA7200
config MLONGCALLS
bool "Enable the -mlong-calls compiler option for big kernels"
def_bool y if (!MODULES)
depends on PA8X00
help
If you configure the kernel to include many drivers built-in instead
as modules, the kernel executable may become too big, so that the
linker will not be able to resolve some long branches and fails to link
your vmlinux kernel. In that case enabling this option will help you
to overcome this limit by using the -mlong-calls compiler option.
Usually you want to say N here, unless you e.g. want to build
a kernel which includes all necessary drivers built-in and which can
be used for TFTP booting without the need to have an initrd ramdisk.
Enabling this option will probably slow down your kernel.
config 64BIT
bool "64-bit kernel"
depends on PA8X00
help
Enable this if you want to support 64bit kernel on PA-RISC platform.
At the moment, only people willing to use more than 2GB of RAM,
or having a 64bit-only capable PA-RISC machine should say Y here.
Since there is no 64bit userland on PA-RISC, there is no point to
enable this option otherwise. The 64bit kernel is significantly bigger
and slower than the 32bit one.
choice
prompt "Kernel page size"
default PARISC_PAGE_SIZE_4KB
config PARISC_PAGE_SIZE_4KB
bool "4KB"
help
This lets you select the page size of the kernel. For best
performance, a page size of 16KB is recommended. For best
compatibility with 32bit applications, a page size of 4KB should be
selected (the vast majority of 32bit binaries work perfectly fine
with a larger page size).
4KB For best 32bit compatibility
16KB For best performance
64KB For best performance, might give more overhead.
If you don't know what to do, choose 4KB.
config PARISC_PAGE_SIZE_16KB
bool "16KB"
depends on PA8X00
config PARISC_PAGE_SIZE_64KB
bool "64KB"
depends on PA8X00
endchoice
config SMP
bool "Symmetric multi-processing support"
---help---
This enables support for systems with more than one CPU. If you have
a system with only one CPU, say N. If you have a system with more
than one CPU, say Y.
If you say N here, the kernel will run on uni- and multiprocessor
machines, but will use only one CPU of a multiprocessor machine. If
you say Y here, the kernel will run on many, but not all,
uniprocessor machines. On a uniprocessor machine, the kernel
will run faster if you say N here.
See also <file:Documentation/nmi_watchdog.txt> and the SMP-HOWTO
available at <http://www.tldp.org/docs.html#howto>.
If you don't know what to do here, say N.
config IRQSTACKS
bool "Use separate kernel stacks when processing interrupts"
default y
help
If you say Y here the kernel will use separate kernel stacks
for handling hard and soft interrupts. This can help avoid
overflowing the process kernel stacks.
config HOTPLUG_CPU
bool
default y if SMP
config ARCH_SELECT_MEMORY_MODEL
def_bool y
depends on 64BIT
config ARCH_DISCONTIGMEM_ENABLE
def_bool y
depends on 64BIT
config ARCH_FLATMEM_ENABLE
def_bool y
config ARCH_DISCONTIGMEM_DEFAULT
def_bool y
depends on ARCH_DISCONTIGMEM_ENABLE
config NODES_SHIFT
int
default "3"
depends on NEED_MULTIPLE_NODES
source "kernel/Kconfig.preempt"
source "kernel/Kconfig.hz"
source "mm/Kconfig"
config COMPAT
def_bool y
depends on 64BIT
config SYSVIPC_COMPAT
def_bool y
depends on COMPAT && SYSVIPC
config AUDIT_ARCH
def_bool y
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
depends on SMP
default "32"
endmenu
source "drivers/parisc/Kconfig"
menu "Executable file formats"
source "fs/Kconfig.binfmt"
endmenu
source "net/Kconfig"
source "drivers/Kconfig"
source "fs/Kconfig"
source "arch/parisc/Kconfig.debug"
config SECCOMP
def_bool y
prompt "Enable seccomp to safely compute untrusted bytecode"
---help---
This kernel feature is useful for number crunching applications
that may need to compute untrusted bytecode during their
execution. By using pipes or other transports made available to
the process as file descriptors supporting the read/write
syscalls, it's possible to isolate those applications in
their own address space using seccomp. Once seccomp is
enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
and the task is only allowed to execute a few safe syscalls
defined by each seccomp mode.
If unsure, say Y. Only embedded should say N here.
source "security/Kconfig"
source "crypto/Kconfig"
source "lib/Kconfig"
Reference in New Issue View Git Blame Copy Permalink