kernel/linux.git/tools/testing/selftests/x86, branch v5.4.168

selftests/vm/pkeys: fix alloc_random_pkey() to make it really, really random

2021-07-14T14:53:47+00:00

[ Upstream commit f36ef407628835a7d7fb3d235b1f1aac7022d9a3 ] Patch series "selftests/vm/pkeys: Bug fixes and a new test". There has been a lot of activity on the x86 front around the XSAVE architecture which is used to context-switch processor state (among other things). In addition, AMD has recently joined the protection keys club by adding processor support for PKU. The AMD implementation helped uncover a kernel bug around the PKRU "init state", which actually applied to Intel's implementation but was just harder to hit. This series adds a test which is expected to help find this class of bug both on AMD and Intel. All the work around pkeys on x86 also uncovered a few bugs in the selftest. This patch (of 4): The "random" pkey allocation code currently does the good old: srand((unsigned int)time(NULL)); *But*, it unfortunately does this on every random pkey allocation. There may be thousands of these a second. time() has a one second resolution. So, each time alloc_random_pkey() is called, the PRNG is *RESET* to time(). This is nasty. Normally, if you do: srand(); foo = rand(); bar = rand(); You'll be quite guaranteed that 'foo' and 'bar' are different. But, if you do: srand(1); foo = rand(); srand(1); bar = rand(); You are quite guaranteed that 'foo' and 'bar' are the *SAME*. The recent "fix" effectively forced the test case to use the same "random" pkey for the whole test, unless the test run crossed a second boundary. Only run srand() once at program startup. This explains some very odd and persistent test failures I've been seeing. Link: https://lkml.kernel.org/r/20210611164153.91B76FB8@viggo.jf.intel.com Link: https://lkml.kernel.org/r/20210611164155.192D00FF@viggo.jf.intel.com Fixes: 6e373263ce07 ("selftests/vm/pkeys: fix alloc_random_pkey() to make it really random") Signed-off-by: Dave Hansen Signed-off-by: Thomas Gleixner Tested-by: Aneesh Kumar K.V Cc: Ram Pai Cc: Sandipan Das Cc: Florian Weimer Cc: "Desnes A. Nunes do Rosario" Cc: Ingo Molnar Cc: Thiago Jung Bauermann Cc: Michael Ellerman Cc: Michal Hocko Cc: Michal Suchanek Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

selftests/x86/fsgsbase: Test PTRACE_PEEKUSER for GSBASE with invalid LDT GS

2020-11-05T10:43:23+00:00

commit 1b9abd1755ad947d7c9913e92e7837b533124c90 upstream. This tests commit: 8ab49526b53d ("x86/fsgsbase/64: Fix NULL deref in 86_fsgsbase_read_task") Unpatched kernels will OOPS. Signed-off-by: Andy Lutomirski Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/c618ae86d1f757e01b1a8e79869f553cb88acf9a.1598461151.git.luto@kernel.org Signed-off-by: Greg Kroah-Hartman

selftests/x86/fsgsbase: Reap a forgotten child

2020-11-05T10:43:15+00:00

[ Upstream commit ab2dd173330a3f07142e68cd65682205036cd00f ] The ptrace() test forgot to reap its child. Reap it. Signed-off-by: Andy Lutomirski Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/e7700a503f30e79ab35a63103938a19893dbeff2.1598461151.git.luto@kernel.org Signed-off-by: Sasha Levin

selftests/x86/syscall_nt: Clear weird flags after each test

2020-10-01T11:18:10+00:00

[ Upstream commit a61fa2799ef9bf6c4f54cf7295036577cececc72 ] Clear the weird flags before logging to improve strace output -- logging results while, say, TF is set does no one any favors. Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/907bfa5a42d4475b8245e18b67a04b13ca51ffdb.1593191971.git.luto@kernel.org Signed-off-by: Sasha Levin

selftests/vm/pkeys: fix alloc_random_pkey() to make it really random

2020-06-24T15:50:39+00:00

[ Upstream commit 6e373263ce07eeaa6410843179535fbdf561fc31 ] alloc_random_pkey() was allocating the same pkey every time. Not all pkeys were geting tested. This fixes it. Signed-off-by: Ram Pai Signed-off-by: Sandipan Das Signed-off-by: Andrew Morton Acked-by: Dave Hansen Cc: Dave Hansen Cc: Florian Weimer Cc: "Desnes A. Nunes do Rosario" Cc: Ingo Molnar Cc: Thiago Jung Bauermann Cc: "Aneesh Kumar K.V" Cc: Michael Ellerman Cc: Michal Hocko Cc: Michal Suchanek Cc: Shuah Khan Link: http://lkml.kernel.org/r/0162f55816d4e783a0d6e49e554d0ab9a3c9a23b.1585646528.git.sandipan@linux.ibm.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

selftests/x86/ptrace_syscall_32: Fix no-vDSO segfault

2020-04-17T08:50:02+00:00

[ Upstream commit 630b99ab60aa972052a4202a1ff96c7e45eb0054 ] If AT_SYSINFO is not present, don't try to call a NULL pointer. Reported-by: kbuild test robot Signed-off-by: Andy Lutomirski Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/faaf688265a7e1a5b944d6f8bc0f6368158306d3.1584052409.git.luto@kernel.org Signed-off-by: Sasha Levin

selftests/x86/sigreturn/32: Invalidate DS and ES when abusing the kernel

2019-11-29T09:09:59+00:00

commit 4d2fa82d98d2d296043a04eb517d7dbade5b13b8 upstream. If the kernel accidentally uses DS or ES while the user values are loaded, it will work fine for sane userspace. In the interest of simulating maximally insane userspace, make sigreturn_32 zero out DS and ES for the nasty parts so that inadvertent use of these segments will crash. Signed-off-by: Andy Lutomirski Signed-off-by: Peter Zijlstra (Intel) Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman

selftests/x86/mov_ss_trap: Fix the SYSENTER test

2019-11-29T09:09:58+00:00

commit 8caa016bfc129f2c925d52da43022171d1d1de91 upstream. For reasons that I haven't quite fully diagnosed, running mov_ss_trap_32 on a 32-bit kernel results in an infinite loop in userspace. This appears to be because the hacky SYSENTER test doesn't segfault as desired; instead it corrupts the program state such that it infinite loops. Fix it by explicitly clearing EBP before doing SYSENTER. This will give a more reliable segfault. Fixes: 59c2a7226fc5 ("x86/selftests: Add mov_to_ss test") Signed-off-by: Andy Lutomirski Signed-off-by: Peter Zijlstra (Intel) Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman

Merge branch 'x86-entry-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2019-09-17T02:06:29+00:00

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

Merge branch 'x86/cleanups' into x86/cpu, to pick up dependent changes

2019-09-06T05:30:23+00:00

Signed-off-by: Ingo Molnar