On Mon, Aug 22, 2011 at 11:15 PM, Al Viro wrote:
>
> * it does SETREGS, setting eax to return value, eip to original return
> address of syscall insn... and ebp to what it had in regs.bp. I.e. the
> damn arg6 value.
Ok, I think that exhaustively explains that
(a) our system call restart has al
On Tue, Aug 23, 2011 at 12:03 PM, Linus Torvalds
wrote:
> On Mon, Aug 22, 2011 at 11:15 PM, Al Viro wrote:
>>
>> * it does SETREGS, setting eax to return value, eip to original return
>> address of syscall insn... and ebp to what it had in regs.bp. I.e. the
>> damn arg6 value.
>
> Ok, I think th
On Tue, Aug 23, 2011 at 02:15:31AM -0400, Al Viro wrote:
> Almost, but not quite. What happens is:
> * process hits syscall insn
> * it's stopped and tracer (guest kernel) does GETREGS
> + looks at the registers (mapped to the normal layout)
> + decides to call sys_brk()
> + noti
On Tue, Aug 23, 2011 at 9:11 AM, Andrew Lutomirski wrote:
>
> Egads. Does this mean that doing GETREGS and then doing SETREGS later
> on with the *exact same values* is considered incorrect?
No. If it does it with exactly the same values, it's perfectly ok. But
it isn't. It's changing some of th
On Tue, Aug 23, 2011 at 9:22 AM, Borislav Petkov wrote:
>
> I don't think that removing SYSCALL from 32-bit code just so that UML
> trapped syscalls work is something we'd like since SYSCALL is much
> cheaper than INT $0x80:
Oh yes.
System call performance is *important*. And x86 is *important*.
On Tue, Aug 23, 2011 at 04:26:08PM +0200, Borislav Petkov wrote:
> On Tue, Aug 23, 2011 at 02:15:31AM -0400, Al Viro wrote:
> > Almost, but not quite. What happens is:
> > * process hits syscall insn
> > * it's stopped and tracer (guest kernel) does GETREGS
> > + looks at the registers (mapped
On Tue, Aug 23, 2011 at 09:03:04AM -0700, Linus Torvalds wrote:
> Suggested fixes:
>
> - instead of blindly doing SETREGS, just write the result registers
> individually like you suggested
Not enough. There is also a PITA with signal handlers. There we can't
avoid modifying ebp on the way out
On Tue, Aug 23, 2011 at 09:29:29AM -0700, Linus Torvalds wrote:
> Oh yes.
>
> System call performance is *important*. And x86 is *important*.
>
> UML? In comparison, not that important.
>
> So quite frankly, if this is purely an UML issue (and unless we're
> missing something else, that's what
Am 23.08.2011 18:53, schrieb Al Viro:
> On Tue, Aug 23, 2011 at 09:29:29AM -0700, Linus Torvalds wrote:
>
>> Oh yes.
>>
>> System call performance is *important*. And x86 is *important*.
>>
>> UML? In comparison, not that important.
>>
>> So quite frankly, if this is purely an UML issue (and unless
On Tue, Aug 23, 2011 at 06:58:18PM +0200, Richard Weinberger wrote:
> What about this hack/solution?
> While booting UML can check whether the host's vDSO contains
> a SYSCALL instruction.
> If so, UML will not make the host's vDSO available to it's
> processes...
Note that this is *only* for 32b
Am 23.08.2011 19:07, schrieb Al Viro:
> On Tue, Aug 23, 2011 at 06:58:18PM +0200, Richard Weinberger wrote:
>
>> What about this hack/solution?
>> While booting UML can check whether the host's vDSO contains
>> a SYSCALL instruction.
>> If so, UML will not make the host's vDSO available to it's
>>
On Tue, Aug 23, 2011 at 09:20:12AM -0700, Linus Torvalds wrote:
> It's EMULATING A SYSTEM CALL. That original "getregs" value is not
> some "user space state". It's the *system call* state that you got
> after the system call trapped. Setting it back is an insane operation,
> but it would happen t
On Tue, Aug 23, 2011 at 9:48 AM, Al Viro wrote:
>
> Um... How would it know which syscall variant had that been, to start
> with?
Just read the instruction, for chissake.
UML *already* does that, to see if it's "int80" or "sysenter" ('is_syscall()').
Now, I do agree that if we had designed the
On Tue, Aug 23, 2011 at 06:33:17PM +0100, Al Viro wrote:
> * SYSCALL is not terminally broken wrt restarts. My apologies for
> misreading what was going on.
> * SYSENTER with Linus' patch does work just fine wrt restarts + ptrace
> * SYSCALL is losing ptrace-made changes to argum
On Tue, Aug 23, 2011 at 12:11:43PM -0400, Andrew Lutomirski wrote:
> In any case, this seems insanely overcomplicated. I'd be less afraid
> of something like my approach (which, I think, makes all of the
> SYSCALL weirdness pretty much transparent to ptrace users) or of just
> removing SYSCALL ent
On 08/23/2011 09:22 AM, Borislav Petkov wrote:
> On Tue, Aug 23, 2011 at 12:11:43PM -0400, Andrew Lutomirski wrote:
>> In any case, this seems insanely overcomplicated. I'd be less afraid
>> of something like my approach (which, I think, makes all of the
>> SYSCALL weirdness pretty much transparen
On 08/23/2011 09:48 AM, Al Viro wrote:
>
> Um... How would it know which syscall variant had that been, to start
> with? For int 0x80 it would need to use registers as-is. For SYSENTER
> it also could use them as-is - ebp will differ from what we put there
> when entering the sucker, but not cr
On Tue, Aug 23, 2011 at 12:18 PM, H. Peter Anvin wrote:
>
> We could drop that information in a metaregister. It's not backward
> compatible, but at least it will be obvious when that information is
> available and not.
Well, seriously, UML already looks at the word at "ip-2" for other
reasons.
On 08/23/2011 12:24 PM, Linus Torvalds wrote:
> On Tue, Aug 23, 2011 at 12:18 PM, H. Peter Anvin wrote:
>>
>> We could drop that information in a metaregister. It's not backward
>> compatible, but at least it will be obvious when that information is
>> available and not.
>
> Well, seriously, UML
On Tue, Aug 23, 2011 at 12:24:22PM -0700, Linus Torvalds wrote:
> On Tue, Aug 23, 2011 at 12:18 PM, H. Peter Anvin wrote:
> >
> > We could drop that information in a metaregister. ?It's not backward
> > compatible, but at least it will be obvious when that information is
> > available and not.
>
On Tue, Aug 23, 2011 at 12:41 PM, Al Viro wrote:
>
> And it's not cheap - doing that on each syscall will be unpleasant...
> Frankly, I'd rather stopped telling the uml userland about vdso in such
> setups. And anything that plays with SYSCALL outside of vdso...
> we already have a "don't run it
On 08/23/2011 01:56 PM, Borislav Petkov wrote:
>
> But no, I don't think the difference has disappeared - to the contrary,
> AFAICT, the intention is for SYSCALL to be the fastest way to do
> syscalls on x86 due to diminished number of segment checks etc. INT80
> is legacy, slower, etc. I believe
On 08/23/2011 10:33 AM, Linus Torvalds wrote:
>
> It would be *nice* if we did the swizzling automatically at setregs()
> time too, but we simply don't have enough information in the kernel to
> do that. Again, exactly because pt_regs doesn't have a "state"
> variable, when user-space does the SET
On Tue, Aug 23, 2011 at 12:43:28PM -0700, Linus Torvalds wrote:
> On Tue, Aug 23, 2011 at 12:41 PM, Al Viro wrote:
> >
> > And it's not cheap - doing that on each syscall will be unpleasant...
> > Frankly, I'd rather stopped telling the uml userland about vdso in such
> > setups. ?And anything tha
On Tue, Aug 23, 2011 at 2:08 PM, H. Peter Anvin wrote:
>
> Again, can we steal one of the padding fields to use for that state
> variable? We have two 16-bit padding fields; one for cs and one for ss.
We can steal them for passing the information to the user, but no, I
don't think we can use the
On Tue, Aug 23, 2011 at 03:15:58PM -0400, H. Peter Anvin wrote:
> Right, but if you had said the difference had disappeared on current AMD
> silicon it would be much less of an issue. That's why I wanted to find
> that bit out from you.
Yeah, I dug this out in the APM, btw.
But no, I don't think
On Tue, Aug 23, 2011 at 05:06:03PM -0400, H. Peter Anvin wrote:
> On 08/23/2011 01:56 PM, Borislav Petkov wrote:
> >
> > But no, I don't think the difference has disappeared - to the contrary,
> > AFAICT, the intention is for SYSCALL to be the fastest way to do
> > syscalls on x86 due to diminishe
On 08/23/2011 02:20 PM, Linus Torvalds wrote:
> On Tue, Aug 23, 2011 at 2:08 PM, H. Peter Anvin wrote:
>>
>> Again, can we steal one of the padding fields to use for that state
>> variable? We have two 16-bit padding fields; one for cs and one for ss.
>
> We can steal them for passing the inform
On 08/23/2011 02:10 PM, Borislav Petkov wrote:
> On Tue, Aug 23, 2011 at 05:06:03PM -0400, H. Peter Anvin wrote:
>> On 08/23/2011 01:56 PM, Borislav Petkov wrote:
>>>
>>> But no, I don't think the difference has disappeared - to the contrary,
>>> AFAICT, the intention is for SYSCALL to be the faste
29 matches
Mail list logo
