>> On Feb 15, 2018, at 4:08 PM, Linus Torvalds <torva...@linux-foundation.org> >> wrote: >> >> On Thu, Feb 15, 2018 at 3:29 PM, Andy Lutomirski <l...@kernel.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.
If we're going to do Nadav's thing, I think we have no choice. We could say that Nadav's idea of turning off PTI for 32-bit is just too messy, though. > >> 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? That's the idea. We already switch out three GDT entries for TLS. Switching two more isn't going to kill us. > > 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. The clever scheme is that we have a new (maybe default) compat-and-i-mean-it mode that removes the DPL=3 L code segment from the GDT and prevents opportunistic SYSRET.
