Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • sophisticles
    replied
    Originally posted by archkde View Post

    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.

    Leave a comment:


  • caligula
    replied
    Originally posted by milkylainen View Post

    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.

    Leave a comment:


  • andyhhp
    replied
    Originally posted by hinicogi View Post
    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

    Leave a comment:


  • hinicogi
    replied
    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);​

    Leave a comment:


  • andyhhp
    replied
    Originally posted by ATLief View Post

    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

    Leave a comment:


  • ATLief
    replied
    Originally posted by andyhhp View Post
    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?​

    Leave a comment:


  • muncrief
    replied
    This is not working because I'm still melting down internally!

    Oh wait ...

    Never mind

    Leave a comment:


  • EphemeralEft
    replied
    Incoming “I don’t use CPU mitigations anyway, hehehe” comments…

    Leave a comment:


  • User29
    replied
    Originally posted by milkylainen View Post

    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.
    i think he meant "it's always interesting to see the old masters in action"

    Leave a comment:


  • archkde
    replied
    Originally posted by sophisticles View Post
    I find it hard to believe that AMD CPUs have security vulnerabilities.

    Can we get a fact check?
    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.

    Leave a comment:

Working...
X