On Fri, Jul 10, 2015 at 9:35 AM, Linus Torvalds <[email protected]> wrote: > On Fri, Jul 10, 2015 at 7:37 AM, Andy Lutomirski <[email protected]> wrote: >> >> Having just written a pile of tests for it, I don't think so, as long as none >> of the syscall slow path stuff is in use :( > > It seems that you are thinking that people actually use vm86 mode as a > real Linux mode, and do system calls from it etc.
Nope. > > The common situation is that you enter vm86 mode with vm86(), and that > you exit it due to one of the (many) unhandled situations or a signal > or whatever. Yeah,we handle a few sad instructions directly, but most > vm86 exits just return to user mode. > > The system call paths just aren't an issue in reality, because they > just aren't used. > That's not what I mean. I'm referring to the vm86 syscall itself. If you have a ti flag that causes the slow exit path to be used, then you call vm86. vm86 sets up the ludicrous double stack frame that it uses and jumps back to the exit asm. The exit asm then branches off to the slow path, hits the notifysig_v86 kludge, calls save_v86_state, tears down its double stack frame, and keeps meandering back through the exit asm. We finally IRET right back to protected mode, and the code that userspace was trying to execute in v8086 mode never actually runs. That code looked fishy when I first read it, and it is, indeed, entirely incorrect. So the vm86 syscall itself is broken if the slow path is in use. Fortunately, you can't do an a syscall inside vm86. If you could, I think it would be a disaster, because the double stack means that the syscall would run in a completely bogus context. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
