Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759230AbcDHWci (ORCPT ); Fri, 8 Apr 2016 18:32:38 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:53265 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759203AbcDHWcg (ORCPT ); Fri, 8 Apr 2016 18:32:36 -0400 X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208";a="352613503" Subject: Re: [Xen-devel] Does __KERNEL_DS serve a purpose? To: Andy Lutomirski , Paolo Bonzini References: <5707654F.1060407@citrix.com> <5707E681.7040202@redhat.com> CC: kvm list , X86 ML , "linux-kernel@vger.kernel.org" , xen-devel , Borislav Petkov , Andy Lutomirski From: Andrew Cooper Message-ID: <5708316D.4040802@citrix.com> Date: Fri, 8 Apr 2016 23:32:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1498 Lines: 38 On 08/04/16 23:06, Andy Lutomirski wrote: > On Fri, Apr 8, 2016 at 10:12 AM, Paolo Bonzini wrote: >> >> On 08/04/2016 18:00, Andy Lutomirski wrote: >>> But %ss can be loaded with 0 on 64-bit kernels. (I assume that >>> loading 0 into %ss sets SS.DPL to 0 if done at CPL0, but I'm vague on >>> this, since it only really matters to hypervisor code AFAIK.) >> It's even simpler, unless CPL=0 SS cannot be loaded with 0 while in a >> 64-bit code segment (SS can never be loaded with 0 if you're not in a >> 64-bit code segment). >> >> Thus indeed SS=0 implies SS.DPL=0 on 64-bit kernels. > I think we are stuck with __KERNEL_DS: SYSCALL uses it. SYSCALL expects the OS to keep the programmed selector in sync with its descriptor entry. It specifically loads fixed attributes, and doesn't re-read the GDT. > Unless we start fiddling with conforming code segments (ugh) I don't see how this would help. > , I don't think > there's a valid GDT layout that doesn't have two flat data segments. My gut feeling is that nothing good can possibly come of having the GDT entry out of sync with the fixed attributes SYSCALL loads. It would break code which manually reloaded %ss, such as constructed an IRET frame using PUSH %ss. > Oh well, chalk it up to historical accident. Feel very glad that SYSCALL and SYSENTER (appear to) behave identically in their expectations of GDT layout and fixed attributes... I for one wouldn't bet on it, knowing the x86 architecture. ~Andrew