> > Given that, I think it would still be worthwhile to disable /proc/PID/pagemap. > > Having slept on this further, I think that unprivileged pagemap access > is awful and we should disable it with no option to re-enable. If we > absolutely must, we could allow programs to read all zeros or to read > addresses that are severely scrambled (e.g. ECB-encrypted by a key > generated once per open of pagemap). > - It could easily leak direct-map addresses, and there's a nice paper > detailing a SMAP bypass using that technique. Do you have a pointer? > Can we just try getting rid of it except with global CAP_SYS_ADMIN. > > (Hmm. Rowhammer attacks targeting SMRAM could be interesting.) :-). > >> Can we do anything about that? Disabling cache flushes from userland > >> should make it no longer exploitable. > > > > Unfortunately there's no way to disable userland code's use of > > CLFLUSH, as far as I know. > > > > Maybe Intel or AMD could disable CLFLUSH via a microcode update, but > > they have not said whether that would be possible. > > The Intel people I asked last week weren't confident. For one thing, > I fully expect that rowhammer can be exploited using only reads and > writes with some clever tricks involving cache associativity. I don't > think there are any fully-associative caches, although the cache > replacement algorithm could make the attacks interesting. We should definitely get Intel/AMD to disable CLFLUSH, then. Because if it can be exploited using reads, it is _extremely_ important to know. As it probably means rowhammer can be exploited using Javascript / Java... and affected machines are unsafe even without remote users. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>