From mboxrd@z Thu Jan  1 00:00:00 1970
From: "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] x86: Use entire page for the per-cpu GDT only if
 paravirt-enabled
Date: Tue, 29 Sep 2015 18:31:43 -0700
Message-ID: <560B3B7F.4000305@zytor.com>
References: <1443290440-14930-1-git-send-email-dvlasenk@redhat.com>
 <706E9982-24E3-442B-808A-172909449DD4@zytor.com>
 <56070241.2030407@redhat.com> <20150928075851.GA23998@gmail.com>
 <56093657.8070409@redhat.com> <20150929090112.GA1400@gmail.com>
 <CALCETrV3hMxSbX+eUZYLffVzcCTxAtr=tN2W69eF8=ismM=PBw@mail.gmail.com>
 <CA+55aFxQfG09Hn33iTDt2L5iO5AiqTrXFODy-A+wf_xdpPoVKw@mail.gmail.com>
 <878u7ou2i4.fsf@x220.int.ebiederm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: Andy Lutomirski <luto@amacapital.net>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Brian Gerst <brgerst@gmail.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Gleb Natapov <gleb@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Joerg Roedel <joro@8bytes.org>, X86 ML <x86@kernel.org>,
	kvm list <kvm@vger.kernel.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <878u7ou2i4.fsf@x220.int.ebiederm.org>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org

On 09/29/2015 06:20 PM, Eric W. Biederman wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
>> On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>
>>> Does anyone know what happens if you stick a non-accessed segment in
>>> the GDT, map the GDT RO, and access it?
>>
>> You should get a #PF, as you guess, but go ahead and test it if you
>> want to make sure.
> 
> I tested this by accident once when workinng on what has become known
> as coreboot.  Early in boot with your GDT in a EEPROM switching from
> real mode to 32bit protected mode causes a write and locks up the
> machine when the hardware declines the write to the GDT to set the
> accessed bit.  As I recall the write kept being retried and retried and
> retried...
> 
> Setting the access bit in the GDT cleared up the problem and I did not
> look back.
> 
> Way up in 64bit mode something might be different, but I don't know why
> cpu designeres would waste the silicon.
> 

This is totally different from a TLB violation.  In your case, the write
goes through as far as the CPU is concerned, but when the data is
fetched back, it hasn't changed.  A write to a TLB-protected location
will #PF.

	-hpa