3 ms·

Again, not all optimizations that compiler writers can come up with are Good Ideas. Since the Meltdown and Spectre processor vulnerabilities came to light back

by bcrl 5y ago

Again, not all optimizations that compiler writers can come up with are Good Ideas. Since the Meltdown and Spectre processor vulnerabilities came to light back in 2017, many large projects have been forced to switch to prioritizing security over performance. With that shift in the industry, I think it's fair to expect compiler writers to give greater weight to potential security issues (including issues related to UB). It really is a different world now than it was 5 years ago on this front.

astrange 5y ago
Meltdown shouldn’t have required anyone to switch anything since it was a purely Intel hardware bug. Even saying Spectre causes you to care more about memory safety sounds like marketing fluff. Fixing memory bugs doesn’t even prevent Spectre issues.
- bcrl 5y ago
  When Spectre and Meltdown hit, the Linux kernel was forced down the path of adding mitigations which pessimised the generated code. Performance is no longer the primary driver of generated code. That is a change in technical direction and is hardly "marketing fluff". And it doesn't just impact Linux, it impacts languages that are implemented using JIT engines that virtually everyone uses. Thankfully Linux was able to badger the C compiler into doing what was needed, but these sorts of needs of system level projects are way outside of what ISO C permits, and they're hard technical requirements now that can't be ignored.
  - astrange 5y ago
    Memory safety was always and is still more important than performance in code generation, and it's by far the most important thing in security. Spectre mitigations in userland are mostly about removing exact sources of timing data rather than changing anything else. There are code changes to stop branch prediction but it's mainly limited to the kernel. Or even limited to the Linux kernel, because other OSes have different approaches to it.
  - gpderetta 5y ago
    IIRC a few mitigations were rolled back as the additional safety was not worth the performance cost.

by bcrl 5y ago

astrange 5y ago

Meltdown shouldn’t have required anyone to switch anything since it was a purely Intel hardware bug. Even saying Spectre causes you to care more about memory safety sounds like marketing fluff. Fixing memory bugs doesn’t even prevent Spectre issues.

bcrl 5y ago
When Spectre and Meltdown hit, the Linux kernel was forced down the path of adding mitigations which pessimised the generated code. Performance is no longer the primary driver of generated code. That is a change in technical direction and is hardly "marketing fluff". And it doesn't just impact Linux, it impacts languages that are implemented using JIT engines that virtually everyone uses. Thankfully Linux was able to badger the C compiler into doing what was needed, but these sorts of needs of system level projects are way outside of what ISO C permits, and they're hard technical requirements now that can't be ignored.
- astrange 5y ago
  Memory safety was always and is still more important than performance in code generation, and it's by far the most important thing in security. Spectre mitigations in userland are mostly about removing exact sources of timing data rather than changing anything else. There are code changes to stop branch prediction but it's mainly limited to the kernel. Or even limited to the Linux kernel, because other OSes have different approaches to it.
- gpderetta 5y ago
  IIRC a few mitigations were rolled back as the additional safety was not worth the performance cost.