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: Florian Weimer <fweimer at redhat dot com>
- To: Anthony Steinhauser <asteinhauser at google dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 22 Jan 2020 11:08:01 +0100
- Subject: Re: [PATCH] aarch64: fix speculative execution past SVC vulnerability
- References: <20200122012932.129013-1-asteinhauser@google.com>
* 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.
The PDF attached to the bug report says this:
| The speculative execution does not cross privilege-levels (to the jump
| target as one would expect), but it continues on the current privilege
| level as if those instructions did not change the control flow.
I assume that “current privilege level” means “user mode”.
Which is it? If it is possible to speculatively execute userspace code
in kernel mode, then a simple userspace code change will not fix this
because an attacker can simply use their own system call sequence.
Is there a performance benefit from inhibiting speculative execution?
It seems wasteful in many cases because it does take the side effects of
the system call into account.
Do we have to make this conditi onal on the CPU? It wouldn't be fair to
penalize vendors who implement this correctly. (As a general rule, I
really dislike software mitigation attempts because they are usually
incomplete and slow down execution for everyone, without actually fixing
any security issue.)
Thanks,
Florian