From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753122AbbI3C1j (ORCPT ); Tue, 29 Sep 2015 22:27:39 -0400 Received: from terminus.zytor.com ([198.137.202.10]:50683 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752296AbbI3C1g (ORCPT ); Tue, 29 Sep 2015 22:27:36 -0400 User-Agent: K-9 Mail for Android In-Reply-To: <87y4for6z4.fsf@x220.int.ebiederm.org> 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> <878u7ou2i4.fsf@x220.int.ebiederm.org> <560B3B7F.4000305@zytor.com> <87y4for6z4.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled From: "H. Peter Anvin" Date: Tue, 29 Sep 2015 19:26:51 -0700 To: ebiederm@xmission.com CC: Linus Torvalds , Andy Lutomirski , Ingo Molnar , Thomas Gleixner , Paolo Bonzini , Denys Vlasenko , Borislav Petkov , Andrew Morton , David Vrabel , Konrad Rzeszutek Wilk , Brian Gerst , Boris Ostrovsky , Gleb Natapov , Kees Cook , "linux-kernel@vger.kernel.org" , Peter Zijlstra , Joerg Roedel , X86 ML , kvm list Message-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org No, it is a natural result of an implemention which treats setting the A bit as an abnormal flow (e.g. in microcode as opposed to hardware). On September 29, 2015 7:11:59 PM PDT, ebiederm@xmission.com wrote: >"H. Peter Anvin" writes: > >> On 09/29/2015 06:20 PM, Eric W. Biederman wrote: >>> Linus Torvalds writes: >>> >>>> On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski > 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. > >The key point is that a write is generated when the cpu needs to set >the >access bit. I agree the failure points are different. A TLB fault vs >a >case where the hardware did not accept the write. > >The idea of a cpu reading back data (and not trusting it's cache >coherency controls) to verify the access bit gets set seems mind >boggling. That is slow, stupid, racy and incorrect. Incorrect as the >cpu should not only set the access bit once per segment register load. > >In my case I am pretty certain it was something very weird with the >hardware not acceppting the write and either not acknowledging the bus >transaction or cancelling it. In which case the cpu knew the write had >not made it to the ``memory'' and was trying to cope. > >Eric -- Sent from my Android device with K-9 Mail. Please excuse my brevity.