linux-kernel - Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

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: <20180216071139.GC32767@uranus>
Date:   Fri, 16 Feb 2018 10:11:39 +0300
From:   Cyrill Gorcunov <gorcunov@...il.com>
To:     Andy Lutomirski <luto@...nel.org>,
        Andrey Vagin <avagin@...tuozzo.com>,
        Dmitry Safonov <dsafonov@...tuozzo.com>
Cc:     Nadav Amit <nadav.amit@...il.com>,
        Pavel Emelyanov <xemul@...allels.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Willy Tarreau <w@....eu>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

On Thu, Feb 15, 2018 at 11:29:42PM +0000, Andy Lutomirski wrote:
...
> >>> +bool pti_handle_segment_not_present(long error_code)
> >>> +{
> >>> +       if (!static_cpu_has(X86_FEATURE_PTI))
> >>> +               return false;
> >>> +
> >>> +       if ((unsigned short)error_code != GDT_ENTRY_DEFAULT_USER_CS << 3)
> >>> +               return false;
> >>> +
> >>> +       pti_reenable();
> >>> +       return true;
> >>> +}
> >>
> >> Please don't.  You're trying to emulate the old behavior here, but
> >> you're emulating it wrong.  In particular, you won't trap on LAR.
> >
> > Yes, I thought I’ll manage to address LAR, but failed. I thought you said
> > this is not a “show-stopper”. I’ll adapt your approach of using prctl, although
> > it really limits the benefit of this mechanism.
> >
> 
> It's possible we could get away with adding the prctl but making the
> default be that only the bitness that matches the program being run is
> allowed.  After all, it's possible that CRIU is literally the only
> program that switches bitness using the GDT.  (DOSEMU2 definitely does
> cross-bitness stuff, but it uses the LDT as far as I know.)  And I've
> never been entirely sure that CRIU fully counts toward the Linux
> "don't break ABI" guarantee.
> 
> Linus, how would you feel about, by default, preventing 64-bit
> programs from long-jumping to __USER32_CS and vice versa?  I think it
> has some value as a hardening measure.  I've certainly engaged in some
> exploit shenanigans myself that took advantage of the ability to long
> jump/ret to change bitness at will.  This wouldn't affect users of
> modify_ldt() -- 64-bit programs could still create and use their own
> private 32-bit segments with modify_ldt(), and seccomp can (and
> should!) prevent that in sandboxed programs.
> 
> In general, I prefer an approach where everything is explicit to an
> approach where we almost, but not quite, emulate the weird historical
> behavior.
> 
> Pavel and Cyrill, how annoying would it be if CRIU had to do an extra
> arch_prctl() to enable its cross-bitness shenanigans when
> checkpointing and restoring a 32-bit program?

I think this should not be a problem for criu (CC'ing Dima, who has
been working on compat mode support in criu). As far as I remember
we initiate restoring of 32 bit tasks in native 64 bit mode (well,
ia32e to be precise :) mode and then, once everything is ready,
we changing the mode by doing a return to __USER32_CS descriptor.
So this won't be painful to add additional prctl call here.