This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] aarch64: fix speculative execution past SVC vulnerability
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Anthony Steinhauser <asteinhauser at google dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: nd <nd at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Date: Wed, 22 Jan 2020 10:08:51 +0000
- Subject: Re: [PATCH] aarch64: fix speculative execution past SVC vulnerability
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BhDoIby6sts0VXcaTMmxoxEXjR5rMCe1mNrxU3g49iY=; b=CFvpMFeau8rLv0d9sT5XMCXP52WgpO24B7uEB+gmgY5yX+aU8O4sMSFb6j+yPZFqacXrjhKL38XsLCPoHLRTwjCnc+zKWPI9LDQGVWzpHtBkY32vA4zYQQUcRkSwJHmCFQH8nBKhegsjXq/7Cva2Ahn9YChHs+fnLQO+Chtq5KfM3Z1zxWdSkO0i84HyLJ/FhVdglyI6R0cTxYhiR6kG/rhMPxCNiIdCVpHTdEwqJer85dXSqWVchuA4v5LV0PGEhn6XLYiJSOMX3idFnUqcWOETdP1r/Z8ZGClTXHVigyc2+ej1yzvnp17+VUPxC1LKLIplCe46OWz4g+GAi9VsmA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bs7hAR57y+cADlXN1KtRM+yyDEiHw/o2EUganhHlc0ZfD6V5MRlngvX+IAtspoGuLmOWnfFCNvxq4ZMmTZBOxacSAYL+aUgT8OP3hr7cEjH+Zj6Qa0zFFb2qLc5fnjfH5zMNQv/c9Xy1LOCwEJWDlclVjhlXxK7yfYvJjZhKHpgiYVcI46ErUymJIHLyafd4t7YtV/hucbyEnE1fNHUJ+KfhaoPa/KIzp7BpJOBP6cINd05+E+HswAcRiuH4wD+ZYNrUogzaTN5Z7MUDrkODd/QDSQdFzZqFhfBxGZtTUD6kvxb82RuOIl4pIBCOrwIS7NG37+lDnjhCXggPTd88SQ==
- Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- References: <20200122012932.129013-1-asteinhauser@google.com>
On 22/01/2020 01:29, Anthony Steinhauser wrote:
> Even though SVC always causes a jump to another address, aarch64 CPUs
> speculatively execute following instructions as if the SVC
> instruction was not a jump instruction.
thanks for the patch, it looks good, but i add
somebody on cc who spent more time on spectre
mitigation in case there is further insight.
> The speculative execution does not cross privilege-levels (to the jump
> target as one would expect), but it continues on the kernel privilege
> level as if the SVC instruction did not change the control flow -
i don't understand this bit: why is anything
executing on the kernel privilege level here?
> thus execution anything that is accidentally linked after the SVC
> instruction. Later, the results of this speculative execution are
> always architecturally discarded, however they can leak data using
> microarchitectural side channels. This speculative execution is very
> reliable (seems to be unconditional) and it manages to complete even
> relatively performance-heavy operations (e.g. multiple dependent
> fetches from uncached memory).
>
> Something like:
> read(2)
> ...
> [parse read result]
> Gets potentially dangerous, since this would allow us potentially
> reasonably reliably hit uninitialized memory (with potentially attacker
> controlled offsets from prior reads) if we speculate over the SVC in the
> syscall. Particularly in a netspectre-like scope.
>
> Bugzilla record:
> https://sourceware.org/bugzilla/show_bug.cgi?id=25436
>
> Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
> ---
> sysdeps/unix/sysv/linux/aarch64/sysdep.h | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/sysdeps/unix/sysv/linux/aarch64/sysdep.h b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
> index 00b8e241c8..cf1e6ed45f 100644
> --- a/sysdeps/unix/sysv/linux/aarch64/sysdep.h
> +++ b/sysdeps/unix/sysv/linux/aarch64/sysdep.h
> @@ -147,7 +147,9 @@
> # undef DO_CALL
> # define DO_CALL(syscall_name, args) \
> mov x8, SYS_ify (syscall_name); \
> - svc 0
> + svc 0; \
> + dsb nsh; \
> + isb
>
> #else /* not __ASSEMBLER__ */
>
> @@ -191,7 +193,9 @@
> { \
> LOAD_ARGS_##nr (args) \
> register long _x8 asm ("x8") = (name); \
> - asm volatile ("svc 0 // syscall " # name \
> + asm volatile ("svc 0 // syscall\n\t" # name \
> + "dsb nsh\n\t" \
> + "isb" \
> : "=r" (_x0) : "r"(_x8) ASM_ARGS_##nr : "memory"); \
> _sys_result = _x0; \
> } \
>