From patchwork Fri Apr 22 14:17:35 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Beulich X-Patchwork-Id: 8912281 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 387779F372 for ; Fri, 22 Apr 2016 14:19:55 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4F68B201F5 for ; Fri, 22 Apr 2016 14:19:54 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 58F8120256 for ; Fri, 22 Apr 2016 14:19:53 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atbtu-0007Kz-6A; Fri, 22 Apr 2016 14:17:42 +0000 Received: from mail6.bemta6.messagelabs.com ([85.158.143.247]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atbts-0007Ks-Uu for xen-devel@lists.xenproject.org; Fri, 22 Apr 2016 14:17:41 +0000 Received: from [85.158.143.35] by server-1.bemta-6.messagelabs.com id 55/84-18833-4823A175; Fri, 22 Apr 2016 14:17:40 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRWlGSWpSXmKPExsXS6fjDS7fZSCr cYPtueYvvWyYzOTB6HP5whSWAMYo1My8pvyKBNWPRu1b2gn3qFbce6Dcwtsl2MXJyCAnkSez8 uoGpi5GDg1fATuL98XiQsISAocS++avYQMIsAqoSt9+ngoTZBNQl2p5tZwUJiwgYSJw7mgQSZ hYIlLh1fwYjiC0sYClxf/YCVoiBghJ/dwhDlNhJnFuzl3ECI9cshMwsJBkIW0vi4a9bLBC2ts Syha+ZQcqZBaQllv/jgAibShz6tY0RVQmI7SCx5Vo/+wJGjlWM6sWpRWWpRbrGeklFmekZJbm JmTm6hgZmermpxcWJ6ak5iUnFesn5uZsYgUHHAAQ7GDv+OR1ilORgUhLl/awpFS7El5SfUpmR WJwRX1Sak1p8iFGGg0NJglfQECgnWJSanlqRlpkDDH+YtAQHj5II71WQNG9xQWJucWY6ROoUo 6KUOK8HSEIAJJFRmgfXBou5S4yyUsK8jECHCPEUpBblZpagyr9iFOdgVBLmFQWZwpOZVwI3/R XQYiagxf8uSIIsLklESEk1MDb0PvSbGrl+Wo/8j8Uu65x2vfEymLrPbHk6D+ukxNVXs3N/O39 6/KZi7cWvyoW9pvluXMbrn+0NYFueumLu/nW+hWYVf+eGTV9jWeE955ls9f8dn6W9J/T4cQYv +1E3fZZGr4Oh/AXx+Hb56MmzZzRfNc7WecQq5xJX+e6Lb+LUzR0suU8Xn1JiKc5INNRiLipOB AB8q+P+tAIAAA== X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1461334657!10772158!1 X-Originating-IP: [137.65.248.74] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 8.34; banners=-,-,- X-VirusChecked: Checked Received: (qmail 45549 invoked from network); 22 Apr 2016 14:17:39 -0000 Received: from prv-mh.provo.novell.com (HELO prv-mh.provo.novell.com) (137.65.248.74) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 22 Apr 2016 14:17:39 -0000 Received: from INET-PRV-MTA by prv-mh.provo.novell.com with Novell_GroupWise; Fri, 22 Apr 2016 08:17:37 -0600 Message-Id: <571A4E9F02000078000E4D15@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.2.0 Date: Fri, 22 Apr 2016 08:17:35 -0600 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Cc: Andrew Cooper , Wei Liu Subject: [Xen-devel] [PATCH] x86emul: don't allow INVLPG in real mode X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP As both INVLPG and INVLPGA have basically the same exception rules (leaving aside that INVLPGA requires SVME enabled, which so far isn't being taken care of, and that INVLPG requires ModRM.mod != 3), fold the handling of the two as much as possible alongside achieving the goal of the patch (at once doing the #UD checks pror to the #GP one, which ought to be more in line with how hardware does things). But please note that AMD and Intel disagree on what exceptions INVLPG may raise, and the more reasonable Intel variant is being followed. Signed-off-by: Jan Beulich x86emul: don't allow INVLPG in real mode As both INVLPG and INVLPGA have basically the same exception rules (leaving aside that INVLPGA requires SVME enabled, which so far isn't being taken care of, and that INVLPG requires ModRM.mod != 3), fold the handling of the two as much as possible alongside achieving the goal of the patch (at once doing the #UD checks pror to the #GP one, which ought to be more in line with how hardware does things). But please note that AMD and Intel disagree on what exceptions INVLPG may raise, and the more reasonable Intel variant is being followed. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -3880,13 +3880,14 @@ x86_emulate( switch( modrm ) { case 0xdf: /* invlpga */ - generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1); - generate_exception_if(!mode_ring0(), EXC_GP, 0); - fail_if(ops->invlpg == NULL); - if ( (rc = ops->invlpg(x86_seg_none, truncate_ea(_regs.eax), - ctxt)) ) - goto done; - goto no_writeback; + ea.mem.off = truncate_ea(_regs.eax); + /* + * This is questionable: AMD's PM calls the address used here both + * virtual and linear. They've informally indicated "linear" is + * meant there. + */ + ea.mem.seg = x86_seg_none; + goto invlpg; case 0xf9: /* rdtscp */ { uint64_t tsc_aux; fail_if(ops->read_msr == NULL); @@ -4006,8 +4007,10 @@ x86_emulate( goto done; break; case 7: /* invlpg */ - generate_exception_if(!mode_ring0(), EXC_GP, 0); generate_exception_if(ea.type != OP_MEM, EXC_UD, -1); + invlpg: + generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1); + generate_exception_if(!mode_ring0(), EXC_GP, 0); fail_if(ops->invlpg == NULL); if ( (rc = ops->invlpg(ea.mem.seg, ea.mem.off, ctxt)) ) goto done; --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -3880,13 +3880,14 @@ x86_emulate( switch( modrm ) { case 0xdf: /* invlpga */ - generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1); - generate_exception_if(!mode_ring0(), EXC_GP, 0); - fail_if(ops->invlpg == NULL); - if ( (rc = ops->invlpg(x86_seg_none, truncate_ea(_regs.eax), - ctxt)) ) - goto done; - goto no_writeback; + ea.mem.off = truncate_ea(_regs.eax); + /* + * This is questionable: AMD's PM calls the address used here both + * virtual and linear. They've informally indicated "linear" is + * meant there. + */ + ea.mem.seg = x86_seg_none; + goto invlpg; case 0xf9: /* rdtscp */ { uint64_t tsc_aux; fail_if(ops->read_msr == NULL); @@ -4006,8 +4007,10 @@ x86_emulate( goto done; break; case 7: /* invlpg */ - generate_exception_if(!mode_ring0(), EXC_GP, 0); generate_exception_if(ea.type != OP_MEM, EXC_UD, -1); + invlpg: + generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1); + generate_exception_if(!mode_ring0(), EXC_GP, 0); fail_if(ops->invlpg == NULL); if ( (rc = ops->invlpg(ea.mem.seg, ea.mem.off, ctxt)) ) goto done;