Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937058Ab3DJJmj (ORCPT ); Wed, 10 Apr 2013 05:42:39 -0400 Received: from nat28.tlf.novell.com ([130.57.49.28]:56730 "EHLO nat28.tlf.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933036Ab3DJJmi convert rfc822-to-8bit (ORCPT ); Wed, 10 Apr 2013 05:42:38 -0400 Message-Id: <5165502902000078000CC022@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Wed, 10 Apr 2013 10:42:33 +0100 From: "Jan Beulich" To: "H. Peter Anvin" Cc: "Borislav Petkov" , "Kees Cook" , "Will Drewry" , "Frederic Weisbecker" , "Steven Rostedt" , "Eric Northup" , "Julien Tinnes" , "Jeremy Fitzhardinge" , "Alex Shi" , "Alexander Duyck" , "x86@kernel.org" , "Paul E. McKenney" , "virtualization@lists.linux-foundation.org" , "kernel-hardening@lists.openwall.com" , "xen-devel@lists.xensource.com" , "Konrad Rzeszutek Wilk" , "Ingo Molnar" , "Marcelo Tosatti" , "LKML" , "Dan Rosenberg" Subject: Re: [Xen-devel] Readonly GDT References: <20130408224328.GA17641@www.outflux.net> <51634935.9010905@zytor.com> <51645D6F.7070705@zytor.com> <51646054.3090509@zytor.com> <5164B5BD.5050702@zytor.com> In-Reply-To: <5164B5BD.5050702@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1397 Lines: 31 >>> On 10.04.13 at 02:43, "H. Peter Anvin" wrote: > OK, thinking about the GDT here. > > The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As > such, we probably don't want to allocate a full page to it for only > that. This means that in order to create a readonly mapping we have to > pack GDTs from different CPUs together in the same pages, *or* we > tolerate that other things on the same page gets reflected in the same > mapping. I think a read-only GDT is incompatible with exceptions delivered through task gates (i.e. double fault on 32-bit), so I would assume this needs to remain a 64-bit only thing. > However, the packing solution has the advantage of reducing address > space consumption which matters on 32 bits: even on i386 we can easily > burn a megabyte of address space for 4096 processors, but burning 16 > megabytes starts to hurt. Packing would have the additional benefit of Xen not needing to become a special case in yet another area (because pages containing live descriptor table entries need to be read-only for PV guests, and need to consist of only descriptor table entries). Jan -- 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/