Messages in this thread | | | Date | Mon, 22 Aug 2011 16:46:24 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [uml-devel] SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386) |
| |
On 08/22/2011 04:27 PM, Linus Torvalds wrote: > On Mon, Aug 22, 2011 at 3:04 PM, H. Peter Anvin <hpa@zytor.com> wrote: >> >> However, we could just issue a SIGILL or SIGSEGV at this point; the same >> way we would if we got an #UD or #GP fault; SIGILL/#UD would be >> consistent with Intel CPUs here. > > Considering that this is not a remotely new issue, and that it has > been around for years without anybody even noticing, I'd really prefer > to just fix things going forwards rather than add any code to actively > break any possible unlucky legacy users. > > So I think the "let's fix the vdso case for sysenter" + "let's remove > the 32-bit syscall vdso" is the right solution. If somebody has > hardcoded syscall instructions, or generates them dynamically with > some JIT, that's their problem. We'll continue to support it as well > as we ever have (read: "almost nobody will ever notice"). > > One thing we *could* do is to just say "we never restart a x86-32 > 'syscall' instruction at all", and just make such a case return EINTR. > IOW, do something along the lines of the appended pseudo-patch. > > Because returning -EINTR is always "almost correct". >
I have to say it worries me from a potential security hole point of view, especially since it clearly isn't very well trod ground to begin with. An almost-never-used path with access to the full system call suite is scarier than hell in that sense.
Keep in mind support for SYSCALL32 is already (vendor-)conditional.
(The obvious solution of just putting the proper register frame back in its place would be okay except for totally breaking anything trace-on-exit as already hashed to death...)
-hpa
| |