linux-kernel - Re: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and ARCH_SET

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: <20180110144239.cm5t7j6s7akkpked@pd.tnic>
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.