On Aug 22, 2011 9:01 PM, "Al Viro" <viro@zeniv.linux.org.uk> wrote:
>
> On Mon, Aug 22, 2011 at 05:22:07PM -0700, Linus Torvalds wrote:
>
> > You guys seem to positively _want_ to make this a bigger issue than it
> > is. As far as I can tell, nobody has ever even noticed this problem
> > before, and we already have a trivial fix ("don't do it then") for the
> > case Al actually did notice.
>
> I'm not sure.   What I've noticed was complete weirdness in uml,
apparently
> dependent on SYSCALL vs. SYSENTER or int 0x80.  With following round of
> RTFS and finding what looks like an ugly issue with restarts.
>
> What I don't understand at all is how the hell do we manage to avoid much
> more obvious breakage all the time we ptrace a 32bit task.  Look:
> __kernel_vsyscall() is
>        push    %ebp
>        movl    %ecx, %ebp
>        syscall
>        movl    $__USER32_DS, %ecx
>        movl    %ecx, %ss
>        movl    %ebp, %ecx
>        popl    %ebp
>
> now, what is going to happen to %ebp if we go through IRET path, for any
> reason?  From my reading it appears that right after that IRET we'll have
> ebp containing arg6.  I.e. what we'd pushed on stack.  Now, popl %ebp
> will bring the same value back.  Not a problem.  But what about
> movl %ebp, %ecx?  Again, I'm talking about the case when we have no
> restart at all - just an strace(1) tracing a process.

I suspect that very few things care whether syscall arguments get
clobbered.  The only way it would matter is if gcc reuses the argument in
the ecx slot after an inlined syscall later in the same function.  Any code
that does that is already wrong if the syscall restarts with changed ecx or
if something like UML changes the syscall argument.

--Andy

>
> AFAICS, in that case we ought to have %ecx == %ebp after return from
> __kernel_vsyscall().  Which would blow the things up _very_ fast.
>
> So what the hell am I missing here?