5 ms·

Quick reminder that KASLR is broken by "metadata leakage" (the metadata is the page table mappings) on AMD processors by default unless you manually enable KPTI

by paulmd 5y ago

Quick reminder that KASLR is broken by "metadata leakage" (the metadata is the page table mappings) on AMD processors by default unless you manually enable KPTI. This was discovered by the same team that discovered Spectre and Meltdown and the official AMD stance is WONTFIX because it can be mitigated by enabling KPTI, however they also refuse to state that KPTI should be enabled by default on their processors because that would tank their benchmarks. They don't put it in quite those exact words in the bulletin, but the "user and kernel address space boundary" they are referring to that the exploit cannot cross is KPTI. Turn it on and it's mitigated, if it's off kernel pages and user pages live in the same tables and are thus vulnerable. However AMD's official stance is KPTI off-by-default, so generally they are still vulnerable unless you manually enable KPTI. (their ass is covered by the "obey good security practices", i.e. if you actually care you should be turning it on because it's a good security practice in general, but it would nuke their benchmarks just like it did to Intel, so they want it off by default since that's how things are usually benchmarked.) The paper describes several approaches, some of which can be mitigated (the time and power measurement attacks) and some of which cannot except via KPTI (TLB-Evict+Prefetch). The issue is, broadly speaking, unfixed. And actually I think at this point it's past metadata leakage and actually just leaking data considering Lipp has extracted actual memory from the kernel. https://mlq.me/download/amdprefetch.pdf https://mlq.me/download/amdprefetch.pdf https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1017 https://www.amd.com/en/corporate/product-security/bulletin/a...

bravetraveler 5y ago
Forgive me, I'm new to this - but wouldn't the mitigation status also depend on the distribution? It doesn't paint AMD in any better of a light, but it may not be so dire. The distributions at the top don't usually run a mainstream [vanilla] kernel. Consequently, neither do their children/derivatives. For example, the kernel configs for my distribution (Fedora 35) show it as enabled - unless I'm missing some further step: $ zgrep CONFIG_PAGE_TABLE_ISO /boot/config-`uname -r` CONFIG_PAGE_TABLE_ISOLATION=y I ask and remain somewhat curious partly because I don't see the messages in the ring buffer I'd expect (based on some cursory research)
- frankjr 5y ago
  https://security.stackexchange.com/questions/176624/how-do-i-check-if-kpti-is-enabled-on-linux https://security.stackexchange.com/questions/176624/how-do-i...
  - bravetraveler 5y ago
    I appreciate it. I saw that but was a little exhausted to process when I posted There's a bit of hand waving around this it seems lol I have a modern/current kernel (4.x is ancient) built with the option enabled, my command line lacks nopti, yet I do not see the protection message. That's the root of my confusion. When I get back to my machine I'll check the sysfs file
- paulmd 5y ago
  Off-by-default, which remains the recommendation of AMD. 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... Some googling suggests that flag is whether the kernel is compiled with support, not whether it's turned on. You'd need to force boot flag "pti=on" for an AMD system. Postmark or a database benchmark would be a good bench for you to compare, probably. (apparently "kpti=on" is aarch64-specific, other uarchs use "pti" instead, seems kind of odd)
sim7c00 5y ago
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.

by paulmd 5y ago

bravetraveler 5y ago

Forgive me, I'm new to this - but wouldn't the mitigation status also depend on the distribution? It doesn't paint AMD in any better of a light, but it may not be so dire. The distributions at the top don't usually run a mainstream [vanilla] kernel. Consequently, neither do their children/derivatives. For example, the kernel configs for my distribution (Fedora 35) show it as enabled - unless I'm missing some further step: $ zgrep CONFIG_PAGE_TABLE_ISO /boot/config-`uname -r` CONFIG_PAGE_TABLE_ISOLATION=y I ask and remain somewhat curious partly because I don't see the messages in the ring buffer I'd expect (based on some cursory research)

frankjr 5y ago
https://security.stackexchange.com/questions/176624/how-do-i-check-if-kpti-is-enabled-on-linux https://security.stackexchange.com/questions/176624/how-do-i...
- bravetraveler 5y ago
  I appreciate it. I saw that but was a little exhausted to process when I posted There's a bit of hand waving around this it seems lol I have a modern/current kernel (4.x is ancient) built with the option enabled, my command line lacks nopti, yet I do not see the protection message. That's the root of my confusion. When I get back to my machine I'll check the sysfs file
paulmd 5y ago
Off-by-default, which remains the recommendation of AMD. 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... Some googling suggests that flag is whether the kernel is compiled with support, not whether it's turned on. You'd need to force boot flag "pti=on" for an AMD system. Postmark or a database benchmark would be a good bench for you to compare, probably. (apparently "kpti=on" is aarch64-specific, other uarchs use "pti" instead, seems kind of odd)

sim7c00 5y ago

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.