linux-kernel - Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87y4for6z4.fsf@x220.int.ebiederm.org>
Date:	Tue, 29 Sep 2015 21:11:59 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Vrabel <david.vrabel@...rix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Brian Gerst <brgerst@...il.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Gleb Natapov <gleb@...nel.org>,
	Kees Cook <keescook@...omium.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Joerg Roedel <joro@...tes.org>, X86 ML <x86@...nel.org>,
	kvm list <kvm@...r.kernel.org>
Subject: Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

"H. Peter Anvin" <hpa@...or.com> writes:

> On 09/29/2015 06:20 PM, Eric W. Biederman wrote:
>> Linus Torvalds <torvalds@...ux-foundation.org> writes:
>> 
>>> On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski <luto@...capital.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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/