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 thanwe 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. Withoutthose, we can only represent one of the two possible metalevels (rightnow we represent the higher-level metalevel, the argument vector), butwe need both for different usages.

-hpa

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