6 ms·

Optimizing compilers that don't allow disabling all optimizations makes it impossible to write secure code with them. Must do it with assembly.

by nabla9 2y ago

exe34 2y ago
clang::optnone
- nabla9 2y ago
  "Optimizing compilers that don't allow disabling __all__ optimizations"
  - exe34 2y ago
    do these exist? who's using them?
  - layer8 2y ago
    It’s not well-defined what counts as an optimization. For example, should every single source-level read access of a memory location go through all cache levels down to main memory, instead of, for example, caching values in registers? That would be awfully slow. But that question is one reason for UB.
    - kevingadd 2y ago
      Or writing code that relies on inlining and/or tail call optimization to successfully run at all without running out of stack... We've got some code that doesn't run if compiled O0 due to that.
cmeacham98 2y ago
If your "secure" code is not secure because of a compiler optimization it is fundamentally incorrect and broken.
- nabla9 2y ago
  It's secure code we use. I'm sure you know who DJB is.
  - jjuhl 2y ago
    Why is knowing who the author is relevant? Either what he posts is correct or it is not, who the person is is irrelevant.
- hedgehog 2y ago
  There is a fundamental difference of priorities between the two worlds. For most general application code any optimization is fine as long as the output is correct. In security critical code information leakage from execution time and resource usage on the chip matters but that essentially means you need to get away from data-dependent memory access patterns and flow control.
  - account42 2y ago
    Then such code needs to be written in a language that actually makes the relevant timing guarantees. That language may be C with appropriate extensions but it certainly is not C with whining that compilers don't apply my special requirements to all code.
    - hedgehog 2y ago
      That argument would make more sense if such a language was widely available but today in practice it isn't so we live in the universe of less ideal solutions. Actually it doesn't really respond to DJB's point anyway, his case here is that the downstream labor cost of compiler churn exceeds the actual return in performance gains from new features and that a change in policy could give security-related code a more predictable target without requiring a whole new language or toolchain. For what it's worth I think the better solution will end up being something like constant-time function annotations (not stopping new compiler features) but I don't discount his view that absent human nature maybe we would be better of focusing compiler dev on correctness and stability.
bluGill 2y ago
If you have ub then you have a bug and there is some system that will show it. It isn't hard to write code without ub.
- bigstrat2003 2y ago
  It is, in fact, pretty hard as evidenced by how often programmers fail at it. The macho attitude of "it's not hard, just write good code" is divorced from observable reality.
  - bluGill 2y ago
    People write buffer overflows because and memory leaks they are not coreful. The rest of ub are things I have never seen despite running sanitizers and a large codebase.
    - saagarjha 2y ago
      Perhaps you’re not looking all that hard.
      - bluGill 2y ago
        Sanitizers are very good at finding ub.
        deleted 2y ago
        [deleted]
        saagarjha 2y ago
        Sure. That's just a function of how much UB there is, rather than them catching it all.
  - tbrownaw 2y ago
    Staying under the speed limit is, in fact, pretty hard as evidenced by how often drivers fail at it.
Rusky 2y ago
Disabling all optimizations isn't even enough- fundamentally what you need is a much narrower specification for how the source language maps to its output. Even -O0 doesn't give you that, and in fact will often be counterproductive (e.g. you'll get branches in places that the optimizer would have removed them). The problem with this is that no general purpose compiler wants to tie its own hands behind its back in this way, for the benefit of one narrow use case. It's not just that it would cost performance for everyone else, but also that it requires a totally different approach to specification and backwards compatibility, not to mention deep changes to compiler architecture. You almost may as well just design a new language, at that point.
- amluto 2y ago
  > You almost may as well just design a new language, at that point. Forget “almost”. Go compile this C code: void foo(int *ptr) { free(ptr); *ptr = 42; } This is UB. And it has nothing whatsoever to do with optimizations — any sensible translation to machine code is a use-after-free, and an attacker can probably find a way to exploit that machine code to run arbitrary code and format your disk. If you don’t like this, use a language without UB. But djb wants something different, I think: a way to tell the compiler not to introduce timing dependencies on certain values. This is a nice idea, but it needs hardware support! Your CPU may well implement ALU instructions with data-dependent timing. Intel, for example, reserves the right to do this unless you set an MSR to tell it not to. And you cannot set that MSR from user code, so what exactly is a compiler supposed to do? https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html https://www.intel.com/content/www/us/en/developer/articles/t...
  - Rusky 2y ago
    I am not talking about UB at all. I am talking about the same constant-time stuff that djb's post is talking about.
    - SAI_Peregrinus 2y ago

Optimizing compilers that don't allow disabling all optimizations makes it impossible to write secure code with them. Must do it with assembly.

by nabla9 2y ago

Optimizing compilers that don't allow disabling all optimizations makes it impossible to write secure code with them. Must do it with assembly.

exe34 2y ago

clang::optnone

nabla9 2y ago
"Optimizing compilers that don't allow disabling __all__ optimizations"
- exe34 2y ago
  do these exist? who's using them?
- layer8 2y ago
  It’s not well-defined what counts as an optimization. For example, should every single source-level read access of a memory location go through all cache levels down to main memory, instead of, for example, caching values in registers? That would be awfully slow. But that question is one reason for UB.
  - kevingadd 2y ago
    Or writing code that relies on inlining and/or tail call optimization to successfully run at all without running out of stack... We've got some code that doesn't run if compiled O0 due to that.

cmeacham98 2y ago

If your "secure" code is not secure because of a compiler optimization it is fundamentally incorrect and broken.

nabla9 2y ago
It's secure code we use. I'm sure you know who DJB is.
- jjuhl 2y ago
  Why is knowing who the author is relevant? Either what he posts is correct or it is not, who the person is is irrelevant.
hedgehog 2y ago
There is a fundamental difference of priorities between the two worlds. For most general application code any optimization is fine as long as the output is correct. In security critical code information leakage from execution time and resource usage on the chip matters but that essentially means you need to get away from data-dependent memory access patterns and flow control.
- account42 2y ago
  Then such code needs to be written in a language that actually makes the relevant timing guarantees. That language may be C with appropriate extensions but it certainly is not C with whining that compilers don't apply my special requirements to all code.
  - hedgehog 2y ago
    That argument would make more sense if such a language was widely available but today in practice it isn't so we live in the universe of less ideal solutions. Actually it doesn't really respond to DJB's point anyway, his case here is that the downstream labor cost of compiler churn exceeds the actual return in performance gains from new features and that a change in policy could give security-related code a more predictable target without requiring a whole new language or toolchain. For what it's worth I think the better solution will end up being something like constant-time function annotations (not stopping new compiler features) but I don't discount his view that absent human nature maybe we would be better of focusing compiler dev on correctness and stability.

bluGill 2y ago

If you have ub then you have a bug and there is some system that will show it. It isn't hard to write code without ub.

bigstrat2003 2y ago
It is, in fact, pretty hard as evidenced by how often programmers fail at it. The macho attitude of "it's not hard, just write good code" is divorced from observable reality.
- bluGill 2y ago
  People write buffer overflows because and memory leaks they are not coreful. The rest of ub are things I have never seen despite running sanitizers and a large codebase.
  - saagarjha 2y ago
    Perhaps you’re not looking all that hard.
    - bluGill 2y ago
      Sanitizers are very good at finding ub.
      - deleted 2y ago
        [deleted]
      - saagarjha 2y ago
        Sure. That's just a function of how much UB there is, rather than them catching it all.
- tbrownaw 2y ago
  Staying under the speed limit is, in fact, pretty hard as evidenced by how often drivers fail at it.

Rusky 2y ago

Disabling all optimizations isn't even enough- fundamentally what you need is a much narrower specification for how the source language maps to its output. Even -O0 doesn't give you that, and in fact will often be counterproductive (e.g. you'll get branches in places that the optimizer would have removed them). The problem with this is that no general purpose compiler wants to tie its own hands behind its back in this way, for the benefit of one narrow use case. It's not just that it would cost performance for everyone else, but also that it requires a totally different approach to specification and backwards compatibility, not to mention deep changes to compiler architecture. You almost may as well just design a new language, at that point.

amluto 2y ago
> You almost may as well just design a new language, at that point. Forget “almost”. Go compile this C code: void foo(int *ptr) { free(ptr); *ptr = 42; } This is UB. And it has nothing whatsoever to do with optimizations — any sensible translation to machine code is a use-after-free, and an attacker can probably find a way to exploit that machine code to run arbitrary code and format your disk. If you don’t like this, use a language without UB. But djb wants something different, I think: a way to tell the compiler not to introduce timing dependencies on certain values. This is a nice idea, but it needs hardware support! Your CPU may well implement ALU instructions with data-dependent timing. Intel, for example, reserves the right to do this unless you set an MSR to tell it not to. And you cannot set that MSR from user code, so what exactly is a compiler supposed to do? https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html https://www.intel.com/content/www/us/en/developer/articles/t...
- Rusky 2y ago
  I am not talking about UB at all. I am talking about the same constant-time stuff that djb's post is talking about.
  - SAI_Peregrinus 2y ago