5 ms·

I'm sort of surprised Intel is still an option. since they never revamped the fundamentals of their hyperthreading technology their spectre/meltdown/etc mitiga

I'm sort of surprised Intel is still an option. since they never revamped the fundamentals of their hyperthreading technology their spectre/meltdown/etc mitigations still send every new chip they make to the barber for a 15-30% haircut in performance. last hn metrics focused exclusively on comparing their performance against...another Intel chip. just because players like f5 chose to ignore the patches and their Linux kernel patch shipped disabled by default doesn't mean they're out of the woods

gtirloni 4y ago
Is AMD _not_ paying the same price in performance because of spectre/meltdown?
- toast0 4y ago
  AMD is paying a smaller price; they still had some mitigations to do, but they didn't let speculative memory accesses bypass access control, IIRC, so there's less speculation to turn off.
  - itvision 4y ago
    > AMD is paying a smaller price; they still had some mitigations to do, but they didn't let speculative memory accesses bypass access control, IIRC, so there's less speculation to turn off. And this is also blatantly false. Zen 3 CPUs have a bigger overhead mitigating Spectre than Zen 2 and modern Intel uArchs. Check Phoronix for performance reviews.
- paulmd 4y ago
  AMD isn't vulnerable to Meltdown, but they do have their own Meltdown-style vulnerability (actually discovered by the same team) that remains unpatched at a CPU level. https://www.usenix.org/system/files/sec22summer_lipp.pdf https://www.usenix.org/system/files/sec22summer_lipp.pdf The first two attack primitives have been patched, sorta, by making those measurements require root access (and making them inaccessible to VM guests). So they're not fixed, but in a properly configured system you won't be able to get at the primitives needed for the attack. The third measurement, however, remains unpatched. It can be mitigated by turning on KPTI, but AMD doesn't change the default because of the performance consequences. KPTI works by constantly flushing the TLB cache every time you hop to kernel-level code (ie every time you make a syscall), thus creating a "cache barrier" between the two privilege levels - the attack then cannot leak something that is on the higher privilege level, because it's never in cache. This is the same way Intel mitigated meltdown, and it has a large performance impact - every time you talk to the network, or disk, or anything else, you have to flush your TLB cache. AMD's official advice is "this doesn't work if you enforce address-space boundaries, follow all security best-practices", the subtext being you need to enable KPTI, but they won't recommend the option be set by default, and they've done their level best to shove it under the rug. Which is understandable, for some reason it's entered the public consciousness that "AMD doesn't have vulnerabilities" and it would be very bad for their image if that notion were dispelled. https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1017 https://www.amd.com/en/corporate/product-security/bulletin/a... Briefly discussed and measured in Phoronix here: 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... So yeah, AMD doesn't pay the same price for mitigating side-channel attacks... because they don't mitigate them. As phoronix discusses, this gets back to the question of whether everyone needs to be mitigating these, we're not all cloud hyperscalers and there's never been a consumer attack using smeltdown-style attacks (it's far easier to just drop some malware and steal the password vault rather than to randomly scan through memory looking for it - you don't have to be the fastest animal in the herd... just not the slowest) but AMD has kinda chosen insecure-by-default here. Sure, that's faster, and you can turn off mitigations on Intel too. Should you? The odds of an exploit are slight, but that didn't prevent people from taking heavy precautions when this category of exploits was (re-)discovered.
seoaeu 4y ago
Literally none of the new Intel processors are vulnerable meltdown
mhh__ 4y ago
Basically all out of order superscalar processors are vulnerable to Spectre. Intel have already mitigated meltdown in hardware, remember that it was disclosed 4 years ago now...
itvision 4y ago
> since they never revamped the fundamentals of their hyperthreading technology their spectre/meltdown/etc mitigations still send every new chip they make to the barber for a 15-30% haircut in performance. Most of this is blatantly egregiously false.

gtirloni 4y ago

Is AMD _not_ paying the same price in performance because of spectre/meltdown?

toast0 4y ago
AMD is paying a smaller price; they still had some mitigations to do, but they didn't let speculative memory accesses bypass access control, IIRC, so there's less speculation to turn off.
- itvision 4y ago
  > AMD is paying a smaller price; they still had some mitigations to do, but they didn't let speculative memory accesses bypass access control, IIRC, so there's less speculation to turn off. And this is also blatantly false. Zen 3 CPUs have a bigger overhead mitigating Spectre than Zen 2 and modern Intel uArchs. Check Phoronix for performance reviews.
paulmd 4y ago
AMD isn't vulnerable to Meltdown, but they do have their own Meltdown-style vulnerability (actually discovered by the same team) that remains unpatched at a CPU level. https://www.usenix.org/system/files/sec22summer_lipp.pdf https://www.usenix.org/system/files/sec22summer_lipp.pdf The first two attack primitives have been patched, sorta, by making those measurements require root access (and making them inaccessible to VM guests). So they're not fixed, but in a properly configured system you won't be able to get at the primitives needed for the attack. The third measurement, however, remains unpatched. It can be mitigated by turning on KPTI, but AMD doesn't change the default because of the performance consequences. KPTI works by constantly flushing the TLB cache every time you hop to kernel-level code (ie every time you make a syscall), thus creating a "cache barrier" between the two privilege levels - the attack then cannot leak something that is on the higher privilege level, because it's never in cache. This is the same way Intel mitigated meltdown, and it has a large performance impact - every time you talk to the network, or disk, or anything else, you have to flush your TLB cache. AMD's official advice is "this doesn't work if you enforce address-space boundaries, follow all security best-practices", the subtext being you need to enable KPTI, but they won't recommend the option be set by default, and they've done their level best to shove it under the rug. Which is understandable, for some reason it's entered the public consciousness that "AMD doesn't have vulnerabilities" and it would be very bad for their image if that notion were dispelled. https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1017 https://www.amd.com/en/corporate/product-security/bulletin/a... Briefly discussed and measured in Phoronix here: 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... So yeah, AMD doesn't pay the same price for mitigating side-channel attacks... because they don't mitigate them. As phoronix discusses, this gets back to the question of whether everyone needs to be mitigating these, we're not all cloud hyperscalers and there's never been a consumer attack using smeltdown-style attacks (it's far easier to just drop some malware and steal the password vault rather than to randomly scan through memory looking for it - you don't have to be the fastest animal in the herd... just not the slowest) but AMD has kinda chosen insecure-by-default here. Sure, that's faster, and you can turn off mitigations on Intel too. Should you? The odds of an exploit are slight, but that didn't prevent people from taking heavy precautions when this category of exploits was (re-)discovered.

seoaeu 4y ago

Literally none of the new Intel processors are vulnerable meltdown

mhh__ 4y ago

Basically all out of order superscalar processors are vulnerable to Spectre. Intel have already mitigated meltdown in hardware, remember that it was disclosed 4 years ago now...

itvision 4y ago

> since they never revamped the fundamentals of their hyperthreading technology their spectre/meltdown/etc mitigations still send every new chip they make to the barber for a 15-30% haircut in performance. Most of this is blatantly egregiously false.