#
d17e752b |
| 27-Mar-2024 |
Muhammad Usama Anjum <usama.anjum@collabora.com> |
selftests: x86: test_vsyscall: conform test to TAP format output
Conform the layout, informational and status messages to TAP. No functional change is intended other than the layout of output messag
selftests: x86: test_vsyscall: conform test to TAP format output
Conform the layout, informational and status messages to TAP. No functional change is intended other than the layout of output messages. Add more logic code to skip the tests if particular configuration isn't available to make sure that either we skip each test or mark it pass/fail.
Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
113ad23f |
| 27-Mar-2024 |
Muhammad Usama Anjum <usama.anjum@collabora.com> |
selftests: x86: test_vsyscall: reorder code to reduce #ifdef blocks
There are multiple #ifdef blocks inside functions where they return just 0 if #ifdef is false. This makes number of tests counting
selftests: x86: test_vsyscall: reorder code to reduce #ifdef blocks
There are multiple #ifdef blocks inside functions where they return just 0 if #ifdef is false. This makes number of tests counting difficult. Move those functions inside one #ifdef block and move all of them together. This is preparatory patch for next patch to convert this into TAP format. So in this patch, we are just moving functions around without any changes.
With and without this patch, the output of this patch is same.
Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
5646bbd6 |
| 25-Nov-2022 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
selftests: Emit a warning if getcpu() is missing on 32bit
The VDSO implementation for getcpu() has been wired up on 32bit so warn if missing.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linut
selftests: Emit a warning if getcpu() is missing on 32bit
The VDSO implementation for getcpu() has been wired up on 32bit so warn if missing.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20221125094216.3663444-4-bigeasy@linutronix.de
show more ...
|
#
dd40f44e |
| 21-Oct-2021 |
Shuah Khan <skhan@linuxfoundation.org> |
selftests: x86: fix [-Wstringop-overread] warn in test_process_vm_readv()
Fix the following [-Wstringop-overread] by passing in the variable instead of the value.
test_vsyscall.c: In function ‘test
selftests: x86: fix [-Wstringop-overread] warn in test_process_vm_readv()
Fix the following [-Wstringop-overread] by passing in the variable instead of the value.
test_vsyscall.c: In function ‘test_process_vm_readv’: test_vsyscall.c:500:22: warning: ‘__builtin_memcmp_eq’ specified bound 4096 exceeds source size 0 [-Wstringop-overread] 500 | if (!memcmp(buf, (const void *)0xffffffffff600000, 4096)) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
8891adc6 |
| 03-Sep-2020 |
Andy Lutomirski <luto@kernel.org> |
selftests/x86/test_vsyscall: Improve the process_vm_readv() test
The existing code accepted process_vm_readv() success or failure as long as it didn't return garbage. This is too weak: if the vsysc
selftests/x86/test_vsyscall: Improve the process_vm_readv() test
The existing code accepted process_vm_readv() success or failure as long as it didn't return garbage. This is too weak: if the vsyscall page is readable, then process_vm_readv() should succeed and, if the page is not readable, then it should fail.
Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: x86@kernel.org Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Jann Horn <jannh@google.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
cced0b24 |
| 26-Jun-2020 |
Andy Lutomirski <luto@kernel.org> |
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 <luto@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/982ce58ae8dea2f1e57093ee894760e35267e751.1593191971.git.luto@kernel.org
show more ...
|
#
399ea57a |
| 01-Jul-2019 |
Colin Ian King <colin.king@canonical.com> |
selftests/x86: fix spelling mistake "FAILT" -> "FAIL"
There is an spelling mistake in an a test error message. Fix it.
Acked-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Colin Ian King <col
selftests/x86: fix spelling mistake "FAILT" -> "FAIL"
There is an spelling mistake in an a test error message. Fix it.
Acked-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
7f0a5e07 |
| 27-Jun-2019 |
Andy Lutomirski <luto@kernel.org> |
selftests/x86: Add a test for process_vm_readv() on the vsyscall page
get_gate_page() is a piece of somewhat alarming code to make get_user_pages() work on the vsyscall page. Test it via process_vm
selftests/x86: Add a test for process_vm_readv() on the vsyscall page
get_gate_page() is a piece of somewhat alarming code to make get_user_pages() work on the vsyscall page. Test it via process_vm_readv().
Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Florian Weimer <fweimer@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Kernel Hardening <kernel-hardening@lists.openwall.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lkml.kernel.org/r/0fe34229a9330e8f9de9765967939cc4f1cf26b1.1561610354.git.luto@kernel.org
show more ...
|
#
b0386979 |
| 27-Jun-2019 |
Andy Lutomirski <luto@kernel.org> |
selftests/x86/vsyscall: Verify that vsyscall=none blocks execution
If vsyscall=none accidentally still allowed vsyscalls, the test wouldn't fail. Fix it.
Signed-off-by: Andy Lutomirski <luto@kerne
selftests/x86/vsyscall: Verify that vsyscall=none blocks execution
If vsyscall=none accidentally still allowed vsyscalls, the test wouldn't fail. Fix it.
Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Florian Weimer <fweimer@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Kernel Hardening <kernel-hardening@lists.openwall.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lkml.kernel.org/r/b413397c804265f8865f3e70b14b09485ea7c314.1561610354.git.luto@kernel.org
show more ...
|
#
e0a446ce |
| 27-Jun-2019 |
Andy Lutomirski <luto@kernel.org> |
x86/vsyscall: Document odd SIGSEGV error code for vsyscalls
Even if vsyscall=none, user page faults on the vsyscall page are reported as though the PROT bit in the error code was set. Add a comment
x86/vsyscall: Document odd SIGSEGV error code for vsyscalls
Even if vsyscall=none, user page faults on the vsyscall page are reported as though the PROT bit in the error code was set. Add a comment explaining why this is probably okay and display the value in the test case.
While at it, explain why the behavior is correct with respect to PKRU.
Modify also the selftest to print the odd error code so that there is a way to demonstrate the odd behaviour.
If anyone really cares about more accurate emulation, the behaviour could be changed. But that needs a real good justification.
Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Florian Weimer <fweimer@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Kernel Hardening <kernel-hardening@lists.openwall.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lkml.kernel.org/r/75c91855fd850649ace162eec5495a1354221aaa.1561610354.git.luto@kernel.org
show more ...
|
#
076ca272 |
| 07-Mar-2018 |
Andy Lutomirski <luto@kernel.org> |
x86/vsyscall/64: Drop "native" vsyscalls
Since Linux v3.2, vsyscalls have been deprecated and slow. From v3.2 on, Linux had three vsyscall modes: "native", "emulate", and "none".
"emulate" is the
x86/vsyscall/64: Drop "native" vsyscalls
Since Linux v3.2, vsyscalls have been deprecated and slow. From v3.2 on, Linux had three vsyscall modes: "native", "emulate", and "none".
"emulate" is the default. All known user programs work correctly in emulate mode, but vsyscalls turn into page faults and are emulated. This is very slow. In "native" mode, the vsyscall page is easily usable as an exploit gadget, but vsyscalls are a bit faster -- they turn into normal syscalls. (This is in contrast to vDSO functions, which can be much faster than syscalls.) In "none" mode, there are no vsyscalls.
For all practical purposes, "native" was really just a chicken bit in case something went wrong with the emulation. It's been over six years, and nothing has gone wrong. Delete it.
Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Kernel Hardening <kernel-hardening@lists.openwall.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/519fee5268faea09ae550776ce969fa6e88668b0.1520449896.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
d8e92de8 |
| 11-Feb-2018 |
Dominik Brodowski <linux@dominikbrodowski.net> |
selftests/x86: Clean up and document sscanf() usage
Replace a couple of magically connected buffer length literal constants with a common definition that makes their relationship obvious. Also docum
selftests/x86: Clean up and document sscanf() usage
Replace a couple of magically connected buffer length literal constants with a common definition that makes their relationship obvious. Also document why our sscanf() usage is safe.
No intended functional changes.
Suggested-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Andrew Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> 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/20180211205924.GA23210@light.dominikbrodowski.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
352909b4 |
| 12-Jan-2018 |
Andy Lutomirski <luto@kernel.org> |
selftests/x86: Add test_vsyscall
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 mad
selftests/x86: Add test_vsyscall
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>
show more ...
|