From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
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>
Subject: Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled
Date: Tue, 29 Sep 2015 21:11:59 -0500 [thread overview]
Message-ID: <87y4for6z4.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <560B3B7F.4000305@zytor.com> (H. Peter Anvin's message of "Tue, 29 Sep 2015 18:31:43 -0700")
"H. Peter Anvin" <hpa@zytor.com> writes:
> 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.
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
next prev parent reply other threads:[~2015-09-30 2:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-26 18:00 Denys Vlasenko
2015-09-26 19:50 ` H. Peter Anvin
2015-09-26 20:38 ` Denys Vlasenko
2015-09-28 7:58 ` Ingo Molnar
2015-09-28 12:45 ` Denys Vlasenko
2015-09-29 9:01 ` Ingo Molnar
2015-09-29 17:35 ` Andy Lutomirski
2015-09-29 17:50 ` Linus Torvalds
2015-09-29 18:02 ` Andy Lutomirski
2015-09-29 20:30 ` H. Peter Anvin
2015-09-30 1:20 ` Eric W. Biederman
2015-09-30 1:31 ` H. Peter Anvin
2015-09-30 2:11 ` Eric W. Biederman [this message]
2015-09-30 2:26 ` H. Peter Anvin
2015-09-29 18:18 ` H. Peter Anvin
2015-09-29 18:22 ` Andy Lutomirski
2015-09-29 18:27 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y4for6z4.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=david.vrabel@citrix.com \
--cc=dvlasenk@redhat.com \
--cc=gleb@kernel.org \
--cc=hpa@zytor.com \
--cc=joro@8bytes.org \
--cc=keescook@chromium.org \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome