Hey Roman, On 21.06.24 22:14, Roman Kagan wrote:
In a series posted a few years ago [1], a proposal was put forward to allow the kernel to allocate memory local to a mm and thus push it out of reach for current and future speculation-based cross-process attacks. We still believe this is a nice thing to have. However, in the time passed since that post Linux mm has grown quite a few new goodies, so we'd like to explore possibilities to implement this functionality with less effort and churn leveraging the now available facilities. Specifically, this is a proof-of-concept attempt to implement mm-local allocations piggy-backing on memfd_secret(), using regular user addressess but pinning the pages and flipping the user/supervisor flag on the respective PTEs to make them directly accessible from kernel, and sealing the VMA to prevent userland from taking over the address range. The approach allowed to delegate all the heavy lifting -- address management, interactions with the direct map, cleanup on mm teardown -- to the existing infrastructure, and required zero architecture-specific code. Compared to the approach used in the orignal series, where a dedicated kernel address range and thus a dedicated PGD was used for mm-local allocations, the one proposed here may have certain drawbacks, in particular - using user addresses for kernel memory may violate assumptions in various parts of kernel code which we may not have identified with smoke tests we did - the allocated addresses are guessable by the userland (ATM they are even visible in /proc/PID/maps but that's fixable) which may weaken the security posture Also included is a simple test driver and selftest to smoke test and showcase the feature. The code is PoC RFC and lacks a lot of checks and special case handling, but demonstrates the idea. We'd appreciate any feedback on whether it's a viable approach or it should better be abandoned in favor of the one with dedicated PGD / kernel address range or yet something else. [1] https://lore.kernel.org/lkml/20190612170834.14855-1-mhillenb@xxxxxxxxx/
I haven't seen any negative feedback on the RFC, so when can I expect a v1 of this patch set that addresses the non-production-readyness of it that you call out above? :)
Alex Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597
