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 20:39:21 +0100
From:   Willy Tarreau <w@....eu>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Brian Gerst <brgerst@...il.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when
 pti_disable is set

Hi Andy,

On Wed, Jan 10, 2018 at 11:21:15AM -0800, Andy Lutomirski wrote:
> > If we agree on this, I'd like to propose to have two flags :
> >
> >   - TIF_DISABLE_PTI_NOW : disable PTI for the current task, reset by execve()
> >   - TIF_DISABLE_PTI_NEXT : disable PTI after execve(), reset by execve()
> 
> I really dislike state that isn't cleared on execve().  I'm assuming
> that this is so you can run time pwn_me_without_pti whatever?

Yes exactly. I've just sent a 3rd series with an example code for this.
In fact it's not that the state is not cleared by execve(), it's that
it's set for the next execve() which then resets it.

> Surely LD_PRELOAD can do this, too?

That was one of my other proposals. I really don't know if LD_PRELOAD
fits anyone's usage for such things (static/setuid binaries, complication
to pass variables maybe).

Please take a look and tell me if you still dislike it or not.

thanks!
Willy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ