2018-02-15 20:02 GMT+00:00 Andy Lutomirski <l...@kernel.org>: > On Thu, Feb 15, 2018 at 4:36 PM, Nadav Amit <na...@vmware.com> wrote: >> Based on the understanding that there should be no way for userspace to >> address the kernel-space from compatibility mode, disable it while >> running in compatibility mode as long as the 64-bit code segment of the >> user is not used. >> >> Reenabling PTI is performed by restoring NX-bits to the userspace >> mappings, flushing the TLBs, and notifying all the CPUs that use the >> affected mm to disable PTI. Each core responds by removing the present >> bit for the 64-bit code-segment, and marking that PTI is disabled on >> that core. >> > > I dislike this patch because it's conflating two things. The patch > claims to merely disable PTI for compat tasks, whatever those are. > But it's also introducing a much stronger concept of what a compat > task is. The kernel currently mostly doesn't care whether a task is > "compat" or not, and I think that most remaining code paths that do > care are buggy and should be removed.
Yes, please, don't do a stronger concept.. Speaking from CRIU side, it C/R ia32 tasks with x86_64 binaries. -- Dmitry