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] [day] [month] [year] [list]
Date:   Sat, 20 Jan 2018 17:31:30 +0100
From:   Willy Tarreau <w@....eu>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Nadav Amit <nadav.amit@...il.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI

On Sat, Jan 20, 2018 at 03:26:27PM +0100, Ingo Molnar wrote:
> 
> * Nadav Amit <nadav.amit@...il.com> wrote:
> 
> > > So we are trading a 5-15% slowdown (PTI) for another 5-15% slowdown, plus we 
> > > are losing the soft-SMEP feature on older CPUs that PTI enables, which is a 
> > > pretty powerful mitigation technique.
> > 
> > This soft-SMEP can be kept by keeping PTI if SMEP is unsupported. Although we 
> > trade slowdowns, they are different ones, which allows the user to make his best 
> > decision.
> 
> Indeed, not allowing PTI to be disabled if SMEP is unavailable might be a 
> solution.

Well, I do not agree with this, for the simple reason that the SMEP-like
protection provided by PTI was in fact a byproduct of the Meltdown
mitigation, eventhough quite a valuable one. For me, disabling PTI means
"I want to recover the performance I had on this workload before the PTI
fixes because I value performance over security". By doing it per process
we'll allow users to have both performance for a few processes and
protection (including SMEP-like) for the rest of the system. Their only
other choice will be to completely disable PTI, thus removing all
protection and losing the SMEP emulation.

Best regards,
Willy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ