Linux Adjusts "Meltdown Lite" Mitigation Handling On Newer Zen 5 CPUs

[ATLief]

In fact, the STAC/CLAC change is probably a non-negligible part of why Zen5 is dominating in benchmarks. It will speed up ~all syscalls that ever access guest memory.

So will fixing this vulnerability hurt Linux performance on Zen5 / make it more similar to Zen4? Will it be enough to invalidate previous benchmarks?

[andyhhp]

So will fixing this vulnerability hurt Linux performance on Zen5 / make it more similar to Zen4? Will it be enough to invalidate previous benchmarks?

This change should be negligible.

There was previously an optimisation which should be a win across the board. In fact, Intel's kernel test robot measured it at +6.8% improvement on stress-ng. (https://lore.kernel.org/all/[email protected]/)

However, the optimisation made Linux vulnerable to CVE-2020-12965 on AMD systems. This is is an adjustment to that optimisation, to keep it fast but without the problem on AMD.

~Andrew

[hinicogi]

Maybe someone who understands deeper could explain why the conditional sizing of the pointer limit is commented out:

+ /*
+ * Enable this when LAM is gated on LASS support
+ if (cpu_feature_enabled(X86_FEATURE_LAM))
+ USER_PTR_MAX = (1ul << 63) - PAGE_SIZE - 1;
+ */
+ runtime_const_init(ptr, USER_PTR_MAX);

[andyhhp]

Maybe someone who understands deeper could explain why the conditional sizing of the pointer limit is commented out:

+ /*
+ * Enable this when LAM is gated on LASS support
+ if (cpu_feature_enabled(X86_FEATURE_LAM))
+ USER_PTR_MAX = (1ul << 63) - PAGE_SIZE - 1;
+ */
+ runtime_const_init(ptr, USER_PTR_MAX);

LAM (Linear Address Masking) is a feature permitting the use of metadata in the high bits of pointers, rather than demanding sign extension (the current behaviour). It is a feature intended for JITs, ASAN, etc. Support for LAM is still in review on the mailing list.

However enabling LAM allows speculative sidechannels to leak data it previously couldn't leak (i.e. previously blocked by the sign extension requirement). This is the subject of a research paper called SLAM. https://lwn.net/Articles/953880/

There's a separate feature, LASS (Linear Address Space Separation) which is a far more comprehensive prevention of sidechannels (speculative and otherwise). However, it's not available in all CPUs which support LAM, and Linux has decided to veto the use of LAM in those systems.

The reason the logic is commented out is that it is logic that needs to be turned on by LAM support, but only after a) LASS is enabled too, or b) LAM is hard-vetoed on non-LASS systems.

~Andrew

[caligula]

Why is that interesting? Like he wouldn't be capable?
I know lots of 50+ that would code circles around their younger peers.

Beside. I credit the man for working his brain, instead of letting it turn to mush.

Usually if you're talented, you'll become an executive person, some manager, or angel investor after the age of 35 to 40 years. Or maybe start a new company and become a millionaire CEO. If seriously autistic, maybe CTO.

[sophisticles]

Goddammit they even have an advisory for it on their own website, go read it if you don't believe it. Nearly any halfway performant CPU has some transient execution vulnerabilities.

I take it you missed the sarcasm dripping from my comment.