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: <CA+55aFypED6i6pESAnk_RPUon_cyvdP3g-QZg2gspEBNAQWvmQ@mail.gmail.com>
Date:   Thu, 15 Feb 2018 16:08:33 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Nadav Amit <nadav.amit@...il.com>,
        Pavel Emelyanov <xemul@...allels.com>,
        Cyrill Gorcunov <gorcunov@...nvz.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 3:29 PM, Andy Lutomirski <luto@...nel.org> wrote:
>
> 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.

Ugh.

There are just _so_ many reasons to dislike that.

It's not that I don't think we could try to encourage it, but this
whole "security depends on it being in sync" seems really like a
fundamentally bad design.

> Linus, how would you feel about, by default, preventing 64-bit
> programs from long-jumping to __USER32_CS and vice versa?

How? It's a standard GDT entry. Are you going to start switching the
GDT around every context switch?

I *thought* that user space can just do a far jump on its own. But
it's so long since I had to care that I may have forgotten all the
requirements for going between "compatibility mode" and real long
mode.

I just feel this all is a nightmare. I can see how you would want to
think that compatibility mode doesn't need PTI, but at the same time
it feels like a really risky move to do this.

I can see one thread being in compatibiilty mode, and another being in
long mode, and sharing the address space. But even with just one
thread, I'm not seeing how you keep user mode from going from
compatibility mode to L mode with just a far jump.

But maybe you have some clever scheme in mind that guarantees that
there are no issues, or maybe I've just forgotten all the details of
long mode vs compat mode.

               Linus