Linus Torvalds wrote:
>
> > > sysenter is really a strange thing. Have you verified that your current
> > > code works with vm86 mode programs like dosemu or with wine, for example?
> >
> > No, it does not. I haven't even written the code handling that case, for
> > the very simple reason i haven't yet figured out _what_ to do when a
> > vm86 task executes SYSENTER.
>
> Oh, you can't do that. SYSENTER just loses all the information, so you
> don't really have much choice: you can't get it right as far as I can
> tell.
>
> I was more thinking about the case where SYSENTER was used for the vm86()
> system call, and you'd have to be careful _not_ to use SYSEXIT because you
> can't use SYSEXIT to return to vm86 mode - you have to use the same old
> "iret" for that case. That shouldn't be too hard: just check the flags on
> the return path and if the flags imply a return to VM86 you just use the
> old path.
>
> The same is true of Wine: you just need to check the DS/SS segment values
> on return (and if they are anything but USER_DS you need to use "iret"
> again).
>
> You may have all this code already, I was just wondering. It doesn't look
> like rocket science, but it _does_ look like there's just a lot of details
> that need to be just right...
Yep. and all the cases i've so far identified are handled (although
i'm assuming ds is std on entry for non-vm86 tasks (note the ss case
you don't even get to check)).
> > This is one of only two unresolved issues
> > left. As it is impossible to recover from this (w/o a cooperative
> > userspace, that is. sysenter drops eip/esp/cs/ss) what should happen?
>
> The thing is, you don't even have enough information to know whether the
> user was co-operative or not. A "bad" use of SYSENTER will look exactly
> like a good one, so you really cannot tell. As such, I wouldn't worry
> about the issue, because there is nothing you can possibly do about it
> anyway.
exactly.
[there is something you could do -- not make SYSENTER available from vm86,
ie clear the msr while switching to a vm86 task, and reset it otherwise.
I don't like the cost though, as it likely means two additional conditional
branches and an extra msr write in switchto()]
[if fact what i'm doing right now is trying to put as many cases as possible
back on the sysexit path -- it _will_ make it a few cycles slower, but
there are other reasons i need the extra code for anyway]
> > [i don't use any vm86 tasks so i'd find it acceptable to simply _exit(),
> > but there might be a better way... Ideas?]
>
> How would you know to _exit()? You'll just have to think that it's a real
> system call, and then on the return path the process will probably receive
> a SIGSEGV because the stack is crap etc.. But that's ok - just another bad
> pointer dereference..
ok, that's simple enough. But do we really want linux syscalls executed
from inside wine, dosemu etc?
[i'll ignore vmware for now, but there might be some interesting
possibilities there... :^) ]
> > Oh, there's something else i have on the todo list, but haven't yet
> > looked into -- SYSENTER doesn't clear TF.
>
> Does it matter?
As i said, finding out is on my todo list. [iirc it's not fatal, but i
did not investigate this fully, it could make a difference, and even
if it does, should be easy to fix]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/