Linux Address Space Isolation “ASI” Revived After Lowering 70% Performance Hit To 13%

Several years ago Google engineers began exploring address space isolation for the Linux kernel and ultimately proposing Linux ASI for better dealing with CPU speculative execution attacks. While the hope was it would better cope with the ever growing list of CPU speculative execution vulnerabilities, the effort was thwarted initially by I/O throughput seeing a 70% performance hit. That level of performance cost was unsustainable. But now that I/O overhead has been reduced to just 13%.

Google engineer Brendan Jackman is back to bringing up ASI to Linux kernel developers now that “ASI is fast again…I’ve now prepared an up-to-date ASI branch that demonstrates a technique for solving the page cache performance devastation…The goal of this prototype is to increase confidence that ASI is viable as a broad solution for CPU vulnerabilities. (If the community still has to develop and maintain new mitigations for every individual vuln, because ASI only works for certain use-cases, then ASI isn’t super attractive given its complexity burden). The biggest gap for establishing that confidence was that Google’s deployment still only uses ASI for KVM workloads, not bare-metal processes. And indeed the page cache turned out to be a massive issue that Google just hasn’t run up against yet internally.“

Random reads with FIO were still hit by a 13% regression but at least better than 70%. ASI in current form also increased Linux kernel compilation times by 6~7%. Jackman added:

“Despite my title these numbers are kinda disappointing to be honest, it’s not where I wanted to be by now, but it’s still an order-of-magnitude better than where we were for native FIO a few months ago. I believe almost all of this remaining slowdown is due to unnecessary ASI exits, the key areas being:

– On every context_switch(). Google’s internal implementation has fixed this (we only really need it when switching mms).

– Whenever zeroing sensitive pages from the allocator. This could potentially be solved with the ephmap but requires a bit of care to avoid opening CPU attack windows.

– In copy-on-write for user pages. The ephmap could also help here but the current implementation doesn’t support it (it only allows one allocation at a time per context).”

With this LKML thread the hope now is to figure out if the state is improving good enough that the ASI work can move forward for potentially upstreaming into the Linux kernel.

“So, x86 folks: Does this feel like “line of sight” to you? If not, what would that look like, what experiments should I run?”

We’ll see what happens of Linux ASI.

Keep your files stored safely and securely with the SanDisk 2TB Extreme Portable SSD. With over 69,505 ratings and an impressive 4.6 out of 5 stars, this product has been purchased over 8K+ times in the past month. At only $129.99, this Amazon’s Choice product is a must-have for secure file storage.

Help keep private content private with the included password protection featuring 256-bit AES hardware encryption. Order now for just $129.99 on Amazon!

Help Power Techcratic’s Future – Scan To Support

If Techcratic’s content and insights have helped you, consider giving back by supporting the platform with crypto. Every contribution makes a difference, whether it’s for high-quality content, server maintenance, or future updates. Techcratic is constantly evolving, and your support helps drive that progress.

As a solo operator who wears all the hats, creating content, managing the tech, and running the site, your support allows me to stay focused on delivering valuable resources. Your support keeps everything running smoothly and enables me to continue creating the content you love. I’m deeply grateful for your support, it truly means the world to me! Thank you!