From: Ammar Faizi <ammarfaizi2@gnuweeb.org>
To: Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
Dave Hansen <dave.hansen@intel.com>, Xin Li <xin3.li@intel.com>
Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org>,
Andrew Cooper <Andrew.Cooper3@citrix.com>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
x86 Mailing List <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Kselftest Mailing List <linux-kselftest@vger.kernel.org>,
GNU/Weeb Mailing List <gwml@vger.gnuweeb.org>
Subject: [RESEND RFC PATCH v8 2/3] selftests/x86: sysret_rip: Add more tests to verify the 'syscall' behavior
Date: Mon, 20 Feb 2023 10:09:58 +0700 [thread overview]
Message-ID: <20230220030959.119222-3-ammarfaizi2@gnuweeb.org> (raw)
In-Reply-To: <20230220030959.119222-1-ammarfaizi2@gnuweeb.org>
There are two cases:
A) 'syscall' in a FRED system preserves %rcx and %r11.
B) 'syscall' in a non-FRED system sets %rcx=%rip and %r11=%rflags.
When the do_syscall() function is called for the first time, it will
memorize the behavior, either (A) or (B). Then, the next do_syscall()
call will verify that the 'syscall' behavior is the same.
Test them with trivial system calls like __NR_getppid and friends, which
are highly likely to return with SYSRET on an IDT system.
The purposes of this test are:
- Ensure that the syscall behavior is consistent. It must always be
(A) or always be (B). Not a mix of them.
- Ensure that the kernel doesn't leak its internal data when returning
to userspace.
Cc: Xin Li <xin3.li@intel.com>
Link: https://lore.kernel.org/lkml/25b96960-a07e-a952-5c23-786b55054126@zytor.com
Co-developed-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org>
---
tools/testing/selftests/x86/sysret_rip.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/x86/sysret_rip.c b/tools/testing/selftests/x86/sysret_rip.c
index 300104900192d396..1531593b50d02150 100644
--- a/tools/testing/selftests/x86/sysret_rip.c
+++ b/tools/testing/selftests/x86/sysret_rip.c
@@ -266,8 +266,21 @@ static void test_syscall_fallthrough_to(unsigned long ip)
printf("[OK]\tWe survived\n");
}
+/* See the comment in do_syscall(). */
+static void test_syscall_rcx_r11_consistent(void)
+{
+ do_syscall(__NR_getpid, 0, 0, 0, 0, 0, 0);
+ do_syscall(__NR_gettid, 0, 0, 0, 0, 0, 0);
+ do_syscall(__NR_getppid, 0, 0, 0, 0, 0, 0);
+}
+
int main()
{
+ int i;
+
+ for (i = 0; i < 32; i++)
+ test_syscall_rcx_r11_consistent();
+
/*
* When the kernel returns from a slow-path syscall, it will
* detect whether SYSRET is appropriate. If it incorrectly
@@ -275,7 +288,7 @@ int main()
* it'll crash on Intel CPUs.
*/
sethandler(SIGUSR1, sigusr1, 0);
- for (int i = 47; i < 64; i++)
+ for (i = 47; i < 64; i++)
test_sigreturn_to(1UL<<i);
clearhandler(SIGUSR1);
@@ -286,7 +299,7 @@ int main()
test_syscall_fallthrough_to((1UL << 47) - 2*PAGE_SIZE);
/* These are the interesting cases. */
- for (int i = 47; i < 64; i++) {
+ for (i = 47; i < 64; i++) {
test_syscall_fallthrough_to((1UL<<i) - PAGE_SIZE);
test_syscall_fallthrough_to(1UL<<i);
}
--
Ammar Faizi
next prev parent reply other threads:[~2023-02-20 3:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-20 3:09 [RESEND RFC PATCH v8 0/3] Intel FRED architecture support for the sysret_rip selftest Ammar Faizi
2023-02-20 3:09 ` [RESEND RFC PATCH v8 1/3] selftests/x86: sysret_rip: Handle syscall on the Intel FRED architecture Ammar Faizi
2023-02-20 3:09 ` Ammar Faizi [this message]
2023-02-20 3:09 ` [RESEND RFC PATCH v8 3/3] selftests/x86: sysret_rip: Test SYSRET with a signal handler Ammar Faizi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230220030959.119222-3-ammarfaizi2@gnuweeb.org \
--to=ammarfaizi2@gnuweeb.org \
--cc=Andrew.Cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=gwml@vger.gnuweeb.org \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xin3.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox