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
I get it. Sorry for the confusion.
On Wed, Jan 22, 2020 at 12:43 PM Andrew Pinski <pinskia@gmail.com> wrote:
>
> On Wed, Jan 22, 2020 at 12:39 PM Anthony Steinhauser
> <asteinhauser@google.com> wrote:
> >
> > *Florian Weimer
> > It's the user mode in the case of SVC instruction. I incorrectly
> > copied that passage from the ERET kernel fixes. Sorry for that.
> > If there are vendors or CPUs who implement this correctly, it would be
> > good to make it CPU-specific.
> > On the ARM and Cavium CPUs that I tested the control flow past SVC is
> > always mispredicted, so it seems like the barrier there would have
> > little if any overhead.
> > However, it does not enhance the performance either. It just prevents
> > very similar Spectre-like effects as in the ERET case.
> >
> > *Szabolcs Nagy
> > I'm not sure whether the endline should be wrong. Without it, the
> > resulting assembly would look like:
> > svc 0 // syscall dsb nsh
> > isb
> > So the dsb nsh instruction will be commented-out. Or am I missing something?
>
> He means the return (\n) is misplaced. It should be after the #name.
> e.g.
> asm volatile ("svc 0 // syscall" # name "\n\t"
>
> Thanks,
> Andrew Pinski
>
> >
> >
> > On Wed, Jan 22, 2020 at 2:12 AM Szabolcs Nagy <Szabolcs.Nagy@arm.com> wrote:
> > >
> > > On 22/01/2020 10:08, Szabolcs Nagy wrote:
> > > > On 22/01/2020 01:29, Anthony Steinhauser wrote:
> > > >> { \
> > > >> LOAD_ARGS_##nr (args) \
> > > >> register long _x8 asm ("x8") = (name); \
> > > >> - asm volatile ("svc 0 // syscall " # name \
> > > >> + asm volatile ("svc 0 // syscall\n\t" # name \
> > >
> > > \n before the name looks wrong
> > >
> > > >> + "dsb nsh\n\t" \
> > > >> + "isb" \
> > > >> : "=r" (_x0) : "r"(_x8) ASM_ARGS_##nr : "memory"); \
> > > >> _sys_result = _x0; \
> > > >> } \