Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sun, Jan 21, 2018 at 3:46 PM, Nadav Amit <nadav.amit@xxxxxxxxx> wrote: >> I wanted to see whether segments protection can be a replacement for PTI >> (yes, excluding SMEP emulation), or whether speculative execution “ignores” >> limit checks, similarly to the way paging protection is skipped. >> >> It does seem that segmentation provides sufficient protection from Meltdown. >> The “reliability” test of Gratz PoC fails if the segment limit is set to >> prevent access to the kernel memory. [ It passes if the limit is not set, >> even if the DS is reloaded. ] My test is enclosed below. > > Interesting. It might not be entirely reliable for all > microarchitectures, though. > >> So my question: wouldn’t it be much more efficient to use segmentation >> protection for x86-32, and allow users to choose whether they want SMEP-like >> protection if needed (and then enable PTI)? > > That's what we did long long ago, with user space segments actually > using the limit (in fact, if you go back far enough, the kernel even > used the base). > > You'd have to make sure that the LDT loading etc do not allow CPL3 > segments with base+limit past TASK_SIZE, so that people can't generate > their own. And the TLS segments also need to be limited (and > remember, the limit has to be TASK_SIZE-base, not just TASK_SIZE). > > And we should check with Intel that segment limit checking really is > guaranteed to be done before any access. Thanks. I’ll try to check with Intel liaison people of VMware (my employer), yet any feedback will be appreciated. > Too bad x86-64 got rid of the segments ;) Actually, as I noted in a different thread, running 32-bit binaries on x86_64 in legacy-mode, without PTI, performs considerably better than x86_64 binaries with PTI for workloads that are hit the most (e.g., Redis). By dynamically removing the 64-bit user-CS from the GDT, this mode should be safe, as long as CS load is not done speculatively. Regards, Nadav -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href
