[lkml]   [2011]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386)
    On 08/21/2011 06:41 PM, Linus Torvalds wrote:
    > 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.
    > That said, I'd *hope* that everybody uses the vdso32, simply because
    > user programs are not supposed to know which CPU they are running on
    > and if that CPU even *supports* the syscall instruction. In which case
    > it may be possible that we can play games with the vdso thing. But
    > that really would be conditional on "nobody ever reports a failure".

    I think we found that out with the vsyscall emulation issue last cycle.
    It works, so it will have been used, somewhere...

    > But if that's possible, maybe we can increment the RIP by 2 for
    > 'syscall', and slip an "'int 0x80" after the syscall instruction in
    > the vdso there? Resulting in the same pseudo-solution I suggested for
    > sysenter...

    I think we have the above problem.

    The problem here is that the syscall state is actually more complex than
    we retain: the entire state is given by (entry point, register state);
    with that amount of state we have all the information needed to *either*
    extract the syscall arguments *or* the register contents. Without
    those, we can only represent one of the two possible metalevels (right
    now we represent the higher-level metalevel, the argument vector), but
    we need both for different usages.


    H. Peter Anvin, Intel Open Source Technology Center
    I work for Intel. I don't speak on their behalf.

     \ /
      Last update: 2011-08-22 03:51    [W:0.020 / U:43.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site