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]
Date:   Wed, 1 Nov 2017 04:18:38 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        moritz.lipp@...k.tugraz.at,
        Daniel Gruss <daniel.gruss@...k.tugraz.at>,
        michael.schwarz@...k.tugraz.at,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kees Cook <keescook@...gle.com>,
        Hugh Dickins <hughd@...gle.com>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH 04/23] x86, tlb: make CR4-based TLB flushes more robust

On Wed, Nov 1, 2017 at 3:56 AM, Kirill A. Shutemov <kirill@...temov.name> wrote:
> On Wed, Nov 01, 2017 at 03:38:23AM -0700, Andy Lutomirski wrote:
>> On Wed, Nov 1, 2017 at 3:11 AM, Kirill A. Shutemov <kirill@...temov.name> wrote:
>> > On Wed, Nov 01, 2017 at 01:01:45AM -0700, Andy Lutomirski wrote:
>> >> On Tue, Oct 31, 2017 at 3:31 PM, Dave Hansen
>> >> <dave.hansen@...ux.intel.com> wrote:
>> >> >
>> >> > Our CR4-based TLB flush currently requries global pages to be
>> >> > supported *and* enabled.  But, we really only need for them to be
>> >> > supported.  Make the code more robust by alllowing X86_CR4_PGE to
>> >> > clear as well as set.
>> >> >
>> >> > This change was suggested by Kirill Shutemov.
>> >>
>> >> I may have missed something, but why would be ever have CR4.PGE off?
>> >
>> > This came out from me thinking on if we can disable global pages by not
>> > turning on CR4.PGE instead of making _PAGE_GLOBAL zero.
>> >
>> > Dave decided to not take this path, but this change would make
>> > __native_flush_tlb_global_irq_disabled() a bit less fragile in case
>> > if the situation would change in the future.
>>
>> How about just adding a VM_WARN_ON_ONCE, then?
>
> What's wrong with xor? The function will continue to work this way even if
> CR4.PGE is disabled.

That's true.  OTOH, since no one is actually proposing doing that,
there's an argument that people should get warned and therefore be
forced to think about it.

Powered by blists - more mailing lists