]> git.karo-electronics.de Git - karo-tx-linux.git/blobdiff - arch/x86/Kconfig
Merge remote-tracking branch 'tip/auto-latest'
[karo-tx-linux.git] / arch / x86 / Kconfig
index e0836de76f3c90dcb57ec0e7bbfb293cb7d0ca99..591b19ec8af8216954888958c315195e3fe14ce4 100644 (file)
@@ -124,6 +124,7 @@ config X86
        select COMPAT_OLD_SIGACTION if IA32_EMULATION
        select RTC_LIB
        select HAVE_DEBUG_STACKOVERFLOW
+       select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
 
 config INSTRUCTION_DECODER
        def_bool y
@@ -753,20 +754,25 @@ config DMI
          BIOS code.
 
 config GART_IOMMU
-       bool "GART IOMMU support" if EXPERT
-       default y
+       bool "Old AMD GART IOMMU support"
        select SWIOTLB
        depends on X86_64 && PCI && AMD_NB
        ---help---
-         Support for full DMA access of devices with 32bit memory access only
-         on systems with more than 3GB. This is usually needed for USB,
-         sound, many IDE/SATA chipsets and some other devices.
-         Provides a driver for the AMD Athlon64/Opteron/Turion/Sempron GART
-         based hardware IOMMU and a software bounce buffer based IOMMU used
-         on Intel systems and as fallback.
-         The code is only active when needed (enough memory and limited
-         device) unless CONFIG_IOMMU_DEBUG or iommu=force is specified
-         too.
+         Provides a driver for older AMD Athlon64/Opteron/Turion/Sempron
+         GART based hardware IOMMUs.
+
+         The GART supports full DMA access for devices with 32-bit access
+         limitations, on systems with more than 3 GB. This is usually needed
+         for USB, sound, many IDE/SATA chipsets and some other devices.
+
+         Newer systems typically have a modern AMD IOMMU, supported via
+         the CONFIG_AMD_IOMMU=y config option.
+
+         In normal configurations this driver is only active when needed:
+         there's more than 3 GB of memory and the system contains a
+         32-bit limited device.
+
+         If unsure, say Y.
 
 config CALGARY_IOMMU
        bool "IBM Calgary IOMMU support"
@@ -1591,7 +1597,7 @@ config EFI_STUB
           This kernel feature allows a bzImage to be loaded directly
          by EFI firmware without the use of a bootloader.
 
-         See Documentation/x86/efi-stub.txt for more information.
+         See Documentation/efi-stub.txt for more information.
 
 config SECCOMP
        def_bool y
@@ -1720,16 +1726,56 @@ config RELOCATABLE
 
          Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address
          it has been loaded at and the compile time physical address
-         (CONFIG_PHYSICAL_START) is ignored.
+         (CONFIG_PHYSICAL_START) is used as the minimum location.
 
-# Relocation on x86-32 needs some additional build support
+config RANDOMIZE_BASE
+       bool "Randomize the address of the kernel image"
+       depends on RELOCATABLE
+       depends on !HIBERNATION
+       default n
+       ---help---
+          Randomizes the physical and virtual address at which the
+          kernel image is decompressed, as a security feature that
+          deters exploit attempts relying on knowledge of the location
+          of kernel internals.
+
+          Entropy is generated using the RDRAND instruction if it
+          is supported.  If not, then RDTSC is used, if supported. If
+          neither RDRAND nor RDTSC are supported, then no randomness
+          is introduced.
+
+          The kernel will be offset by up to RANDOMIZE_BASE_MAX_OFFSET,
+          and aligned according to PHYSICAL_ALIGN.
+
+config RANDOMIZE_BASE_MAX_OFFSET
+       hex "Maximum ASLR offset allowed"
+       depends on RANDOMIZE_BASE
+       range 0x0 0x20000000 if X86_32
+       default "0x20000000" if X86_32
+       range 0x0 0x40000000 if X86_64
+       default "0x40000000" if X86_64
+       ---help---
+        Determines the maximal offset in bytes that will be applied to the
+        kernel when Address Space Layout Randomization (ASLR) is active.
+        Must be less than or equal to the actual physical memory on the
+        system. This must be a multiple of CONFIG_PHYSICAL_ALIGN.
+
+        On 32-bit this is limited to 512MiB.
+
+        On 64-bit this is limited by how the kernel fixmap page table is
+        positioned, so this cannot be larger that 1GiB currently. Normally
+        there is a 512MiB to 1.5GiB split between kernel and modules. When
+        this is raised above the 512MiB default, the modules area will
+        shrink to compensate, up to the current maximum 1GiB to 1GiB split.
+
+# Relocation on x86 needs some additional build support
 config X86_NEED_RELOCS
        def_bool y
-       depends on X86_32 && RELOCATABLE
+       depends on RANDOMIZE_BASE || (X86_32 && RELOCATABLE)
 
 config PHYSICAL_ALIGN
        hex "Alignment value to which kernel should be aligned"
-       default "0x1000000"
+       default "0x200000"
        range 0x2000 0x1000000 if X86_32
        range 0x200000 0x1000000 if X86_64
        ---help---