From patchwork Wed Jan 22 01:29:32 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Anthony Steinhauser X-Patchwork-Id: 37460 Received: (qmail 107662 invoked by alias); 22 Jan 2020 01:29:43 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 107647 invoked by uid 89); 22 Jan 2020 01:29:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy=channels, manages, privilege, 1939 X-HELO: mail-pj1-f74.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=EolQ8G/OSOEy5EBpukvUWalCg8m1sKzOC8F1Xhgh7f8=; b=itQh3+lyTW7dh/V2ogMF/ZGu+nqG4sNDyyvWtsnoRQIdcPmVn77bMKhlAfUd5mNxfN E4hQhacbi3qY+PC4b/umNRi1WkAwqrwr3uGaSW95wvq22HV6iVJ533+gcIpnEAt3dPNf HfBEVEqSToi+UN9SyGoxbaIAkTWBCOx4WNdSx4aMNRTTmsk5sETUVii7otc2nfvShdJd ZTh+NfhK70ACnEKMicA+2hFOpDsQHFAFja1klwHWCPoaokWX1CkduKxOSnlX+jZWADgI yEF9Dcxk858iwjrnFRaRNZiSMeoUJ71KlB0NJXEQOUx7TLzTtaNDPAowbf2nDm0utkAB rUog== Date: Tue, 21 Jan 2020 17:29:32 -0800 Message-Id: <20200122012932.129013-1-asteinhauser@google.com> Mime-Version: 1.0 Subject: [PATCH] aarch64: fix speculative execution past SVC vulnerability From: Anthony Steinhauser To: libc-alpha@sourceware.org Cc: Anthony Steinhauser 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. 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 - 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 --- 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; \ } \