From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752997AbbI3CTc (ORCPT ); Tue, 29 Sep 2015 22:19:32 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:49493 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751604AbbI3CTZ (ORCPT ); Tue, 29 Sep 2015 22:19:25 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "H. Peter Anvin" 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 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> Date: Tue, 29 Sep 2015 21:11:59 -0500 In-Reply-To: <560B3B7F.4000305@zytor.com> (H. Peter Anvin's message of "Tue, 29 Sep 2015 18:31:43 -0700") Message-ID: <87y4for6z4.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX18Kv7/GWoWAbgZvo32mY3Hedxeh07aqcH4= X-SA-Exim-Connect-IP: 67.3.201.231 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa05 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;"H. Peter Anvin" X-Spam-Relay-Country: X-Spam-Timing: total 252 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 3.2 (1.3%), b_tie_ro: 2.3 (0.9%), parse: 0.63 (0.3%), extract_message_metadata: 14 (5.6%), get_uri_detail_list: 1.37 (0.5%), tests_pri_-1000: 10 (3.8%), tests_pri_-950: 0.99 (0.4%), tests_pri_-900: 0.82 (0.3%), tests_pri_-400: 22 (8.9%), check_bayes: 21 (8.5%), b_tokenize: 7 (2.7%), b_tok_get_all: 8 (3.1%), b_comp_prob: 1.92 (0.8%), b_tok_touch_all: 3.0 (1.2%), b_finish: 0.58 (0.2%), tests_pri_0: 194 (77.1%), tests_pri_500: 3.6 (1.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "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