3 ms·

half of your text makes it read like KASLR and/or KPTI is an AMD feature, but isn't KPTI and KASLR both kernel features? So what would AMD have to say about it

half of your text makes it read like KASLR and/or KPTI is an AMD feature, but isn't KPTI and KASLR both kernel features? So what would AMD have to say about it being off by default? From the page you link: CONFIG_PAGE_TABLE_ISOLATION=y in the kernel configuration. This only indicates that the kernel is capable of kernel page-table isolation. KPTI can be disabled at boot time from the kernel command line through the nopti or pti=off options. On some systems, it can be disabled at runtime by writing 0 to /sys/kernel/debug/x86/pti_enabled. Does AMD dictate if this nopti or pti=off is set in the _kernel_ commandline? (curiosity - pls don't kill me :cat-emote:)

paulmd 5y ago
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.

paulmd 5y ago

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.