From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Bisected Xen-unstable: "Segment register inaccessible for d1v0" when starting HVM guest on intel Date: Wed, 2 Jul 2014 11:02:53 +0100 Message-ID: <53B3D8CD.1050506@citrix.com> References: <1057886355.20140628222158@eikelenboom.it> <53B1A244020000780001EA4D@mail.emea.novell.com> <1081819750.20140630183750@eikelenboom.it> <53B19EEB.4060603@citrix.com> <53B27902020000780001ED8B@mail.emea.novell.com> <53B29E03020000780001EF03@mail.emea.novell.com> <53B3CA8A020000780001F4B4@mail.emea.novell.com> <53B3D5D2020000780001F4F8@mail.emea.novell.com> <53B3ECEE020000780001F61F@mail.emea.novell.com> <53B3D491.1080907@citrix.com> <53B3F324020000780001F66B@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1X2HNS-0004qj-Pg for xen-devel@lists.xenproject.org; Wed, 02 Jul 2014 10:02:58 +0000 In-Reply-To: <53B3F324020000780001F66B@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Sander Eikelenboom , Feng Wu , "xen-devel@lists.xenproject.org" List-Id: xen-devel@lists.xenproject.org On 02/07/14 10:55, Jan Beulich wrote: >>>> On 02.07.14 at 11:44, wrote: >> On 02/07/14 10:28, Jan Beulich wrote: >>> This being a PV extension to the base architecture, the hardware >>> specification is meaningless. What we need to do here is _extend_ what >>> the hardware has specified for those extra accesses. We have three >>> options basically: >>> 1) never do any checking on such accesses >>> 2) honor CPL and EFLAGS.AC >>> 3) always do the checking >>> The first one obviously is bad from a security POV. Since the third one is >>> more strict than the second and since I assume adding some override is >>> going to be the simpler change than altering the point in time when the >>> VMCS gets loaded during context switch (the suggestion of which no one >>> at all commented on so far), I'd prefer that one, but wouldn't mind >>> option 2 to be implemented instead. >> The problem is not the hypervisor check. We are already deep within an >> hvm_copy_to_user() which is between a stac()/clac() pair. >> >> The issue is that guest_walk_tables() is checking a Xen access using >> guest page tables as if it were a supervisor access given the current >> context of the vcpu. > And I only ever referred to the checking done there; the hypervisor > access is of no concern here. > >> What can/should Xen do if its emulated access fails with a guest SMAP >> violations? It certainly can't/shouldn't inject a pagefault, nor should >> it actually fail the write. copy_to_user() is not subject to the guest >> operating mode and whether we are writing into guest user or supervisor >> pages. > Just like copy_to_user() would produce -EFAULT for a hypercall > when used on a non-present page or a non-canonical address, it > should (and afaict will with how things are right now) similarly > produce -EFAULT for an attempted access to a guest-accessible > page when the current mode of the guest is supervisor. > > To me it is a logical extension to also fail accesses outside of > hypercalls or emulation. > > Jan Consider an HVM guest with SMAP in effect, making a hypercall. If a guest handle points to guest userspace, Xen would be unable to ever complete the hypercall without an -EFAULT. I don't think this is reasonable to fail. ~Andrew