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
| ||
|
Date: Tue, 29 Sep 2015 19:26:51 -0700 From: "H. Peter Anvin" <hpa@...or.com> To: ebiederm@...ssion.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@...r.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 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@...ssion.com wrote: >"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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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/
Powered by blists - more mailing lists