From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/PV: properly populate descriptor tables Date: Mon, 26 Oct 2015 14:58:43 +0000 Message-ID: <562E3FA3.5030707@citrix.com> References: <5602E29802000078000A4EAF@prv-mh.provo.novell.com> <562E3C0B.5040908@citrix.com> <562E3EDF.5040502@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZqjEV-0001y5-B8 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2015 14:58:47 +0000 In-Reply-To: <562E3EDF.5040502@citrix.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: David Vrabel , Jan Beulich , xen-devel Cc: Keir Fraser , Wei Liu List-Id: xen-devel@lists.xenproject.org On 26/10/15 14:55, Andrew Cooper wrote: > On 26/10/15 14:43, David Vrabel wrote: >> On 23/09/15 16:34, Jan Beulich wrote: >>> Us extending the GDT limit past the Xen descriptors so far meant that >>> guests (including user mode programs) accessing any descriptor table >>> slot above the original OS'es limit but below the first Xen descriptor >>> caused a #PF, converted to a #GP in our #PF handler. Which is quite >>> different from the native behavior, where some of such accesses (LAR >>> and LSL) don't fault. Mimic that behavior by mapping a blank page into >>> unused slots. >>> >>> While not strictly required, treat the LDT the same for consistency. >> This change causes a 32-bit userspace process running in a 32-bit PV >> guest to segfault. >> >> The process is a Go program and it is using the modify_ldt() system call >> (which is successful) but loading %gs with the new descriptor causes a >> fault. Even a minimal (empty main()) go program faults. > D'uh - its obvious now you point it out. > > By filling the shadow ldt slots as present, zero entries, we break their > demand-faulting. > > We can't be safe to incorrect faults from LAR/LSL, *and* perform demand > faulting of the LDT. Wait. Yes we can. I am talking nonsense. Hunk 2 should be reverted, and the demand fault handler should populate a zero entry rather than passing #GP back to the guest. ~Andrew