There's a ton of details like this that are worth exploring,
but that right now are not worth it because we don't have the
infrastructure.
gettimeofday() is a great example. We don't just want to assume "rdtsc" in
user space, and even if we did we wouldn't want to re-calibrate all the
time. But yes, it would work very nicely indeed with the global area
approach (and when the CPU doesn't have rdtsc, the global area would just
do an old-fashioned system call).
A "node ID" may be another global static thing that would be useful in the
future, but that's certainly not an issue today.
> > 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...
> 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.
Silly SYSENTER semantics.
> [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..
> 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?
Linus
-
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/