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: <7B00EFC7-7BF2-4A17-981E-01EC69AEADA8@gmail.com>
Date:   Thu, 15 Feb 2018 12:45:11 -0800
From:   Nadav Amit <nadav.amit@...il.com>
To:     Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     Andy Lutomirski <luto@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Willy Tarreau <w@....eu>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC v2 5/6] x86: Use global pages when PTI is disabled

Dave Hansen <dave.hansen@...ux.intel.com> wrote:

> On 02/15/2018 11:53 AM, Andy Lutomirski wrote:
>>> --- a/arch/x86/include/asm/tlbflush.h
>>> +++ b/arch/x86/include/asm/tlbflush.h
>>> @@ -319,6 +319,12 @@ static inline void set_cpu_pti_disable(unsigned short disable)
>>>        WARN_ON_ONCE(preemptible());
>>> 
>>>        pti_update_user_cs64(cpu_pti_disable(), disable);
>>> +       if (__supported_pte_mask & _PAGE_GLOBAL) {
>>> +               if (disable)
>>> +                       cr4_set_bits(X86_CR4_PGE);
>>> +               else
>>> +                       cr4_clear_bits(X86_CR4_PGE);
>>> +       }
>> This will be *extremely* slow, and I don't see the point at all.  What
>> are you accomplishing here?
> 
> It won't be slow if you always run compat processes, I guess.
> 
> But mixing these in here will eat a big chunk of the benefit of having
> global pages (or PCIDs for that matter) in the first place.

These are all good points. The idea was to allow workloads like Apache, that
spawn multiple processes that frequently perform context-switches to incur
TLB misses on kernel pages. 

The double-flushing was not intentional - I missed it. Anyhow, based on your
comments, and because I don’t see an easy way to make the global
cpu_entry_area (your recent patches) to work with this patch, I think I will
drop this patch.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ