On January 21, 2018 6:11:07 PM PST, Linus Torvalds <torva...@linux-foundation.org> wrote: >On Sun, Jan 21, 2018 at 3:46 PM, Nadav Amit <nadav.a...@gmail.com> >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. > >Too bad x86-64 got rid of the segments ;) > > Linus
No idea about Intel, but at least on Transmeta CPUs the limit check was asynchronous with the access. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
