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. > 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