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, 10 Jan 2018 15:42:39 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Willy Tarreau <w@....eu>
Cc:     Andy Lutomirski <luto@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Brian Gerst <brgerst@...il.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Kees Cook <keescook@...omium.org>
Subject: Re: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and
 ARCH_SET_NOPTI to enable/disable PTI

On Tue, Jan 09, 2018 at 11:40:09PM +0100, Willy Tarreau wrote:
> Boris, please don't try to make me look like a fool when I'm trying to
> explain a common process.

I haven't even intended to do that, sorry, maybe you're misunderstanding
me.

All I'm trying to say is booting with pti=allow_optout should be part of
the proper *setup* of the box. In the sense, the thing is kinda expected
to go to 100% and if performance is still not enough, to allow customers
to disable PTI per process for the price of diminished security.

But...

> No, your distro did. Please keep in mind that you were the one asking me
> to have this option so that distros can enable it to please their users,
> or possibly in fact to remove it to please the competitors.

... I was asking for this so that I can completely keep the code out of the
built kernel but from reading this thread, it sounds to me like we'd
need the full spectrum of options:

1. prohibit disabling of PTI
2. per-process PTI disabling
3. disable PTI on the system

and then show people how to do that and do that at runtime. Apparently,
it is important to people to be able to control that.

And also explain what each option means so that they can evaluate
themselves what they'd prefer.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ