It's not an AMD feature, but AMD does dictate (or rather, strongly influence) whether it's on by default. The OS community listens to what AMD and Intel say an

It's not an AMD feature, but AMD does dictate (or rather, strongly influence) whether it's on by default. The OS community listens to what AMD and Intel say and generally follow their guidance. When AMD says "we don't need it", that generally is taken as a pretty authoritative statement. https://www.phoronix.com/scan.php?page=article&item=if-amd-kpti&num=1 https://www.phoronix.com/scan.php?page=article&item=if-amd-k... Now - the problem is there's obviously a lot of self-interest here, because the KPTI mitigation is pretty performance-intensive. You have to basically flush the TLB every time you do a syscall, and that hurts server pretty heavily in particular. AMD is making a big push into server with Epyc - it's really the entire focus of the Zen/Ryzen design, consumer CPUs are a convenient synergy. The performance hit is around 10% in most cases, 20-30% in some more IO-intensive situations (database loads, etc). Obviously they would rather not have that turned on, but what they're low-key saying in their bulletin is that not turning it on (no user-kernel cache boundary) leaks memory. They're being coy and downplaying it, so they're saying the inverse "the exploit doesn't work if you turn on KPTI", rather than outright confirming "it does work if you don't enable KPTI", and they refuse to say KPTI by name, but that's what's going on there. The exploit author stated outright that KPTI mitigated the problem and should probably be enabled by default, but AMD is conveniently leaving off the second half of that sentence. Systems are routinely benchmarked in a default/manufacturer-recommended configuration, if they had to turn on KPTI by default it would significantly hurt their server benchmarks, at a time when the company is making an enormous push for server. It's much better for them to have their processors benched in an insecure-by-default configuration while forcing Intel to constantly flush their caches, and that's what I see going on there. But people are generally very generous with giving AMD the benefit of the doubt, and truth be told the chances of it actually being exploited in practice are slim anyway (just like Intel), so it's likely a bet that will work out for AMD. And even if someone did get hacked - they did the CYA "if you care you should probably enable it" in their various security bulletins, so sucks to be you, even if their default was unsafe. Even ignoring whether or not it leaks actual memory - the exploit author says it does, AMD doesn't explicitly confirm or deny either way - KASLR has been broken for some time on AMD processors unless you manually enable KPTI. And that makes chaining attacks much easier, because now you don't have to guess where to point your Specter exploit (or in this case - a stack overflow), the chip will just tell you.