* [GIT PULL] Protection Keys (pkeys) support
@ 2016-03-17 8:44 Ingo Molnar
2016-03-21 2:21 ` Linus Torvalds
0 siblings, 1 reply; 5+ messages in thread
From: Ingo Molnar @ 2016-03-17 8:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Dave Hansen, Thomas Gleixner, H. Peter Anvin,
Peter Zijlstra, Andrew Morton, Rik van Riel, Borislav Petkov,
Andy Lutomirski
Linus,
Please pull the latest mm-pkeys-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git mm-pkeys-for-linus
# HEAD: 0d47638f80a02b15869f1fe1fc09e5bf996750fd x86/mm/pkeys: Fix mismerge of protection keys CPUID bits
This tree adds support for a new memory protection hardware feature that is
available in upcoming Intel CPUs: 'protection keys' (pkeys).
There's a background article at LWN.net:
https://lwn.net/Articles/643797/
The gist is that protection keys allow the encoding of user-controllable
permission masks in the pte. So instead of having a fixed protection mask in the
pte (which needs a system call to change and works on a per page basis), the user
can map a (handful of) protection mask variants and can change the masks runtime
relatively cheaply, without having to change every single page in the affected
virtual memory range.
This allows the dynamic switching of the protection bits of large amounts of
virtual memory, via user-space instructions. It also allows more precise control
of MMU permission bits: for example the executable bit is separate from the read
bit (see more about that below).
This tree adds the MM infrastructure and low level x86 glue needed for that, plus
it adds a high level API to make use of protection keys - if a user-space
application calls:
mmap(..., PROT_EXEC);
or
mprotect(ptr, sz, PROT_EXEC);
(note PROT_EXEC-only, without PROT_READ/WRITE), the kernel will notice this
special case, and will set a special protection key on this memory range. It also
sets the appropriate bits in the Protection Keys User Rights (PKRU) register so
that the memory becomes unreadable and unwritable.
So using protection keys the kernel is able to implement 'true' PROT_EXEC on x86
CPUs: without protection keys PROT_EXEC implies PROT_READ as well. Unreadable
executable mappings have security advantages: they cannot be read via information
leaks to figure out ASLR details, nor can they be scanned for ROP gadgets - and
they cannot be used by exploits for data purposes either.
We know about no user-space code that relies on pure PROT_EXEC mappings today, but
binary loaders could start making use of this new feature to map binaries and
libraries in a more secure fashion.
There is other pending pkeys work that offers more high level system call APIs to
manage protection keys - but those are not part of this pull request.
Right now there's a Kconfig that controls this feature
(CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS) that is default enabled (like most x86
CPU feature enablement code that has no runtime overhead), but it's not
user-configurable at the moment. If there's any serious problem with this then we
can make it configurable and/or flip the default.
Thanks,
Ingo
---{ shortlog and diffstat generated manually }--------------->
Dave Hansen (38):
mm/gup: Introduce get_user_pages_remote()
mm/gup: Overload get_user_pages() functions
mm/gup: Switch all callers of get_user_pages() to not pass tsk/mm
x86/fpu: Add placeholder for 'Processor Trace' XSAVE state
x86/mm/pkeys: Add Kconfig option
x86/cpufeature, x86/mm/pkeys: Add protection keys related CPUID definitions
x86/cpu, x86/mm/pkeys: Define new CR4 bit
x86/fpu, x86/mm/pkeys: Add PKRU xsave fields and data structures
x86/mm/pkeys: Add PTE bits for storing protection key
x86/mm/pkeys: Add new 'PF_PK' page fault error code bit
mm/core, x86/mm/pkeys: Store protection bits in high VMA flags
x86/mm/pkeys: Add arch-specific VMA protection bits
x86/mm/pkeys: Pass VMA down in to fault signal generation code
signals, ia64, mips: Update arch-specific siginfos with pkeys field
signals, pkeys: Notify userspace about protection key faults
x86/mm/pkeys: Fill in pkey field in siginfo
x86/mm/pkeys: Add functions to fetch PKRU
mm/gup: Factor out VMA fault permission checking
x86/mm/gup: Simplify get_user_pages() PTE bit handling
mm/gup, x86/mm/pkeys: Check VMAs and PTEs for protection keys
um, pkeys: Add UML arch_*_access_permitted() methods
mm/core: Do not enforce PKEY permissions on remote mm access
x86/mm/pkeys: Optimize fault handling in access_error()
mm/core, x86/mm/pkeys: Differentiate instruction fetches
x86/mm/pkeys: Dump PKRU with other kernel registers
x86/mm/pkeys: Dump pkey from VMA in /proc/pid/smaps
x86/mm/pkeys: Add Kconfig prompt to existing config option
x86/mm/pkeys: Actually enable Memory Protection Keys in the CPU
mm/core, arch, powerpc: Pass a protection key in to calc_vm_flag_bits()
mm/core, x86/mm/pkeys: Add arch_validate_pkey()
x86/mm: Factor out LDT init from context init
x86/fpu: Allow setting of XSAVE state
x86/mm/pkeys: Allow kernel to modify user pkey rights register
x86/mm/pkeys: Create an x86 arch_calc_vm_prot_bits() for VMA flags
mm/core, x86/mm/pkeys: Add execute-only protection keys support
x86/mm/pkeys: Fix access_error() denial of writes to write-only VMA
mm/pkeys: Fix siginfo ABI breakage caused by new u64 field
x86/mm/pkeys: Fix mismerge of protection keys CPUID bits
Ingo Molnar (1):
Merge branches 'x86/fpu', 'x86/mm' and 'x86/asm' into x86/pkeys
Documentation/kernel-parameters.txt | 3 +++
arch/cris/arch-v32/drivers/cryptocop.c | 8 ++----
arch/ia64/include/uapi/asm/siginfo.h | 13 +++++++---
arch/ia64/kernel/err_inject.c | 3 +--
arch/mips/include/uapi/asm/siginfo.h | 13 +++++++---
arch/mips/mm/gup.c | 3 +--
arch/powerpc/include/asm/mman.h | 5 ++--
arch/powerpc/include/asm/mmu_context.h | 12 +++++++++
arch/s390/include/asm/mmu_context.h | 12 +++++++++
arch/s390/mm/gup.c | 4 +--
arch/sh/mm/gup.c | 2 +-
arch/sparc/mm/gup.c | 2 +-
arch/um/include/asm/mmu_context.h | 14 ++++++++++
arch/unicore32/include/asm/mmu_context.h | 12 +++++++++
arch/x86/Kconfig | 16 ++++++++++++
arch/x86/include/asm/cpufeature.h | 55 +++++++++++++++++++++++++--------------
arch/x86/include/asm/cpufeatures.h | 6 ++++-
arch/x86/include/asm/disabled-features.h | 15 +++++++++++
arch/x86/include/asm/fpu/internal.h | 2 ++
arch/x86/include/asm/fpu/types.h | 12 +++++++++
arch/x86/include/asm/fpu/xstate.h | 3 ++-
arch/x86/include/asm/mmu_context.h | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
arch/x86/include/asm/pgtable.h | 38 +++++++++++++++++++++++++++
arch/x86/include/asm/pgtable_types.h | 39 ++++++++++++++++++++++++----
arch/x86/include/asm/pkeys.h | 34 ++++++++++++++++++++++++
arch/x86/include/asm/required-features.h | 7 +++++
arch/x86/include/asm/special_insns.h | 22 ++++++++++++++++
arch/x86/include/uapi/asm/mman.h | 22 ++++++++++++++++
arch/x86/include/uapi/asm/processor-flags.h | 2 ++
arch/x86/kernel/cpu/common.c | 44 +++++++++++++++++++++++++++++++
arch/x86/kernel/fpu/core.c | 63 ++++++++++++++++++++++++++++++++++++++++++++
arch/x86/kernel/fpu/xstate.c | 185 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
arch/x86/kernel/ldt.c | 4 +--
arch/x86/kernel/process_64.c | 2 ++
arch/x86/kernel/setup.c | 9 +++++++
arch/x86/mm/Makefile | 2 ++
arch/x86/mm/fault.c | 150 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------
arch/x86/mm/gup.c | 45 ++++++++++++++++++++------------
arch/x86/mm/mpx.c | 4 +--
arch/x86/mm/pkeys.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/char/agp/frontend.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +--
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 6 ++---
drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +++----
drivers/gpu/drm/radeon/radeon_ttm.c | 3 +--
drivers/gpu/drm/via/via_dmablit.c | 3 +--
drivers/infiniband/core/umem.c | 2 +-
drivers/infiniband/core/umem_odp.c | 8 +++---
drivers/infiniband/hw/mthca/mthca_memfree.c | 3 +--
drivers/infiniband/hw/qib/qib_user_pages.c | 3 +--
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +-
drivers/iommu/amd_iommu_v2.c | 1 +
drivers/media/pci/ivtv/ivtv-udma.c | 4 +--
drivers/media/pci/ivtv/ivtv-yuv.c | 10 +++----
drivers/media/v4l2-core/videobuf-dma-sg.c | 3 +--
drivers/misc/mic/scif/scif_rma.c | 2 --
drivers/misc/sgi-gru/grufault.c | 3 +--
drivers/scsi/st.c | 2 --
drivers/staging/android/ashmem.c | 4 +--
drivers/video/fbdev/pvr2fb.c | 4 +--
drivers/virt/fsl_hypervisor.c | 5 ++--
fs/exec.c | 8 ++++--
fs/proc/task_mmu.c | 14 ++++++++++
include/asm-generic/mm_hooks.h | 12 +++++++++
include/linux/mm.h | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------
include/linux/mman.h | 6 ++---
include/linux/pkeys.h | 33 ++++++++++++++++++++++++
include/uapi/asm-generic/siginfo.h | 17 ++++++++----
kernel/events/uprobes.c | 10 +++++--
kernel/signal.c | 4 +++
mm/Kconfig | 5 ++++
mm/frame_vector.c | 2 +-
mm/gup.c | 127 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------
mm/ksm.c | 12 ++++++---
mm/memory.c | 8 +++++-
mm/mempolicy.c | 6 ++---
mm/mmap.c | 10 ++++++-
mm/mprotect.c | 8 +++---
mm/nommu.c | 66 +++++++++++++++++++++++++++++++++--------------
mm/process_vm_access.c | 11 +++++---
mm/util.c | 4 +--
net/ceph/pagevec.c | 2 +-
security/tomoyo/domain.c | 9 ++++++-
virt/kvm/async_pf.c | 8 +++++-
virt/kvm/kvm_main.c | 10 +++----
85 files changed, 1406 insertions(+), 241 deletions(-)
create mode 100644 arch/x86/include/asm/pkeys.h
create mode 100644 arch/x86/mm/pkeys.c
create mode 100644 include/linux/pkeys.h
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PULL] Protection Keys (pkeys) support
2016-03-17 8:44 [GIT PULL] Protection Keys (pkeys) support Ingo Molnar
@ 2016-03-21 2:21 ` Linus Torvalds
2016-03-21 7:34 ` Ingo Molnar
0 siblings, 1 reply; 5+ messages in thread
From: Linus Torvalds @ 2016-03-21 2:21 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linux Kernel Mailing List, Dave Hansen, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Andrew Morton, Rik van Riel,
Borislav Petkov, Andy Lutomirski
So I finally got around to this one and the objtool pull request, and
note that there's a conflict in the arch/x86/Kconfig file.
And I'm not sending this email because the conflict would have been
hard to resolve - it was completely trivial. But the conflict does
show that once again people are starting to add the new options to the
end of the list, even though that list is supposedly sorted.
HOWEVER.
I didn't actually fix that up in the merge, because I think that those
options should be done differently anyway.
So all of these are under the "X86" config options as "select"
statements that are true for x86. However, all the new ones (and an
alarming number of old ones) aren't actually really "these are true
for x86". No, they are *conditionally* true for x86.
For example, if we were to sort those thing, the two PKEY-related
options would have to be split up:
select ARCH_USES_HIGH_VMA_FLAGS if
X86_INTEL_MEMORY_PROTECTION_KEYS
select ARCH_HAS_PKEYS if
X86_INTEL_MEMORY_PROTECTION_KEYS
which would actually make it really nasty to see that they are related.
There's also a *lot* of those X86 selects that are "if X86_64". So
they really aren't x86 options, they are x86-64 options.
So instead of having a _huge_ list of select statements under the X86
option, why aren't those split up, and the select statements are
closer to the thing that actually controls them.
I realize that for many *common* options that really are "this
architecture uses the generic XYZ feature", the current "select" model
is really good. But it's starting to look really quite nasty for some
of these more specialized options, and I really think it would be
better to move (for example) the select for ARCH_HAS_PKEYS and
ARCH_USES_HIGH_VMA_FLAGS to actually be under the
X86_INTEL_MEMORY_PROTECTION_KEYS config option, rather than try to lie
and make it look like this is somehow some "x86 feature". It's much
more specific than that.
Anyway, it's all merged in my tree, but is going through the built
tests and I'll do a boot test too before pushing out. So no need to do
anything wrt these pull requests, this was more of a "Hmm, I really
think the x86 Kconfig file is getting pretty nasty".
Linus
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PULL] Protection Keys (pkeys) support
2016-03-21 2:21 ` Linus Torvalds
@ 2016-03-21 7:34 ` Ingo Molnar
2016-03-21 16:21 ` Linus Torvalds
0 siblings, 1 reply; 5+ messages in thread
From: Ingo Molnar @ 2016-03-21 7:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Dave Hansen, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Andrew Morton, Rik van Riel,
Borislav Petkov, Andy Lutomirski
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> So I finally got around to this one and the objtool pull request, and
> note that there's a conflict in the arch/x86/Kconfig file.
>
> And I'm not sending this email because the conflict would have been
> hard to resolve - it was completely trivial. But the conflict does
> show that once again people are starting to add the new options to the
> end of the list, even though that list is supposedly sorted.
>
> HOWEVER.
>
> I didn't actually fix that up in the merge, because I think that those
> options should be done differently anyway.
>
> So all of these are under the "X86" config options as "select"
> statements that are true for x86. However, all the new ones (and an
> alarming number of old ones) aren't actually really "these are true
> for x86". No, they are *conditionally* true for x86.
>
> For example, if we were to sort those thing, the two PKEY-related
> options would have to be split up:
>
> select ARCH_USES_HIGH_VMA_FLAGS if
> X86_INTEL_MEMORY_PROTECTION_KEYS
> select ARCH_HAS_PKEYS if
> X86_INTEL_MEMORY_PROTECTION_KEYS
>
> which would actually make it really nasty to see that they are related.
>
> There's also a *lot* of those X86 selects that are "if X86_64". So
> they really aren't x86 options, they are x86-64 options.
>
> So instead of having a _huge_ list of select statements under the X86
> option, why aren't those split up, and the select statements are
> closer to the thing that actually controls them.
>
> I realize that for many *common* options that really are "this
> architecture uses the generic XYZ feature", the current "select" model
> is really good. But it's starting to look really quite nasty for some
> of these more specialized options, and I really think it would be
> better to move (for example) the select for ARCH_HAS_PKEYS and
> ARCH_USES_HIGH_VMA_FLAGS to actually be under the
> X86_INTEL_MEMORY_PROTECTION_KEYS config option, rather than try to lie
> and make it look like this is somehow some "x86 feature". It's much
> more specific than that.
Agreed absolutely - I didn't notice that these two new options were misplaced.
That long list under the x86 option is supposed to be there only for 'pure'
options that only depend on the bitness. The single unified 'table' of options
replaces former hard to read/maintain duplicates like:
config X86_32
...
select HAVE_CMPXCHG_LOCAL
...
[a couple of pages further down]
config X86_64
...
select HAVE_CMPXCHG_LOCAL
...
Also, the 'if X86_64' part is supposed to be for features where the dependency is
a 'maintainer decision/option', not an 'architecture necessity'.
So for example:
select ARCH_HAS_PMEM_API if X86_64
select HAVE_BPF_JIT if X86_64
select HAVE_CONTEXT_TRACKING if X86_64
are 'optional features' that are 64-bit because they are not implemented for
x86-32 yet.
while bits like:
select CLONE_BACKWARDS if X86_32
select ARCH_WANT_IPC_PARSE_VERSION if X86_32
select ARCH_SUPPORTS_INT128 if X86_64
are more 'fundamental' architecture properties that probably won't change in the
future.
The list was also supposed to be sorted by name originally, to make the likelihood
of collisions/conflicts lower...
All of which rules I broke when I applied the pkeys bits :-/
> Anyway, it's all merged in my tree, but is going through the built tests and
> I'll do a boot test too before pushing out. So no need to do anything wrt these
> pull requests, this was more of a "Hmm, I really think the x86 Kconfig file is
> getting pretty nasty".
Yeah, so I think the way I'd solve the pkeys problem is the patch attached below.
Eventually, if 'protection keys' becomes a generic option configured in mm/Kconfig
or so, then we could turn this into a pure architecture select - but not now.
Furthermore, I'd reorganize the 'arch settings' section into 4 groups, the
following way:
1)
#
# Options that are fundamentally only set on x86-32 kernels:
#
config X86_32
select CLONE_BACKWARDS
select ARCH_WANT_IPC_PARSE_VERSION
...
2)
#
# Options that are fundamentally only set on x86-64 kernels:
#
config X86_64
select ARCH_SUPPORTS_INT128
...
3)
#
# Bi-arch options and options that are not yet implemented for both
# x86 bit widths, sorted alphabetically:
#
config X86
select ANON_INODES
...
select ARCH_HAS_PMEM_API if X86_64
select ARCH_SUPPORTS_NUMA_BALANCING if X86_64
select ARCH_USE_BUILTIN_BSWAP
all other options are moved out.
Furthermore, some options have unnecessary dependencies, such as:
select ACPI_LEGACY_TABLES_LOOKUP if ACPI
select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
these could lose the 'if ACPI' part - those options don't make a difference when
ACPI is disabled.
4)
All other options, such as:
select COMPAT_OLD_SIGACTION if IA32_EMULATION
select X86_DEV_DMA_OPS if X86_64
select X86_FEATURE_NAMES if PROC_FS
are moved as selects to their respective config entries.
In the end for 'config X86' we'd have a clean list of options that are only
restricted to any of the bitness variants if that restriction is 'optional', i.e.
we might reasonably expect the other bitness to be supported in the feature.
Do you agree with such an approach?
Thanks,
Ingo
=================>
arch/x86/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8b680a5cb25b..ada9c64cabca 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -156,8 +156,6 @@ config X86
select X86_DEV_DMA_OPS if X86_64
select X86_FEATURE_NAMES if PROC_FS
select HAVE_STACK_VALIDATION if X86_64
- select ARCH_USES_HIGH_VMA_FLAGS if X86_INTEL_MEMORY_PROTECTION_KEYS
- select ARCH_HAS_PKEYS if X86_INTEL_MEMORY_PROTECTION_KEYS
config INSTRUCTION_DECODER
def_bool y
@@ -1726,6 +1724,8 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
def_bool y
# Note: only available in 64-bit mode
depends on CPU_SUP_INTEL && X86_64
+ select ARCH_USES_HIGH_VMA_FLAGS
+ select ARCH_HAS_PKEYS
---help---
Memory Protection Keys provides a mechanism for enforcing
page-based protections, but without requiring modification of the
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [GIT PULL] Protection Keys (pkeys) support
2016-03-21 7:34 ` Ingo Molnar
@ 2016-03-21 16:21 ` Linus Torvalds
2016-11-15 10:42 ` Ingo Molnar
0 siblings, 1 reply; 5+ messages in thread
From: Linus Torvalds @ 2016-03-21 16:21 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linux Kernel Mailing List, Dave Hansen, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Andrew Morton, Rik van Riel,
Borislav Petkov, Andy Lutomirski
On Mon, Mar 21, 2016 at 12:34 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> Furthermore, I'd reorganize the 'arch settings' section into 4 groups, the
> following way:
>
> 1) Options that are fundamentally only set on x86-32 kernels:
>
> 2) Options that are fundamentally only set on x86-64 kernels:
>
> 3) Bi-arch options and options that are not yet implemented for both
>
> 4) All other options are moved as selects to their respective config entries.
Yes, that sounds much better than what we have now.
Thanks,
Linus
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PULL] Protection Keys (pkeys) support
2016-03-21 16:21 ` Linus Torvalds
@ 2016-11-15 10:42 ` Ingo Molnar
0 siblings, 0 replies; 5+ messages in thread
From: Ingo Molnar @ 2016-11-15 10:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Dave Hansen, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Andrew Morton, Rik van Riel,
Borislav Petkov, Andy Lutomirski
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, Mar 21, 2016 at 12:34 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > Furthermore, I'd reorganize the 'arch settings' section into 4 groups, the
> > following way:
> >
> > 1) Options that are fundamentally only set on x86-32 kernels:
> >
> > 2) Options that are fundamentally only set on x86-64 kernels:
> >
> > 3) Bi-arch options and options that are not yet implemented for both
> >
> > 4) All other options are moved as selects to their respective config entries.
>
> Yes, that sounds much better than what we have now.
... a late update a few months later:
JFYI, I've pushed out a series of changes that implements all this:
c763ea2650df x86/kconfig: Sort the 'config X86' selects alphabetically
953fee1d82f3 x86/kconfig: Clean up 32-bit compat options
39f88911b9dc x86/kconfig: Clean up IA32_EMULATION select
52c8e6017c76 x86/kconfig, x86/pkeys: Move pkeys selects to X86_INTEL_MEMORY_PROTECTION_KEYS
d94e068573f2 x86/kconfig: Move 64-bit only arch Kconfig selects to 'config X86_64'
341c787e34af x86/kconfig: Move 32-bit only arch Kconfig selects to 'config X86_32'
Combo patch is below. Full tree can be found at:
git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/build
The remaining 'if X86_64' options are all features that are selected for the
64-bit kernel but could be used on the 32-bit kernel as well (just nobody bothered
porting it yet). I kept those in the generic section for the time being.
Thanks,
Ingo
---
arch/x86/Kconfig | 68 ++++++++++++++++++++++++++++++++++----------------------
1 file changed, 41 insertions(+), 27 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636d1065..e01f101d4413 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -9,28 +9,50 @@ config 64BIT
config X86_32
def_bool y
depends on !64BIT
+ # Options that are inherently 32-bit kernel only:
+ select ARCH_WANT_IPC_PARSE_VERSION
+ select CLKSRC_I8253
+ select CLONE_BACKWARDS
+ select HAVE_AOUT
+ select HAVE_GENERIC_DMA_COHERENT
+ select MODULES_USE_ELF_REL
+ select OLD_SIGACTION
config X86_64
def_bool y
depends on 64BIT
+ # Options that are inherently 64-bit kernel only:
+ select ARCH_HAS_GIGANTIC_PAGE
+ select ARCH_SUPPORTS_INT128
+ select ARCH_USE_CMPXCHG_LOCKREF
+ select HAVE_ARCH_SOFT_DIRTY
+ select MODULES_USE_ELF_RELA
+ select X86_DEV_DMA_OPS
-### Arch settings
+#
+# Arch settings
+#
+# ( Note that options that are marked 'if X86_64' could in principle be
+# ported to 32-bit as well. )
+#
config X86
def_bool y
+ #
+ # Note: keep this list sorted alphabetically
+ #
select ACPI_LEGACY_TABLES_LOOKUP if ACPI
select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
select ANON_INODES
select ARCH_CLOCKSOURCE_DATA
select ARCH_DISCARD_MEMBLOCK
- select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
+ select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_GCOV_PROFILE_ALL
- select ARCH_HAS_GIGANTIC_PAGE if X86_64
select ARCH_HAS_KCOV if X86_64
- select ARCH_HAS_PMEM_API if X86_64
select ARCH_HAS_MMIO_FLUSH
+ select ARCH_HAS_PMEM_API if X86_64
select ARCH_HAS_SG_CHAIN
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_HAVE_NMI_SAFE_CMPXCHG
@@ -39,23 +61,17 @@ config X86
select ARCH_MIGHT_HAVE_PC_SERIO
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
- select ARCH_SUPPORTS_INT128 if X86_64
select ARCH_SUPPORTS_NUMA_BALANCING if X86_64
select ARCH_USE_BUILTIN_BSWAP
- select ARCH_USE_CMPXCHG_LOCKREF if X86_64
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH if SMP
- select ARCH_WANTS_DYNAMIC_TASK_STRUCT
select ARCH_WANT_FRAME_POINTERS
- select ARCH_WANT_IPC_PARSE_VERSION if X86_32
+ select ARCH_WANTS_DYNAMIC_TASK_STRUCT
select BUILDTIME_EXTABLE_SORT
select CLKEVT_I8253
- select CLKSRC_I8253 if X86_32
select CLOCKSOURCE_VALIDATE_LAST_CYCLE
select CLOCKSOURCE_WATCHDOG
- select CLONE_BACKWARDS if X86_32
- select COMPAT_OLD_SIGACTION if IA32_EMULATION
select DCACHE_WORD_ACCESS
select EDAC_ATOMIC_SCRUB
select EDAC_SUPPORT
@@ -77,7 +93,6 @@ config X86
select HAVE_ACPI_APEI if ACPI
select HAVE_ACPI_APEI_NMI if ACPI
select HAVE_ALIGNED_STRUCT_PAGE if SLUB
- select HAVE_AOUT if X86_32
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_HARDENED_USERCOPY
select HAVE_ARCH_HUGE_VMAP if X86_64 || X86_PAE
@@ -88,12 +103,10 @@ config X86
select HAVE_ARCH_MMAP_RND_BITS if MMU
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT
select HAVE_ARCH_SECCOMP_FILTER
- select HAVE_ARCH_SOFT_DIRTY if X86_64
select HAVE_ARCH_TRACEHOOK
select HAVE_ARCH_TRANSPARENT_HUGEPAGE
- select HAVE_ARCH_WITHIN_STACK_FRAMES
- select HAVE_EBPF_JIT if X86_64
select HAVE_ARCH_VMAP_STACK if X86_64
+ select HAVE_ARCH_WITHIN_STACK_FRAMES
select HAVE_CC_STACKPROTECTOR
select HAVE_CMPXCHG_DOUBLE
select HAVE_CMPXCHG_LOCAL
@@ -106,6 +119,7 @@ config X86
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
select HAVE_DYNAMIC_FTRACE_WITH_REGS
+ select HAVE_EBPF_JIT if X86_64
select HAVE_EFFICIENT_UNALIGNED_ACCESS
select HAVE_EXIT_THREAD
select HAVE_FENTRY if X86_64
@@ -113,7 +127,6 @@ config X86
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
select HAVE_GCC_PLUGINS
- select HAVE_GENERIC_DMA_COHERENT if X86_32
select HAVE_HW_BREAKPOINT
select HAVE_IDE
select HAVE_IOREMAP_PROT
@@ -142,15 +155,11 @@ config X86
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
select HAVE_REGS_AND_STACK_ACCESS_API
+ select HAVE_STACK_VALIDATION if X86_64
select HAVE_SYSCALL_TRACEPOINTS
- select HAVE_UID16 if X86_32 || IA32_EMULATION
select HAVE_UNSTABLE_SCHED_CLOCK
select HAVE_USER_RETURN_NOTIFIER
select IRQ_FORCED_THREADING
- select MODULES_USE_ELF_RELA if X86_64
- select MODULES_USE_ELF_REL if X86_32
- select OLD_SIGACTION if X86_32
- select OLD_SIGSUSPEND3 if X86_32 || IA32_EMULATION
select PERF_EVENTS
select RTC_LIB
select RTC_MC146818_LIB
@@ -160,11 +169,7 @@ config X86
select THREAD_INFO_IN_TASK
select USER_STACKTRACE_SUPPORT
select VIRT_TO_BUS
- select X86_DEV_DMA_OPS if X86_64
select X86_FEATURE_NAMES if PROC_FS
- select HAVE_STACK_VALIDATION if X86_64
- select ARCH_USES_HIGH_VMA_FLAGS if X86_INTEL_MEMORY_PROTECTION_KEYS
- select ARCH_HAS_PKEYS if X86_INTEL_MEMORY_PROTECTION_KEYS
config INSTRUCTION_DECODER
def_bool y
@@ -1737,6 +1742,8 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
def_bool y
# Note: only available in 64-bit mode
depends on CPU_SUP_INTEL && X86_64
+ select ARCH_USES_HIGH_VMA_FLAGS
+ select ARCH_HAS_PKEYS
---help---
Memory Protection Keys provides a mechanism for enforcing
page-based protections, but without requiring modification of the
@@ -2092,7 +2099,7 @@ config DEBUG_HOTPLUG_CPU0
config COMPAT_VDSO
def_bool n
prompt "Disable the 32-bit vDSO (needed for glibc 2.3.3)"
- depends on X86_32 || IA32_EMULATION
+ depends on COMPAT_32
---help---
Certain buggy versions of glibc will crash if they are
presented with a 32-bit vDSO that is not mapped at the address
@@ -2694,9 +2701,10 @@ source "fs/Kconfig.binfmt"
config IA32_EMULATION
bool "IA32 Emulation"
depends on X86_64
+ select ARCH_WANT_OLD_COMPAT_IPC
select BINFMT_ELF
select COMPAT_BINFMT_ELF
- select ARCH_WANT_OLD_COMPAT_IPC
+ select COMPAT_OLD_SIGACTION
---help---
Include code to run legacy 32-bit programs under a
64-bit kernel. You should likely turn this on, unless you're
@@ -2721,6 +2729,12 @@ config X86_X32
elf32_x86_64 support enabled to compile a kernel with this
option set.
+config COMPAT_32
+ def_bool y
+ depends on IA32_EMULATION || X86_32
+ select HAVE_UID16
+ select OLD_SIGSUSPEND3
+
config COMPAT
def_bool y
depends on IA32_EMULATION || X86_X32
^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-11-15 10:42 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-17 8:44 [GIT PULL] Protection Keys (pkeys) support Ingo Molnar
2016-03-21 2:21 ` Linus Torvalds
2016-03-21 7:34 ` Ingo Molnar
2016-03-21 16:21 ` Linus Torvalds
2016-11-15 10:42 ` Ingo Molnar
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.