* Ingo Molnar <[email protected]> wrote:
> > Without something like that, we'll be in the awkward position of having
> > some
> > of the selectors (DS, ES, FS, and GS) in both the normal pt_regs slot and
> > in
> > the extended hardware frame during execution of normal vm86-unaware kernel
> > code. If, on the other hand, we copied the selectors across in
> > enter_from_user_mode and prepare_return_from_usermode, then pt_regs would
> > work
> > normally even for tasks that are running in v8086 mode.
> >
> > regs->flags & X86_EFLAGS_VM will be true regardless, so all of the asm that
> > decides to invoke those helpers should work fine.
>
> Btw., has anyone considered an entirely different approach: using KVM's
> instruction emulator to emulate vm86 16-bit code execution? Basically the
> vm86
> system call would be kept compatible, but fully emulated, the CPU never
> enters
> true 16-bit mode, just iterates pt_regs as if it had.
>
> This approach has four main advantages:
>
> - we could remove the fragile vm86 code from the entry code
>
> - it might even be faster for certain workloads than faulting in and out all
> the time and using ancient, fragile hardware mode of the CPU. (For example
> it
> could detect the VGA screen write patterns and accelerate them.)
>
> - it could be made to work on 64-bit as well, FWIIW
>
> - it would provide another angle of testing for the KVM emulator
So there's a fifth advantage as well that I think needs to be stressed:
- it's an _obviously_ much more secure design, as we only iterate user-space
pt_regs and never truly touch any security relevant CPU state. The whole
nested pt_regs and different hw frame entry complications would go away
entirely. All CPU semantics would not be just assumed implicitly, but would
be very much present in the CPU emulator and would be reviewable.
Thanks,
Ingo
--
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/
