Messages in this thread | | | Date | Sun, 21 Aug 2011 21:11:54 -0700 | From | "H. Peter Anvin" <> | Subject | Re: SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386) |
| |
On 08/21/2011 09:07 PM, Al Viro wrote: > On Sun, Aug 21, 2011 at 06:41:16PM -0700, Linus Torvalds wrote: >> On Sun, Aug 21, 2011 at 6:16 PM, Al Viro <viro@zeniv.linux.org.uk> wrote: >>> >>> Is that ability a part of userland ABI or are we declaring that hopelessly >>> wrong and require to go through the function in vdso32? ?Linus? >> >> If people are using syscall directly, we're pretty much stuck. No >> amount of "that's hopelessly wrong" will ever matter. We don't break >> existing binaries. > > There's a funny part, though - such binary won't work on 32bit kernel. > AFAICS, we never set MSR_*STAR on 32bit kernels (and native 32bit vdso > doesn't provide a SYSCALL-based variant). > > So if we really consider such SYSCALL outside of vdso32 kosher, shouldn't > we do something with entry_32.S as well? I don't think it's worth doing, > TBH... > > Again, I very much hope that binaries with such stray SYSCALL simply do > not exist. In theory it's possible to write one, but... > > IIRC, the reason we never had SYSCALL support in 32bit kernel was the utter > lack of point - the *only* CPU where it would matter would be K6-2, IIRC, > and (again, IIRC) it had some differences in SYSCALL semantics compared to > K7 (which supports SYSENTER as well). Bugger if I remember what those > differences might've been... Some flag not cleared?
The most likely reason for a binary to execute a stray SYSCALL is because they read it out of the vdso. Totally daft, but we certainly see a lot of stupid things as evidenced by the JIT thread earlier this month.
In that sense, a "safe" thing would be to drop use of SYSCALL for 32-bit processes... I just sent Borislav a query about the cost.
-hpa
-- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
| |