linux-kernel - Re: [PATCH 4/8] x86/vm86: Use the normal pt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrV5+=Z9NyaAVxrZ0oOZT_63D=07J7oKu8j3jV_BkY+Zfg@mail.gmail.com>
Date:	Wed, 29 Jul 2015 08:50:14 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Brian Gerst <brgerst@...il.com>
Cc:	X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 4/8] x86/vm86: Use the normal pt_regs area for vm86

On Tue, Jul 28, 2015 at 10:41 PM, Brian Gerst <brgerst@...il.com> wrote:
> Change to use the normal pt_regs area to enter and exit vm86 mode.  This is
> done by increasing the padding at the top of the stack to make room for the
> extra vm86 segment slots in the IRET frame.  It then saves the 32-bit regs
> in the off-stack vm86 data, and copies in the vm86 regs.  Exiting back to
> 32-bit mode does the reverse.  This allows removing the hacks to jump directly
> into the exit asm code due to having to change the stack pointer.  Returning
> normally from the vm86 syscall and the exception handlers allows things like
> ptrace and auditing to work properly.

With caveats below:

Acked-by: Andy Lutomirski <luto@...nel.org>

> -       movb    PT_CS(%esp), %bl
> -       andb    $SEGMENT_RPL_MASK, %bl
> -       cmpb    $USER_RPL, %bl
> -       jb      resume_kernel

I agree with this hunk, and I have the same hunk in my tree.  However,
it has nothing to do with vm86 and, on the off chance that this hunk
is wrong, I think it should be bisect-friendly.

If you want to preserve my bit of archeology, you could include:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/entry&id=bb2a2fc1dc6423e87e7f1c3c9c4567a47f727b6e

in this series and stick your patch on top.  (Or, Ingo, if you want to
apply just that one patch from my pile and merge this on top, you'd
get exactly the same result.)

> --- a/arch/x86/include/asm/thread_info.h
> +++ b/arch/x86/include/asm/thread_info.h
> @@ -27,14 +27,17 @@
>   * Without this offset, that can result in a page fault.  (We are
>   * careful that, in this case, the value we read doesn't matter.)
>   *
> - * In vm86 mode, the hardware frame is much longer still, but we neither
> - * access the extra members from NMI context, nor do we write such a
> - * frame at sp0 at all.
> + * In vm86 mode, the hardware frame is much longer still, so add 16
> + * bytes to make room for the real-mode segments.

I've now read this comment a few times, and I think it could be
better.  How about:

In vm86 mode, the hardware frame is extended by 4 bytes for each of
ds, es, fs and gs.  To allow room for those extra slots while still
keeping pt_regs in its normal location on entries from vm86 mode, we
need at least 16 bytes of padding.  In the vm86 case, we don't need to
worry about the SYSENTER + NMI issue: we disallow SYSENTER from vm86
mode, so we don't need to worry about an NMI trying to read above the
top of the vm86 hardware frame.


--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/