[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1587536988.ivnp421w2w.astroid@bobo.none>
Date: Wed, 22 Apr 2020 16:54:18 +1000
From: Nicholas Piggin <npiggin@...il.com>
To: Adhemerval Zanella <adhemerval.zanella@...aro.org>, Rich Felker
<dalias@...c.org>, David Laight <David.Laight@...LAB.COM>
Cc: "libc-alpha@...rceware.org" <libc-alpha@...rceware.org>,
"libc-dev@...ts.llvm.org" <libc-dev@...ts.llvm.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"musl@...ts.openwall.com" <musl@...ts.openwall.com>, Segher Boessenkool
<segher@...nel.crashing.org>
Subject: Re: Powerpc Linux 'scv' system call ABI proposal take 2
Let me try to summarise what we have.
- vdso style call is ruled out as unnecessary with possible security
concerns. Caller can internally use indirect branch to select variant
if it wants to use that mechanism to select.
- LR clobber seems to handled okay by gcc. It can increase size of small
leaf wrapper functions, but they can use the caller stack frame for
this (and even red zone for saving other things if necessary), but not
a huge amount.
- -ve error return seems to be favoured by everyone. Experimentally,
it's better for musl (but musl could probably improve cr0[SO] error
handling a bit 'asm goto').
- Preserving syscall args and volatiles up to r8 is a small but
noticable help for cases that inline the call rather than always call
wrappers. This is unlikely to be helpful unless 'sc' support is
compiled out but I'll consider doing it for the long term. Next step
is to trace and test on real hardware.
- One thing that nobody has really asked about is error handling for
unsupported scv vectors, so I would like to just go over it:
Today, the scv facility is disabled by the kernel (FSCR[SCV] is
cleared), which makes any `scv` instruction take a facility
unavailable, which ends up printing a kernel message about SCV
facility unavilable, and SIGILL's the process with ILL_ILLOPC.
Enabling 'scv 0' will enable 1-127 as well, so the kernel has to handle
those somehow.
What we are saying is that we will allocate HWCAP bits in future if we
implement more scv vectors, so userspace is not *supposed* to rely on
this, but kernel has to choose some behaviour for invalid vectors.
My proposal was to do the same SIGILL (with no kernel facility message),
so it appears to behave the same way to userspace as it does now. There
is also the ILL_ILLOPN code that could be used as invalid operand, but
powerpc does not use this much, and e.g., the static instruction
coded operands e.g., invalid mfspr generate ILL_ILLOPC so we could
consider the entire instruction as the opcode, and input register values
as operands.
Now I don't know why a process would want to distinguish between
FSCR[SCV]=0 and the case where it is enabled but kernel doesn't
implement the vector, but maybe it does?
Another option would be to use a different signal. I don't see that any
are more suitable.
Or return without a signal but -ENOSYS or something in r3. This doesn't
seem so good because an invalid scv vector is not a system call, and a
failure ABI would constrain any future implementation just a little bit.
Any objections to SIGILL ILL_ILLOPC?
Thanks,
Nick
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
