selftests/x86/avx: Add AVX tests

Add xstate testing specifically for those vector register states,
validating kernel's context switching and ensuring ABI compliance.
Use the established xstate testi

selftests/x86/avx: Add AVX tests

Add xstate testing specifically for those vector register states,
validating kernel's context switching and ensuring ABI compliance.
Use the established xstate testing framework.

Alternatively, this invocation could be placed directly in
xstate.c::main(). However, the current test file naming convention, which
clearly specifies the tested area, seems reasonable. Adding avx.c
considerably aligns with that convention.

The test output should be like this for ZMM_Hi256 as an example:

$ avx_64
...
[RUN] AVX-512 ZMM_Hi256: check context switches, 10 iterations, 5 threads.
[OK] No incorrect case was found.
[RUN] AVX-512 ZMM_Hi256: inject xstate via ptrace().
[OK] 'xfeatures' in SW reserved area was correctly written
[OK] xstate was correctly updated.
[RUN] AVX-512 ZMM_Hi256: load xstate and raise SIGUSR1
[OK] 'magic1' is valid
[OK] 'xfeatures' in SW reserved area is valid
[OK] 'xfeatures' in XSAVE header is valid
[OK] xstate delivery was successful
[OK] 'magic2' is valid
[RUN] AVX-512 ZMM_Hi256: load new xstate from sighandler and check it after sigreturn
[OK] xstate was restored correctly

But systems without AVX-512 will look like:
...
The kernel does not support feature number: 5
The kernel does not support feature number: 6
The kernel does not support feature number: 7

Signed-off-by: Chang S. Bae <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

selftests/x86/xstate: Refactor context switching test

The existing context switching and ptrace tests in amx.c are not specific
to dynamic states, making them reusable for general xstate testing.

A

selftests/x86/xstate: Refactor context switching test

The existing context switching and ptrace tests in amx.c are not specific
to dynamic states, making them reusable for general xstate testing.

As a first step, move the context switching test to xstate.c. Refactor
the test code to allow specifying which xstate component being tested.

To decouple the test from dynamic states, remove the permission request
code. In fact, The permission request inside the test wrapper was
redundant.

Additionally, replace fatal_error() with ksft_exit_fail_msg() for
consistency in error handling.

Expected output:
$ amx_64
...
[RUN] AMX Tile data: check context switches, 10 iterations, 5 threads.
[OK] No incorrect case was found.

Signed-off-by: Chang S. Bae <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

Documentation/srso: Document a method for checking safe RET operates properly

Add a method to quickly verify whether safe RET operates properly on
a given system using perf tool.

Also, add a selfte

Documentation/srso: Document a method for checking safe RET operates properly

Add a method to quickly verify whether safe RET operates properly on
a given system using perf tool.

Also, add a selftest which does the same thing.

Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

selftests/x86: avoid -no-pie warnings from clang during compilation

When building with clang, via:

make LLVM=1 -C tools/testing/selftests

...clang warns that -no-pie is "unused during compilat

selftests/x86: avoid -no-pie warnings from clang during compilation

When building with clang, via:

make LLVM=1 -C tools/testing/selftests

...clang warns that -no-pie is "unused during compilation".

This occurs because clang only wants to see -no-pie during linking.
Here, we don't have a separate linking stage, so a compiler warning is
unavoidable without (wastefully) restructuring the Makefile.

Avoid the warning by simply disabling that warning, for clang builds.

Acked-by: Muhammad Usama Anjum <[email protected]>
Signed-off-by: John Hubbard <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

selftests/x86: build sysret_rip.c with clang

When building with clang, via:

make LLVM=1 -C tools/testing/selftests

...the build fails because clang's inline asm doesn't support all of the
feat

selftests/x86: build sysret_rip.c with clang

When building with clang, via:

make LLVM=1 -C tools/testing/selftests

...the build fails because clang's inline asm doesn't support all of the
features that are used in the asm() snippet in sysret_rip.c.

Fix this by moving the asm code into the clang_helpers_64.S file, where
it can be built with the assembler's full set of features.

Acked-by: Muhammad Usama Anjum <[email protected]>
Signed-off-by: John Hubbard <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

selftests/x86: build fsgsbase_restore.c with clang

When building with clang, via:

make LLVM=1 -C tools/testing/selftests

Fix this by moving the inline asm to "pure" assembly, in two new files:

selftests/x86: build fsgsbase_restore.c with clang

When building with clang, via:

make LLVM=1 -C tools/testing/selftests

Fix this by moving the inline asm to "pure" assembly, in two new files:
clang_helpers_32.S, clang_helpers_64.S.

As a bonus, the pure asm avoids the need for ifdefs, and is now very
simple and easy on the eyes.

Acked-by: Muhammad Usama Anjum <[email protected]>
Signed-off-by: John Hubbard <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

selftests/x86: fix Makefile dependencies to work with clang

When building with clang, via:

make LLVM=1 -C tools/testing/selftests

...the following build failure occurs in selftests/x86:

cl

selftests/x86: fix Makefile dependencies to work with clang

When building with clang, via:

make LLVM=1 -C tools/testing/selftests

...the following build failure occurs in selftests/x86:

clang: error: cannot specify -o when generating multiple output files

This happens because, although gcc doesn't complain if you invoke it
like this:

gcc file1.c header2.h

...clang won't accept that form--it rejects the .h file(s). Also, the
above approach is inaccurate anyway, because file.c includes header2.h
in this case, and the inclusion of header2.h on the invocation is an
artifact of the Makefile's desire to maintain dependencies.

In Makefiles of this type, a better way to do it is to use Makefile
dependencies to trigger the appropriate incremental rebuilds, and
separately use file lists (see EXTRA_FILES in this commit) to track what
to pass to the compiler.

This commit splits those concepts up, by setting up both EXTRA_FILES and
the Makefile dependencies with a single call to the new Makefile
function extra-files.

That fixes the build failure, while still providing the correct
dependencies in all cases.

Acked-by: Muhammad Usama Anjum <[email protected]>
Signed-off-by: John Hubbard <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

selftests/x86/mm: Add new test that userspace stack is in fact NX

Here is how it works:

* fault and fill the stack from RSP with INT3 down until rlimit allows,

* fill upwards with INT3 too, over

selftests/x86/mm: Add new test that userspace stack is in fact NX

Here is how it works:

* fault and fill the stack from RSP with INT3 down until rlimit allows,

* fill upwards with INT3 too, overwrite libc stuff, argv, envp,

* try to exec INT3 on each page and catch it in either SIGSEGV or
SIGTRAP handler.

Note: trying to execute _every_ INT3 on a 8 MiB stack takes 30-40 seconds
even on fast machine which is too much for kernel selftesting
(not for LTP!) so only 1 INT3 per page is tried.

Tested on F37 kernel and on a custom kernel which does:

vm_flags |= VM_EXEC;

to stack VMA.

Report from the buggy kernel:

$ ./nx_stack_32
stack min ff007000
stack max ff807000
FAIL executable page on the stack: eip ff806001

$ ./nx_stack_64
stack min 7ffe65bb0000
stack max 7ffe663b0000
FAIL executable page on the stack: rip 7ffe663af001

Signed-off-by: Alexey Dobriyan <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Link: https://lore.kernel.org/r/4cef8266-ad6d-48af-a5f1-fc2b6a8eb422@p183

show more ...

selftests/x86: Add shadow stack test

Add a simple selftest for exercising some shadow stack behavior:
- map_shadow_stack syscall and pivot
- Faulting in shadow stack memory
- Handling shadow stac

selftests/x86: Add shadow stack test

Add a simple selftest for exercising some shadow stack behavior:
- map_shadow_stack syscall and pivot
- Faulting in shadow stack memory
- Handling shadow stack violations
- GUP of shadow stack memory
- mprotect() of shadow stack memory
- Userfaultfd on shadow stack memory
- 32 bit segmentation
- Guard gap test
- Ptrace test

Co-developed-by: Yu-cheng Yu <[email protected]>
Signed-off-by: Yu-cheng Yu <[email protected]>
Signed-off-by: Rick Edgecombe <[email protected]>
Signed-off-by: Dave Hansen <[email protected]>
Acked-by: Mike Rapoport (IBM) <[email protected]>
Tested-by: Pengfei Xu <[email protected]>
Tested-by: John Allen <[email protected]>
Tested-by: Kees Cook <[email protected]>
Link: https://lore.kernel.org/all/20230613001108.3040476-40-rick.p.edgecombe%40intel.com

show more ...

selftests/x86/lam: Add malloc and tag-bits test cases for linear-address masking

LAM is supported only in 64-bit mode and applies only addresses used for data
accesses. In 64-bit mode, linear addres

selftests/x86/lam: Add malloc and tag-bits test cases for linear-address masking

LAM is supported only in 64-bit mode and applies only addresses used for data
accesses. In 64-bit mode, linear address have 64 bits. LAM is applied to 64-bit
linear address and allow software to use high bits for metadata.
LAM supports configurations that differ regarding which pointer bits are masked
and can be used for metadata.

LAM includes following mode:

- LAM_U57, pointer bits in positions 62:57 are masked (LAM width 6),
allows bits 62:57 of a user pointer to be used as metadata.

There are some arch_prctls:
ARCH_ENABLE_TAGGED_ADDR: enable LAM mode, mask high bits of a user pointer.
ARCH_GET_UNTAG_MASK: get current untagged mask.
ARCH_GET_MAX_TAG_BITS: the maximum tag bits user can request. zero if LAM
is not supported.

The LAM mode is for pre-process, a process has only one chance to set LAM mode.
But there is no API to disable LAM mode. So all of test cases are run under
child process.

Functions of this test:

MALLOC

- LAM_U57 masks bits 57:62 of a user pointer. Process on user space
can dereference such pointers.

- Disable LAM, dereference a pointer with metadata above 48 bit or 57 bit
lead to trigger SIGSEGV.

TAG_BITS

- Max tag bits of LAM_U57 is 6.

Signed-off-by: Weihong Zhang <[email protected]>
Signed-off-by: Kirill A. Shutemov <[email protected]>
Signed-off-by: Dave Hansen <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lore.kernel.org/all/20230312112612.31869-13-kirill.shutemov%40linux.intel.com

show more ...

selftests: x86: Fix incorrect kernel headers search path

Use $(KHDR_INCLUDES) as lookup path for kernel headers. This prevents
building against kernel headers from the build environment in scenarios

selftests: x86: Fix incorrect kernel headers search path

Use $(KHDR_INCLUDES) as lookup path for kernel headers. This prevents
building against kernel headers from the build environment in scenarios
where kernel headers are installed into a specific output directory
(O=...).

Signed-off-by: Mathieu Desnoyers <[email protected]>
Cc: Shuah Khan <[email protected]>
Cc: [email protected]
Cc: Ingo Molnar <[email protected]>
Cc: <[email protected]> # 5.18+
Signed-off-by: Shuah Khan <[email protected]>

show more ...

selftests: x86: add 32bit build warnings for SUSE

In order to successfully build all these 32bit tests, these 32bit gcc
and glibc packages, named gcc-32bit and glibc-devel-static-32bit on SUSE,
need

selftests: x86: add 32bit build warnings for SUSE

In order to successfully build all these 32bit tests, these 32bit gcc
and glibc packages, named gcc-32bit and glibc-devel-static-32bit on SUSE,
need to be installed.

This patch added this information in warn_32bit_failure.

Signed-off-by: Geliang Tang <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

selftests, x86: fix how check_cc.sh is being invoked

The $(CC) variable used in Makefiles could contain several arguments
such as "ccache gcc". These need to be passed as a single string to
check_c

selftests, x86: fix how check_cc.sh is being invoked

The $(CC) variable used in Makefiles could contain several arguments
such as "ccache gcc". These need to be passed as a single string to
check_cc.sh, otherwise only the first argument will be used as the
compiler command. Without quotes, the $(CC) variable is passed as
distinct arguments which causes the script to fail to build trivial
programs.

Fix this by adding quotes around $(CC) when calling check_cc.sh to pass
the whole string as a single argument to the script even if it has
several words such as "ccache gcc".

Link: https://lkml.kernel.org/r/d0d460d7be0107a69e3c52477761a6fe694c1840.1646991629.git.guillaume.tucker@collabora.com
Fixes: e9886ace222e ("selftests, x86: Rework x86 target architecture detection")
Signed-off-by: Guillaume Tucker <[email protected]>
Tested-by: "kernelci.org bot" <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Cc: Shuah Khan <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Dave Hansen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

selftests/x86/amx: Add test cases for AMX state management

AMX TILEDATA is a very large XSAVE feature. It could have caused
nasty XSAVE buffer space waste in two places:

* Signal stacks
* Kernel

selftests/x86/amx: Add test cases for AMX state management

AMX TILEDATA is a very large XSAVE feature. It could have caused
nasty XSAVE buffer space waste in two places:

* Signal stacks
* Kernel task_struct->fpu buffers

To avoid this waste, neither of these buffers have AMX state by
default. The non-default features are called "dynamic" features.

There is an arch_prctl(ARCH_REQ_XCOMP_PERM) which allows a task
to declare that it wants to use AMX or other "dynamic" XSAVE
features. This arch_prctl() ensures that sufficient sigaltstack
space is available before it will succeed. It also expands the
task_struct buffer.

Functions of this test:
* Test arch_prctl(ARCH_REQ_XCOMP_PERM). Ensure that it checks for
proper sigaltstack sizing and that the sizing is enforced for
future sigaltstack calls.
* Ensure that ARCH_REQ_XCOMP_PERM is inherited across fork()
* Ensure that TILEDATA use before the prctl() is fatal
* Ensure that TILEDATA is cleared across fork()

Note: Generally, compiler support is needed to do something with
AMX. Instead, directly load AMX state from userspace with a
plain XSAVE. Do not depend on the compiler.

[ dhansen: bunches of cleanups ]

Signed-off-by: Chang S. Bae <[email protected]>
Signed-off-by: Dave Hansen <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

selftests/x86: Test signal frame XSTATE header corruption handling

This is very heavily based on some code from Thomas Gleixner. On a system
without XSAVES, it triggers the WARN_ON():

Bad FPU st

selftests/x86: Test signal frame XSTATE header corruption handling

This is very heavily based on some code from Thomas Gleixner. On a system
without XSAVES, it triggers the WARN_ON():

Bad FPU state detected at copy_kernel_to_fpregs+0x2f/0x40, reinitializing FPU registers.

[ bp: Massage in nitpicks. ]

Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Dave Hansen <[email protected]>
Acked-by: Rik van Riel <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

selftest/x86/signal: Include test cases for validating sigaltstack

The test measures the kernel's signal delivery with different (enough vs.
insufficient) stack sizes.

Signed-off-by: Chang S. Bae <

selftest/x86/signal: Include test cases for validating sigaltstack

The test measures the kernel's signal delivery with different (enough vs.
insufficient) stack sizes.

Signed-off-by: Chang S. Bae <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Len Brown <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

kselftest: Move test_vdso to the vDSO test suite

Move test_vdso from x86 to the vDSO test suite.

Suggested-by: Andy Lutomirski <[email protected]>
Cc: Shuah Khan <[email protected]>
Signed-off-by: Vin

kselftest: Move test_vdso to the vDSO test suite

Move test_vdso from x86 to the vDSO test suite.

Suggested-by: Andy Lutomirski <[email protected]>
Cc: Shuah Khan <[email protected]>
Signed-off-by: Vincenzo Frascino <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

x86/ptrace: Fix 32-bit PTRACE_SETREGS vs fsbase and gsbase

Debuggers expect that doing PTRACE_GETREGS, then poking at a tracee
and maybe letting it run for a while, then doing PTRACE_SETREGS will
pu

x86/ptrace: Fix 32-bit PTRACE_SETREGS vs fsbase and gsbase

Debuggers expect that doing PTRACE_GETREGS, then poking at a tracee
and maybe letting it run for a while, then doing PTRACE_SETREGS will
put the tracee back where it was. In the specific case of a 32-bit
tracer and tracee, the PTRACE_GETREGS/SETREGS data structure doesn't
have fs_base or gs_base fields, so FSBASE and GSBASE fields are
never stored anywhere. Everything used to still work because
nonzero FS or GS would result full reloads of the segment registers
when the tracee resumes, and the bases associated with FS==0 or
GS==0 are irrelevant to 32-bit code.

Adding FSGSBASE support broke this: when FSGSBASE is enabled, FSBASE
and GSBASE are now restored independently of FS and GS for all tasks
when context-switched in. This means that, if a 32-bit tracer
restores a previous state using PTRACE_SETREGS but the tracee's
pre-restore and post-restore bases don't match, then the tracee is
resumed with the wrong base.

Fix it by explicitly loading the base when a 32-bit tracer pokes FS
or GS on a 64-bit kernel.

Also add a test case.

Fixes: 673903495c85 ("x86/process/64: Use FSBSBASE in switch_to() if available")
Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lkml.kernel.org/r/229cc6a50ecbb701abd50fe4ddaf0eda888898cd.1593192140.git.luto@kernel.org

show more ...

selftests/x86: Consolidate and fix get/set_eflags() helpers

There are several copies of get_eflags() and set_eflags() and they all are
buggy. Consolidate them and fix them. The fixes are:

Add mem

selftests/x86: Consolidate and fix get/set_eflags() helpers

There are several copies of get_eflags() and set_eflags() and they all are
buggy. Consolidate them and fix them. The fixes are:

Add memory clobbers. These are probably unnecessary but they make sure
that the compiler doesn't move something past one of these calls when it
shouldn't.

Respect the redzone on x86_64. There has no failure been observed related
to this, but it's definitely a bug.

Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lkml.kernel.org/r/982ce58ae8dea2f1e57093ee894760e35267e751.1593191971.git.luto@kernel.org

show more ...

selftests/x86/pkeys: move selftests to arch-neutral directory

Patch series "selftests, powerpc, x86: Memory Protection Keys", v19.

Memory protection keys enables an application to protect its addre

selftests/x86/pkeys: move selftests to arch-neutral directory

Patch series "selftests, powerpc, x86: Memory Protection Keys", v19.

Memory protection keys enables an application to protect its address space
from inadvertent access by its own code.

This feature is now enabled on powerpc and has been available since
4.16-rc1. The patches move the selftests to arch neutral directory and
enhance their test coverage.

Tested on powerpc64 and x86_64 (Skylake-SP).

This patch (of 24):

Move selftest files from tools/testing/selftests/x86/ to
tools/testing/selftests/vm/.

Signed-off-by: Ram Pai <[email protected]>
Signed-off-by: Thiago Jung Bauermann <[email protected]>
Signed-off-by: Sandipan Das <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Acked-by: Dave Hansen <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Florian Weimer <[email protected]>
Cc: "Desnes A. Nunes do Rosario" <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: "Aneesh Kumar K.V" <[email protected]>
Cc: Michal Suchanek <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Shuah Khan <[email protected]>
Link: http://lkml.kernel.org/r/14d25194c3e2e652e0047feec4487e269e76e8c9.1585646528.git.sandipan@linux.ibm.com
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

x86/mpx: Remove selftests Makefile entry

MPX is being removed from the kernel due to a lack of support in the
toolchain going forward (gcc).

This is the smallest possible patch to fix some issues t

x86/mpx: Remove selftests Makefile entry

MPX is being removed from the kernel due to a lack of support in the
toolchain going forward (gcc).

This is the smallest possible patch to fix some issues that have been
reported around running the MPX selftests. It it would also have been part
of any removal series, it is offered first.

Signed-off-by: Dave Hansen <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

x86/syscalls: Split the x32 syscalls into their own table

For unfortunate historical reasons, the x32 syscalls and the x86_64
syscalls are not all numbered the same. As an example, ioctl() is nr 16

x86/syscalls: Split the x32 syscalls into their own table

For unfortunate historical reasons, the x32 syscalls and the x86_64
syscalls are not all numbered the same. As an example, ioctl() is nr 16 on
x86_64 but 514 on x32.

This has potentially nasty consequences, since it means that there are two
valid RAX values to do ioctl(2) and two invalid RAX values. The valid
values are 16 (i.e. ioctl(2) using the x86_64 ABI) and (514 | 0x40000000)
(i.e. ioctl(2) using the x32 ABI).

The invalid values are 514 and (16 | 0x40000000). 514 will enter the
"COMPAT_SYSCALL_DEFINE3(ioctl, ...)" entry point with in_compat_syscall()
and in_x32_syscall() returning false, whereas (16 | 0x40000000) will enter
the native entry point with in_compat_syscall() and in_x32_syscall()
returning true. Both are bogus, and both will exercise code paths in the
kernel and in any running seccomp filters that really ought to be
unreachable.

Splitting out the x32 syscalls into their own tables, allows both bogus
invocations to return -ENOSYS. I've checked glibc, musl, and Bionic, and
all of them appear to call syscalls with their correct numbers, so this
change should have no effect on them.

There is an added benefit going forward: new syscalls that need special
handling on x32 can share the same number on x32 and x86_64. This means
that the special syscall range 512-547 can be treated as a legacy wart
instead of something that may need to be extended in the future.

Also add a selftest to verify the new behavior.

Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lkml.kernel.org/r/208024256b764312598f014ebfb0a42472c19354.1562185330.git.luto@kernel.org

show more ...

selftests/x86: Test SYSCALL and SYSENTER manually with TF set

Make sure that both variants of the nasty TF-in-compat-syscall are
exercised regardless of what vendor's CPU is running the tests.

Also

selftests/x86: Test SYSCALL and SYSENTER manually with TF set

Make sure that both variants of the nasty TF-in-compat-syscall are
exercised regardless of what vendor's CPU is running the tests.

Also change the intentional signal after SYSCALL to use ud2, which
is a lot more comprehensible.

This crashes the kernel due to an FSGSBASE bug right now.

This test *also* detects a bug in KVM when run on an Intel host. KVM
people, feel free to use it to help debug. There's a bunch of code in this
test to warn instead of going into an infinite looping when the bug gets
triggered.

Reported-by: Vegard Nossum <[email protected]>
Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: "BaeChang Seok" <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: [email protected]
Cc: "Bae, Chang Seok" <[email protected]>
Link: https://lkml.kernel.org/r/5f5de10441ab2e3005538b4c33be9b1965d1bb63.1562035429.git.luto@kernel.org

show more ...

selftests/x86: Detect -no-pie availability

Some toolchains need -no-pie to build all tests, others do not support
the -no-pie flag at all. Therefore, add another test for the
availability of the fl

selftests/x86: Detect -no-pie availability

Some toolchains need -no-pie to build all tests, others do not support
the -no-pie flag at all. Therefore, add another test for the
availability of the flag.

This amends commit 3346a6a4e5ba8c040360f753b26938cec31a4bdc
("selftests: x86: sysret_ss_attrs doesn't build on a PIE build").

Signed-off-by: Florian Weimer <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Signed-off-by: Shuah Khan (Samsung OSG) <[email protected]>

show more ...

x86/selftests: Add mov_to_ss test

This exercises a nasty corner case of the x86 ISA.

Signed-off-by: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Linus Torvalds <torvalds

x86/selftests: Add mov_to_ss test

This exercises a nasty corner case of the x86 ISA.

Signed-off-by: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/67e08b69817171da8026e0eb3af0214b06b4d74f.1525800455.git.luto@kernel.org
Signed-off-by: Ingo Molnar <[email protected]>

show more ...