Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753655AbbG2RO4 (ORCPT ); Wed, 29 Jul 2015 13:14:56 -0400 Received: from mail-oi0-f49.google.com ([209.85.218.49]:33693 "EHLO mail-oi0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751105AbbG2ROz (ORCPT ); Wed, 29 Jul 2015 13:14:55 -0400 MIME-Version: 1.0 In-Reply-To: References: <1438148483-11932-1-git-send-email-brgerst@gmail.com> <1438148483-11932-5-git-send-email-brgerst@gmail.com> Date: Wed, 29 Jul 2015 13:14:54 -0400 Message-ID: Subject: Re: [PATCH 4/8] x86/vm86: Use the normal pt_regs area for vm86 From: Brian Gerst To: Andy Lutomirski Cc: X86 ML , "linux-kernel@vger.kernel.org" , Ingo Molnar , "H. Peter Anvin" , Denys Vlasenko , Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3172 Lines: 71 On Wed, Jul 29, 2015 at 11:50 AM, Andy Lutomirski wrote: > On Tue, Jul 28, 2015 at 10:41 PM, Brian Gerst 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 > >> - 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. I think it was causing signal handling to fail, but I can't remember exactly. If I kept the code it would have needed to add a test for the VM flag. But I came to the same conclusion you did, that it was unneeded. > 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.) I'd be OK with that. >> --- 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. That looks good. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/