summaryrefslogtreecommitdiffstats
path: root/tools/testing/selftests/x86/Makefile
AgeCommit message (Collapse)AuthorLines
2026-01-17selftests/x86: Add selftests include path for kselftest.h after centralizationBala-Vignesh-Reddy-0/+1
The previous change centralizing kselftest.h include path in lib.mk caused x86 selftests to fail, as x86 Makefile overwrites CFLAGS using ":=", dropping the include path added in lib.mk. Therefore, helpers.h could not find kselftest.h during compilation. Fix this by adding the tools/testing/sefltest to CFLAGS in x86 Makefile. [ bp: Correct commit ID in Fixes: ] Fixes: e6fbd1759c9e ("selftests: complete kselftest include centralization") Closes: https://lore.kernel.org/lkml/CA+G9fYvKjQcCBMfXA-z2YuL2L+3Qd-pJjEUDX8PDdz2-EEQd=Q@mail.gmail.com/T/#m83fd330231287fc9d6c921155bee16c591db7360 Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by: Bala-Vignesh-Reddy <reddybalavignesh9979@gmail.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Anders Roxell <anders.roxell@linaro.org> Tested-by: Brendan Jackman <jackmanb@google.com> Link: https://patch.msgid.link/20251022062948.162852-1-reddybalavignesh9979@gmail.com
2025-06-09selftests/x86: Add a test to detect infinite SIGTRAP handler loopXin Li (Intel)-1/+1
When FRED is enabled, if the Trap Flag (TF) is set without an external debugger attached, it can lead to an infinite loop in the SIGTRAP handler. To avoid this, the software event flag in the augmented SS must be cleared, ensuring that no single-step trap remains pending when ERETU completes. This test checks for that specific scenario—verifying whether the kernel correctly prevents an infinite SIGTRAP loop in this edge case when FRED is enabled. The test should _always_ pass with IDT event delivery, thus no need to disable the test even when FRED is not enabled. Signed-off-by: Xin Li (Intel) <xin@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Tested-by: Sohil Mehta <sohil.mehta@intel.com> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250609084054.2083189-3-xin%40zytor.com
2025-04-16selftests/x86/apx: Add APX testChang S. Bae-1/+2
The extended general-purpose registers for APX may contain random data, which is currently assumed by the xstate testing framework. This allows the testing of the new userspace feature using the common test code. Invoke the test entry function from apx.c after enumerating the state component and adding it to the support list Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/r/20250416021720.12305-6-chang.seok.bae@intel.com
2025-02-26selftests/x86/avx: Add AVX testsChang S. Bae-1/+3
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 <chang.seok.bae@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250226010731.2456-10-chang.seok.bae@intel.com
2025-02-26selftests/x86/xstate: Refactor context switching testChang S. Bae-0/+2
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 <chang.seok.bae@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250226010731.2456-5-chang.seok.bae@intel.com
2024-08-27Documentation/srso: Document a method for checking safe RET operates properlyBorislav Petkov (AMD)-1/+1
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) <bp@alien8.de> Link: https://lore.kernel.org/r/20240731160531.28640-1-bp@kernel.org
2024-07-11selftests/x86: avoid -no-pie warnings from clang during compilationJohn Hubbard-0/+7
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 <usama.anjum@collabora.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-07-11selftests/x86: build sysret_rip.c with clangJohn Hubbard-0/+1
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 <usama.anjum@collabora.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-07-11selftests/x86: build fsgsbase_restore.c with clangJohn Hubbard-0/+2
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 <usama.anjum@collabora.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-07-11selftests/x86: fix Makefile dependencies to work with clangJohn Hubbard-6/+15
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 <usama.anjum@collabora.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-10-03selftests/x86/mm: Add new test that userspace stack is in fact NXAlexey Dobriyan-0/+4
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 <adobriyan@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/4cef8266-ad6d-48af-a5f1-fc2b6a8eb422@p183
2023-08-02selftests/x86: Add shadow stack testRick Edgecombe-1/+1
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 <yu-cheng.yu@intel.com> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Mike Rapoport (IBM) <rppt@kernel.org> Tested-by: Pengfei Xu <pengfei.xu@intel.com> Tested-by: John Allen <john.allen@amd.com> Tested-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/all/20230613001108.3040476-40-rick.p.edgecombe%40intel.com
2023-03-16selftests/x86/lam: Add malloc and tag-bits test cases for linear-address maskingWeihong Zhang-1/+1
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 <weihong.zhang@intel.com> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/all/20230312112612.31869-13-kirill.shutemov%40linux.intel.com
2023-02-13selftests: x86: Fix incorrect kernel headers search pathMathieu Desnoyers-1/+1
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 <mathieu.desnoyers@efficios.com> Cc: Shuah Khan <shuah@kernel.org> Cc: linux-kselftest@vger.kernel.org Cc: Ingo Molnar <mingo@redhat.com> Cc: <stable@vger.kernel.org> # 5.18+ Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-04-04selftests: x86: add 32bit build warnings for SUSEGeliang Tang-0/+4
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 <geliang.tang@suse.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-03-22selftests, x86: fix how check_cc.sh is being invokedGuillaume Tucker-3/+3
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 <guillaume.tucker@collabora.com> Tested-by: "kernelci.org bot" <bot@kernelci.org> Reviewed-by: Guenter Roeck <groeck@google.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Borislav Petkov <bp@suse.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-10-28selftests/x86/amx: Add test cases for AMX state managementChang S. Bae-1/+1
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 <chang.seok.bae@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20211026122524.7BEDAA95@davehans-spike.ostc.intel.com
2021-06-09selftests/x86: Test signal frame XSTATE header corruption handlingAndy Lutomirski-1/+2
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 <luto@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Rik van Riel <riel@surriel.com> Link: https://lkml.kernel.org/r/20210608144346.234764986@linutronix.de
2021-05-19selftest/x86/signal: Include test cases for validating sigaltstackChang S. Bae-1/+1
The test measures the kernel's signal delivery with different (enough vs. insufficient) stack sizes. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Len Brown <len.brown@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20210518200320.17239-7-chang.seok.bae@intel.com
2020-10-27kselftest: Move test_vdso to the vDSO test suiteVincenzo Frascino-1/+1
Move test_vdso from x86 to the vDSO test suite. Suggested-by: Andy Lutomirski <luto@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2020-08-04Merge tag 'x86-fsgsbase-2020-08-04' of ↵Linus Torvalds-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fsgsbase from Thomas Gleixner: "Support for FSGSBASE. Almost 5 years after the first RFC to support it, this has been brought into a shape which is maintainable and actually works. This final version was done by Sasha Levin who took it up after Intel dropped the ball. Sasha discovered that the SGX (sic!) offerings out there ship rogue kernel modules enabling FSGSBASE behind the kernels back which opens an instantanious unpriviledged root hole. The FSGSBASE instructions provide a considerable speedup of the context switch path and enable user space to write GSBASE without kernel interaction. This enablement requires careful handling of the exception entries which go through the paranoid entry path as they can no longer rely on the assumption that user GSBASE is positive (as enforced via prctl() on non FSGSBASE enabled systemn). All other entries (syscalls, interrupts and exceptions) can still just utilize SWAPGS unconditionally when the entry comes from user space. Converting these entries to use FSGSBASE has no benefit as SWAPGS is only marginally slower than WRGSBASE and locating and retrieving the kernel GSBASE value is not a free operation either. The real benefit of RD/WRGSBASE is the avoidance of the MSR reads and writes. The changes come with appropriate selftests and have held up in field testing against the (sanitized) Graphene-SGX driver" * tag 'x86-fsgsbase-2020-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (21 commits) x86/fsgsbase: Fix Xen PV support x86/ptrace: Fix 32-bit PTRACE_SETREGS vs fsbase and gsbase selftests/x86/fsgsbase: Add a missing memory constraint selftests/x86/fsgsbase: Fix a comment in the ptrace_write_gsbase test selftests/x86: Add a syscall_arg_fault_64 test for negative GSBASE selftests/x86/fsgsbase: Test ptracer-induced GS base write with FSGSBASE selftests/x86/fsgsbase: Test GS selector on ptracer-induced GS base write Documentation/x86/64: Add documentation for GS/FS addressing mode x86/elf: Enumerate kernel FSGSBASE capability in AT_HWCAP2 x86/cpu: Enable FSGSBASE on 64bit by default and add a chicken bit x86/entry/64: Handle FSGSBASE enabled paranoid entry/exit x86/entry/64: Introduce the FIND_PERCPU_BASE macro x86/entry/64: Switch CR3 before SWAPGS in paranoid entry x86/speculation/swapgs: Check FSGSBASE in enabling SWAPGS mitigation x86/process/64: Use FSGSBASE instructions on thread copy and ptrace x86/process/64: Use FSBSBASE in switch_to() if available x86/process/64: Make save_fsgs_for_kvm() ready for FSGSBASE x86/fsgsbase/64: Enable FSGSBASE instructions in helper functions x86/fsgsbase/64: Add intrinsics for FSGSBASE instructions x86/cpu: Add 'unsafe_fsgsbase' to enable CR4.FSGSBASE ...
2020-07-01x86/ptrace: Fix 32-bit PTRACE_SETREGS vs fsbase and gsbaseAndy Lutomirski-1/+1
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 <luto@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/229cc6a50ecbb701abd50fe4ddaf0eda888898cd.1593192140.git.luto@kernel.org
2020-07-01selftests/x86: Consolidate and fix get/set_eflags() helpersAndy Lutomirski-2/+2
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 <luto@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/982ce58ae8dea2f1e57093ee894760e35267e751.1593191971.git.luto@kernel.org
2020-06-04selftests/x86/pkeys: move selftests to arch-neutral directoryRam Pai-1/+1
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 <linuxram@us.ibm.com> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Sandipan Das <sandipan@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Dave Hansen <dave.hansen@intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Florian Weimer <fweimer@redhat.com> Cc: "Desnes A. Nunes do Rosario" <desnesn@linux.vnet.ibm.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> Cc: Michal Suchanek <msuchanek@suse.de> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Shuah Khan <shuah@kernel.org> Link: http://lkml.kernel.org/r/14d25194c3e2e652e0047feec4487e269e76e8c9.1585646528.git.sandipan@linux.ibm.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-09-16Merge branch 'x86-entry-for-linus' of ↵Linus Torvalds-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 entry updates from Ingo Molnar: "This contains x32 and compat syscall improvements, the biggest one of which splits x32 syscalls into their own table, which allows new syscalls to share the x32 and x86-64 number - which turns the 512-547 special syscall numbers range into a legacy wart that won't be extended going forward" * 'x86-entry-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/syscalls: Split the x32 syscalls into their own table x86/syscalls: Disallow compat entries for all types of 64-bit syscalls x86/syscalls: Use the compat versions of rt_sigsuspend() and rt_sigprocmask() x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long
2019-07-22x86/mpx: Remove selftests Makefile entryDave Hansen-1/+1
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 <dave.hansen@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20190705175318.784C233E@viggo.jf.intel.com
2019-07-22x86/syscalls: Split the x32 syscalls into their own tableAndy Lutomirski-1/+1
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 <luto@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/208024256b764312598f014ebfb0a42472c19354.1562185330.git.luto@kernel.org
2019-07-02selftests/x86: Test SYSCALL and SYSENTER manually with TF setAndy Lutomirski-2/+3
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 <vegard.nossum@oracle.com> Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: "BaeChang Seok" <chang.seok.bae@intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org Cc: "Bae, Chang Seok" <chang.seok.bae@intel.com> Link: https://lkml.kernel.org/r/5f5de10441ab2e3005538b4c33be9b1965d1bb63.1562035429.git.luto@kernel.org
2018-05-30selftests/x86: Detect -no-pie availabilityFlorian Weimer-1/+7
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 <fweimer@redhat.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
2018-05-14x86/selftests: Add mov_to_ss testAndy Lutomirski-1/+1
This exercises a nasty corner case of the x86 ISA. Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/67e08b69817171da8026e0eb3af0214b06b4d74f.1525800455.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-14Merge branch 'x86-pti-for-linus' of ↵Linus Torvalds-8/+16
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 PTI and Spectre related fixes and updates from Ingo Molnar: "Here's the latest set of Spectre and PTI related fixes and updates: Spectre: - Add entry code register clearing to reduce the Spectre attack surface - Update the Spectre microcode blacklist - Inline the KVM Spectre helpers to get close to v4.14 performance again. - Fix indirect_branch_prediction_barrier() - Fix/improve Spectre related kernel messages - Fix array_index_nospec_mask() asm constraint - KVM: fix two MSR handling bugs PTI: - Fix a paranoid entry PTI CR3 handling bug - Fix comments objtool: - Fix paranoid_entry() frame pointer warning - Annotate WARN()-related UD2 as reachable - Various fixes - Add Add Peter Zijlstra as objtool co-maintainer Misc: - Various x86 entry code self-test fixes - Improve/simplify entry code stack frame generation and handling after recent heavy-handed PTI and Spectre changes. (There's two more WIP improvements expected here.) - Type fix for cache entries There's also some low risk non-fix changes I've included in this branch to reduce backporting conflicts: - rename a confusing x86_cpu field name - de-obfuscate the naming of single-TLB flushing primitives" * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (41 commits) x86/entry/64: Fix CR3 restore in paranoid_exit() x86/cpu: Change type of x86_cache_size variable to unsigned int x86/spectre: Fix an error message x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping selftests/x86/mpx: Fix incorrect bounds with old _sigfault x86/mm: Rename flush_tlb_single() and flush_tlb_one() to __flush_tlb_one_[user|kernel]() x86/speculation: Add <asm/msr-index.h> dependency nospec: Move array_index_nospec() parameter checking into separate macro x86/speculation: Fix up array_index_nospec_mask() asm constraint x86/debug: Use UD2 for WARN() x86/debug, objtool: Annotate WARN()-related UD2 as reachable objtool: Fix segfault in ignore_unreachable_insn() selftests/x86: Disable tests requiring 32-bit support on pure 64-bit systems selftests/x86: Do not rely on "int $0x80" in single_step_syscall.c selftests/x86: Do not rely on "int $0x80" in test_mremap_vdso.c selftests/x86: Fix build bug caused by the 5lvl test which has been moved to the VM directory selftests/x86/pkeys: Remove unused functions selftests/x86: Clean up and document sscanf() usage selftests/x86: Fix vDSO selftest segfault for vsyscall=none x86/entry/64: Remove the unused 'icebp' macro ...
2018-02-15selftests/x86: Disable tests requiring 32-bit support on pure 64-bit systemsDominik Brodowski-7/+13
The ldt_gdt and ptrace_syscall selftests, even in their 64-bit variant, use hard-coded 32-bit syscall numbers and call "int $0x80". This will fail on 64-bit systems with CONFIG_IA32_EMULATION=y disabled. Therefore, do not build these tests if we cannot build 32-bit binaries (which should be a good approximation for CONFIG_IA32_EMULATION=y being enabled). Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Dmitry Safonov <dsafonov@virtuozzo.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kselftest@vger.kernel.org Cc: shuah@kernel.org Link: http://lkml.kernel.org/r/20180211111013.16888-6-linux@dominikbrodowski.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-15selftests/x86: Do not rely on "int $0x80" in single_step_syscall.cDominik Brodowski-0/+2
On 64-bit builds, we should not rely on "int $0x80" working (it only does if CONFIG_IA32_EMULATION=y is enabled). To keep the "Set TF and check int80" test running on 64-bit installs with CONFIG_IA32_EMULATION=y enabled, build this test only if we can also build 32-bit binaries (which should be a good approximation for that). Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Dmitry Safonov <dsafonov@virtuozzo.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kselftest@vger.kernel.org Cc: shuah@kernel.org Link: http://lkml.kernel.org/r/20180211111013.16888-5-linux@dominikbrodowski.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-13selftests/x86: Fix build bug caused by the 5lvl test which has been moved to ↵Dominik Brodowski-1/+1
the VM directory Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kselftest@vger.kernel.org Cc: shuah@kernel.org Fixes: 235266b8e11c "selftests/vm: move 128TB mmap boundary test to generic directory" Link: http://lkml.kernel.org/r/20180211111013.16888-2-linux@dominikbrodowski.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-03Merge tag 'linux-kselftest-4.16-rc1' of ↵Linus Torvalds-0/+12
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull kselftest updates from Shuah Khan: "This update to Kselftest consists of fixes, cleanups, and SPDX license additions" * tag 'linux-kselftest-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: selftests: vm: update .gitignore with missing generated file selftests/x86: Add <test_name>{,_32,_64} targets selftests: Fix loss of test output in run_kselftests.sh selftest: ftrace: Fix to add 256 kprobe events correctly selftest: ftrace: Fix to pick text symbols for kprobes selftests: media_tests: Add SPDX license identifier selftests: kselftest.h: Add SPDX license identifier selftests: kselftest_install.sh: Add SPDX license identifier selftests: gen_kselftest_tar.h: Add SPDX license identifier selftests: media_tests: Fix Makefile 'clean' target warning tools/testing: Fix trailing semicolon kselftest: fix OOM in memory compaction test selftests: seccomp: fix compile error seccomp_bpf
2018-01-23selftests/x86: Add <test_name>{,_32,_64} targetsDmitry Safonov-0/+12
One can only use `make all` or `make <test_name>_<bitness>` as make targets. `make <test_name>` doesn't work as Ingo noticed: x86> make test_vsyscall gcc -O2 -g -std=gnu99 -pthread -Wall -no-pie test_vsyscall.c -o test_vsyscall /tmp/aBaoo3nb.o: In function `init_vdso': test_vsyscall.c:68: undefined reference to `dlopen' test_vsyscall.c:76: undefined reference to `dlsym' test_vsyscall.c:80: undefined reference to `dlsym' test_vsyscall.c:84: undefined reference to `dlsym' test_vsyscall.c:88: undefined reference to `dlsym' test_vsyscall.c:70: undefined reference to `dlopen' collect2: error: ld returned 1 exit status <builtin>: recipe for target 'test_vsyscall' failed make: *** [test_vsyscall] Error 1 Makefile target substitution neither works :-/ Generate .PHONY targets per-test and fix target substitution. Cc: Andy Lutomirski <luto@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kselftest@vger.kernel.org Cc: x86@kernel.org Reported-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Dmitry Safonov <dima@arista.com> Reviewed-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2018-01-14Merge branch 'x86-pti-for-linus' of ↵Linus Torvalds-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 pti updates from Thomas Gleixner: "This contains: - a PTI bugfix to avoid setting reserved CR3 bits when PCID is disabled. This seems to cause issues on a virtual machine at least and is incorrect according to the AMD manual. - a PTI bugfix which disables the perf BTS facility if PTI is enabled. The BTS AUX buffer is not globally visible and causes the CPU to fault when the mapping disappears on switching CR3 to user space. A full fix which restores BTS on PTI is non trivial and will be worked on. - PTI bugfixes for EFI and trusted boot which make sure that the user space visible page table entries have the NX bit cleared - removal of dead code in the PTI pagetable setup functions - add PTI documentation - add a selftest for vsyscall to verify that the kernel actually implements what it advertises. - a sysfs interface to expose vulnerability and mitigation information so there is a coherent way for users to retrieve the status. - the initial spectre_v2 mitigations, aka retpoline: + The necessary ASM thunk and compiler support + The ASM variants of retpoline and the conversion of affected ASM code + Make LFENCE serializing on AMD so it can be used as speculation trap + The RSB fill after vmexit - initial objtool support for retpoline As I said in the status mail this is the most of the set of patches which should go into 4.15 except two straight forward patches still on hold: - the retpoline add on of LFENCE which waits for ACKs - the RSB fill after context switch Both should be ready to go early next week and with that we'll have covered the major holes of spectre_v2 and go back to normality" * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (28 commits) x86,perf: Disable intel_bts when PTI security/Kconfig: Correct the Documentation reference for PTI x86/pti: Fix !PCID and sanitize defines selftests/x86: Add test_vsyscall x86/retpoline: Fill return stack buffer on vmexit x86/retpoline/irq32: Convert assembler indirect jumps x86/retpoline/checksum32: Convert assembler indirect jumps x86/retpoline/xen: Convert Xen hypercall indirect jumps x86/retpoline/hyperv: Convert assembler indirect jumps x86/retpoline/ftrace: Convert ftrace assembler indirect jumps x86/retpoline/entry: Convert entry assembler indirect jumps x86/retpoline/crypto: Convert crypto assembler indirect jumps x86/spectre: Add boot time option to select Spectre v2 mitigation x86/retpoline: Add initial retpoline support objtool: Allow alternatives to be ignored objtool: Detect jumps to retpoline thunks x86/pti: Make unpoison of pgd for trusted boot work for real x86/alternatives: Fix optimize_nops() checking sysfs/cpu: Fix typos in vulnerability documentation x86/cpu/AMD: Use LFENCE_RDTSC in preference to MFENCE_RDTSC ...
2018-01-13selftests/x86: Add test_vsyscallAndy Lutomirski-1/+1
This tests that the vsyscall entries do what they're expected to do. It also confirms that attempts to read the vsyscall page behave as expected. If changes are made to the vsyscall code or its memory map handling, running this test in all three of vsyscall=none, vsyscall=emulate, and vsyscall=native are helpful. (Because it's easy, this also compares the vsyscall results to their vDSO equivalents.) Note to KAISER backporters: please test this under all three vsyscall modes. Also, in the emulate and native modes, make sure that test_vsyscall_64 agrees with the command line or config option as to which mode you're in. It's quite easy to mess up the kernel such that native mode accidentally emulates or vice versa. Greg, etc: please backport this to all your Meltdown-patched kernels. It'll help make sure the patches didn't regress vsyscalls. CSigned-off-by: Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Hugh Dickins <hughd@google.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/2b9c5a174c1d60fd7774461d518aa75598b1d8fd.1515719552.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-11-16x86/selftests: Add test for mapping placement for 5-level pagingKirill A. Shutemov-1/+1
5-level paging provides a 56-bit virtual address space for user space application. But the kernel defaults to mappings below the 47-bit address space boundary, which is the upper bound for 4-level paging, unless an application explicitely request it by using a mmap(2) address hint above the 47-bit boundary. The kernel prevents mappings which spawn across the 47-bit boundary unless mmap(2) was invoked with MAP_FIXED. Add a self-test that covers the corner cases of the interface and validates the correctness of the implementation. [ tglx: Massaged changelog once more ] Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: linux-mm@kvack.org Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lkml.kernel.org/r/20171115143607.81541-2-kirill.shutemov@linux.intel.com
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman-0/+1
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-05selftests: x86: sysret_ss_attrs doesn't build on a PIE buildShuah Khan-1/+1
sysret_ss_attrs fails to compile leading x86 test run to fail on systems configured to build using PIE by default. Add -no-pie fix it. Relocation might still fail if relocated above 4G. For now this change fixes the build and runs x86 tests. tools/testing/selftests/x86$ make gcc -m64 -o .../tools/testing/selftests/x86/single_step_syscall_64 -O2 -g -std=gnu99 -pthread -Wall single_step_syscall.c -lrt -ldl gcc -m64 -o .../tools/testing/selftests/x86/sysret_ss_attrs_64 -O2 -g -std=gnu99 -pthread -Wall sysret_ss_attrs.c thunks.S -lrt -ldl /usr/bin/ld: /tmp/ccS6pvIh.o: relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status Makefile:49: recipe for target '.../tools/testing/selftests/x86/sysret_ss_attrs_64' failed make: *** [.../tools/testing/selftests/x86/sysret_ss_attrs_64] Error 1 Suggested-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2017-04-27selftests: x86: override clean in lib.mk to fix warningsShuah Khan-2/+1
Add override with EXTRA_CLEAN for lib.mk clean to fix the following warnings from clean target run. Makefile:44: warning: overriding recipe for target 'clean' ../lib.mk:55: warning: ignoring old recipe for target 'clean' Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2017-03-04Merge tag 'kvm-4.11-2' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds-1/+1
Pull more KVM updates from Radim Krčmář: "Second batch of KVM changes for the 4.11 merge window: PPC: - correct assumption about ASDR on POWER9 - fix MMIO emulation on POWER9 x86: - add a simple test for ioperm - cleanup TSS (going through KVM tree as the whole undertaking was caused by VMX's use of TSS) - fix nVMX interrupt delivery - fix some performance counters in the guest ... and two cleanup patches" * tag 'kvm-4.11-2' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: nVMX: Fix pending events injection x86/kvm/vmx: remove unused variable in segment_base() selftests/x86: Add a basic selftest for ioperm x86/asm: Tidy up TSS limit code kvm: convert kvm.users_count from atomic_t to refcount_t KVM: x86: never specify a sample period for virtualized in_tx_cp counters KVM: PPC: Book3S HV: Don't use ASDR for real-mode HPT faults on POWER9 KVM: PPC: Book3S HV: Fix software walk of guest process page tables
2017-03-01selftests/x86: Add a basic selftest for iopermAndy Lutomirski-1/+1
This doesn't fully exercise the interaction between KVM and ioperm(), but it does test basic functionality. Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2017-02-25Merge tag 'linux-kselftest-4.11-rc1' of ↵Linus Torvalds-7/+10
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull Kselftest update from Shuah Khan: "This update consists of: - fixes to several existing tests from Stafford Horne - cpufreq tests from Viresh Kumar - Selftest build and install fixes from Bamvor Jian Zhang and Michael Ellerman - Fixes to protection-keys tests from Dave Hansen - Warning fixes from Shuah Khan" * tag 'linux-kselftest-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: (28 commits) selftests/powerpc: Fix remaining fallout from recent changes selftests/powerpc: Fix the clean rule since recent changes selftests: Fix the .S and .S -> .o rules selftests: Fix the .c linking rule selftests: Fix selftests build to just build, not run tests selftests, x86, protection_keys: fix wrong offset in siginfo selftests, x86, protection_keys: fix uninitialized variable warning selftest: cpufreq: Update MAINTAINERS file selftest: cpufreq: Add special tests selftest: cpufreq: Add support to test cpufreq modules selftest: cpufreq: Add suspend/resume/hibernate support selftest: cpufreq: Add support for cpufreq tests selftests: Add intel_pstate to TARGETS selftests/intel_pstate: Update makefile to match new style selftests/intel_pstate: Fix warning on loop index overflow cpupower: Restore format of frequency-info limit selftests/futex: Add headers to makefile dependencies selftests/futex: Add stdio used for logging selftests: x86 protection_keys remove dead code selftests: x86 protection_keys fix unused variable compile warnings ...
2017-02-20Merge branch 'x86-mm-for-linus' of ↵Linus Torvalds-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 mm updates from Ingo Molnar: "A laundry list of changes: KASAN improvements/fixes for ptdump, a self-test fix, PAT cleanup and wbinvd() avoidance, removal of stale code and documentation updates" * 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mm/ptdump: Add address marker for KASAN shadow region x86/mm/ptdump: Optimize check for W+X mappings for CONFIG_KASAN=y x86/mm/pat: Use rb_entry() x86/mpx: Re-add MPX to selftests Makefile x86/mm: Remove CONFIG_DEBUG_NX_TEST x86/mm/cpa: Avoid wbinvd() for PREEMPT x86/mm: Improve documentation for low-level device I/O functions
2017-02-02x86/mpx: Re-add MPX to selftests MakefileDave Hansen-1/+1
Ingo pointed out that the MPX tests were no longer in the selftests Makefile. It appears that I shot myself in the foot on this one and accidentally removed them when I added the pkeys tests, probably from bungling a merge conflict. Reported-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 5f23f6d082a9 ("x86/pkeys: Add self-tests") Link: http://lkml.kernel.org/r/20170201225629.C3070852@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-05selftests: enable O and KBUILD_OUTPUTbamvor.zhangjian@huawei.com-7/+10
Enable O and KBUILD_OUTPUT for kselftest. User could compile kselftest to another directory by passing O or KBUILD_OUTPUT. And O is high priority than KBUILD_OUTPUT. Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2017-01-05selftests/x86: Add a selftest for SYSRET to noncanonical addressesAndy Lutomirski-1/+1
SYSRET to a noncanonical address will blow up on Intel CPUs. Linux needs to prevent this from happening in two major cases, and the criteria will become more complicated when support for larger virtual address spaces is added. A fast-path SYSCALL will fall through to the following instruction using SYSRET without any particular checking. To prevent fall-through to a noncanonical address, Linux prevents the highest canonical page from being mapped. This test case checks a variety of possible maximum addresses to make sure that either we can't map code there or that SYSCALL fall-through works. A slow-path system call can return anywhere. Linux needs to make sure that, if the return address is non-canonical, it won't use SYSRET. This test cases causes sigreturn() to return to a variety of addresses (with RCX == RIP) and makes sure that nothing explodes. Some of this code comes from Kirill Shutemov. Kirill reported the following output with 5-level paging enabled: [RUN] sigreturn to 0x800000000000 [OK] Got SIGSEGV at RIP=0x800000000000 [RUN] sigreturn to 0x1000000000000 [OK] Got SIGSEGV at RIP=0x1000000000000 [RUN] sigreturn to 0x2000000000000 [OK] Got SIGSEGV at RIP=0x2000000000000 [RUN] sigreturn to 0x4000000000000 [OK] Got SIGSEGV at RIP=0x4000000000000 [RUN] sigreturn to 0x8000000000000 [OK] Got SIGSEGV at RIP=0x8000000000000 [RUN] sigreturn to 0x10000000000000 [OK] Got SIGSEGV at RIP=0x10000000000000 [RUN] sigreturn to 0x20000000000000 [OK] Got SIGSEGV at RIP=0x20000000000000 [RUN] sigreturn to 0x40000000000000 [OK] Got SIGSEGV at RIP=0x40000000000000 [RUN] sigreturn to 0x80000000000000 [OK] Got SIGSEGV at RIP=0x80000000000000 [RUN] sigreturn to 0x100000000000000 [OK] Got SIGSEGV at RIP=0x100000000000000 [RUN] sigreturn to 0x200000000000000 [OK] Got SIGSEGV at RIP=0x200000000000000 [RUN] sigreturn to 0x400000000000000 [OK] Got SIGSEGV at RIP=0x400000000000000 [RUN] sigreturn to 0x800000000000000 [OK] Got SIGSEGV at RIP=0x800000000000000 [RUN] sigreturn to 0x1000000000000000 [OK] Got SIGSEGV at RIP=0x1000000000000000 [RUN] sigreturn to 0x2000000000000000 [OK] Got SIGSEGV at RIP=0x2000000000000000 [RUN] sigreturn to 0x4000000000000000 [OK] Got SIGSEGV at RIP=0x4000000000000000 [RUN] sigreturn to 0x8000000000000000 [OK] Got SIGSEGV at RIP=0x8000000000000000 [RUN] Trying a SYSCALL that falls through to 0x7fffffffe000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x7ffffffff000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x800000000000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0xfffffffff000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x1000000000000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x1fffffffff000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x2000000000000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x3fffffffff000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x4000000000000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x7fffffffff000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x8000000000000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0xffffffffff000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x10000000000000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x1ffffffffff000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x20000000000000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x3ffffffffff000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x40000000000000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x7ffffffffff000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x80000000000000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0xfffffffffff000 [OK] We survived [RUN] Trying a SYSCALL that falls through to 0x100000000000000 [OK] mremap to 0xfffffffffff000 failed [RUN] Trying a SYSCALL that falls through to 0x1fffffffffff000 [OK] mremap to 0x1ffffffffffe000 failed [RUN] Trying a SYSCALL that falls through to 0x200000000000000 [OK] mremap to 0x1fffffffffff000 failed [RUN] Trying a SYSCALL that falls through to 0x3fffffffffff000 [OK] mremap to 0x3ffffffffffe000 failed [RUN] Trying a SYSCALL that falls through to 0x400000000000000 [OK] mremap to 0x3fffffffffff000 failed [RUN] Trying a SYSCALL that falls through to 0x7fffffffffff000 [OK] mremap to 0x7ffffffffffe000 failed [RUN] Trying a SYSCALL that falls through to 0x800000000000000 [OK] mremap to 0x7fffffffffff000 failed [RUN] Trying a SYSCALL that falls through to 0xffffffffffff000 [OK] mremap to 0xfffffffffffe000 failed [RUN] Trying a SYSCALL that falls through to 0x1000000000000000 [OK] mremap to 0xffffffffffff000 failed [RUN] Trying a SYSCALL that falls through to 0x1ffffffffffff000 [OK] mremap to 0x1fffffffffffe000 failed [RUN] Trying a SYSCALL that falls through to 0x2000000000000000 [OK] mremap to 0x1ffffffffffff000 failed [RUN] Trying a SYSCALL that falls through to 0x3ffffffffffff000 [OK] mremap to 0x3fffffffffffe000 failed [RUN] Trying a SYSCALL that falls through to 0x4000000000000000 [OK] mremap to 0x3ffffffffffff000 failed [RUN] Trying a SYSCALL that falls through to 0x7ffffffffffff000 [OK] mremap to 0x7fffffffffffe000 failed [RUN] Trying a SYSCALL that falls through to 0x8000000000000000 [OK] mremap to 0x7ffffffffffff000 failed Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/e70bd9a3f90657ba47b755100a20475d038fa26b.1482808435.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-11-17selftests/x86: Add test_vdso to test getcpu()Andy Lutomirski-1/+1
I'll eventually add tests for more vDSO functions here. Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Megha <megha.dey@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/945cd29901a62a3cc6ea7d6ee5e389ab1ec1ac0c.1479320367.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
generated by cgit v1.2.3 (git 2.46.0) at 2026-04-02 04:36:20 +0000