linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Andy Lutomirski <luto@kernel.org>
Cc: "X86 ML" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Frédéric Weisbecker" <fweisbec@gmail.com>,
	"Rik van Riel" <riel@redhat.com>,
	"Oleg Nesterov" <oleg@redhat.com>,
	"Denys Vlasenko" <vda.linux@googlemail.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Kees Cook" <keescook@chromium.org>,
	"Brian Gerst" <brgerst@gmail.com>,
	"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: [RFC/PATCH 5/7] x86/vm86: Teach handle_vm86_trap to return to 32bit mode directly
Date: Thu, 9 Jul 2015 18:33:59 -0700	[thread overview]
Message-ID: <CALCETrXb_A4s=ORYDEv4j1--tQsqKeHkyaKbL6cUhDa1FxpG6A@mail.gmail.com> (raw)
In-Reply-To: <CALCETrWrJ1CJ6cqpHzOGHSx3BRZ2nYG8dDZWabbaj1n-=YBvng@mail.gmail.com>

On Thu, Jul 9, 2015 at 3:41 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Wed, Jul 8, 2015 at 12:24 PM, Andy Lutomirski <luto@kernel.org> wrote:
>> The TIF_NOTIFY_RESUME hack it was using was buggy and unsupportable.
>> vm86 mode was completely broken under ptrace, for example, because
>> we'd never make it to v8086 mode.
>>
>> This code is still a huge, scary mess, but at least it's no longer
>> tangled with the exit-to-userspace loop.
>
> This patch is incorrect.  Brian, what's the ETA for your vm86 cleanup?
>  If it's very soon, then I'll see if I can rely on it.  If not, I'll
> have to come up with a way to fix this patch.
>
> Grr.  The kernel state when handle_vm86_trap is called is absurd right
> now.  Somehow we're supposed to survive do_trap, send a signal
> corresponding to the outside-vm86 state, and exit vm86 cleanly (with
> ax = 0), all before returning to user mode.  I doubt these semantics
> are even intentional.
>
> This code sucks.

OK, I have a version that seems to work.  It comes with a much better
selftest, too.  I'll send it shortly.

Brian, would it make sense to base your work on top of it?

Now that I've looked at this stuff, if I were designing Linux support
for v8086 mode, I'd do it very differently.  There wouldn't be a vm86
syscall at all.  Instead you'd call sigaltstack, then raise a signal,
set X86_EFLAGS_VM, and return.

The kernel would handle X86_EFLAGS_VM being set by setting TIF_V8086
and adjusting sp0.  On entry, TIF_V8086 would move the segment
registers from the hardware frame into pt_regs and, on exit, TIF_V8086
would move them back.  Clearing X86_EFLAGS_VM (via ptrace, signal
delivery, or sigreturn) would sanitize the segment registers.

SYSENTER would be safe, so the SYSENTER_CS hack wouldn't be needed.
Of course, we'd lose the CPU state, so the user would have to be
careful.

And that's it.  There wouldn't be any emulation -- user code could
emulate syscalls all by itself in a signal handler.  Exiting v8086
mode would be straightforward -- just do anything that would raise a
signal.

Of course, this isn't at all ABI-compatible with the current turd, and
v8086 mode isn't really that useful, so this is just idle retroactive
speculation.  But the TIF_V8086 trick would still be useful to let us
get rid of all the awful hacks in the trap and exit code.

--Andy

  reply	other threads:[~2015-07-10  1:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-08 19:23 [RFC/PATCH 0/7] x86_32: Migrate to new entry/exit paths Andy Lutomirski
2015-07-08 19:23 ` [RFC/PATCH 1/7] x86/entry/32: Remove 32-bit syscall audit optimizations Andy Lutomirski
2015-07-08 19:23 ` [RFC/PATCH 2/7] x86/entry/32: Fix an incorrect comment for work_notifysig_v86 Andy Lutomirski
2015-07-08 19:24 ` [RFC/PATCH 3/7] [TEMPORARY] x86/entry/32: Sanity check for work_notifysig Andy Lutomirski
2015-07-08 19:25   ` Andy Lutomirski
2015-07-08 19:24 ` [RFC/PATCH 4/7] x86/entry/32: Finish removing bogus kernel-mode check Andy Lutomirski
2015-07-08 19:25   ` Andy Lutomirski
2015-07-08 19:24 ` [RFC/PATCH 5/7] x86/vm86: Teach handle_vm86_trap to return to 32bit mode directly Andy Lutomirski
2015-07-09 22:41   ` Andy Lutomirski
2015-07-10  1:33     ` Andy Lutomirski [this message]
2015-07-10 15:27       ` Brian Gerst
2015-07-08 19:24 ` [RFC/PATCH 6/7] x86/entry/32: Use prepare_exit_to_usermode and syscall_return_slowpath Andy Lutomirski
2015-07-08 19:24 ` [RFC/PATCH 7/7] x86/entry: Remove do_notify_resume, syscall_trace_leave, and their TIF masks Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALCETrXb_A4s=ORYDEv4j1--tQsqKeHkyaKbL6cUhDa1FxpG6A@mail.gmail.com' \
    --to=luto@amacapital.net \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=oleg@redhat.com \
    --cc=riel@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vda.linux@googlemail.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).