7 ms·

What you've said is true but I still think the problem is overblown, and solutions at the hardware level are disregarded in favor of dubious and more costly sof

What you've said is true but I still think the problem is overblown, and solutions at the hardware level are disregarded in favor of dubious and more costly software rewrite solutions. If something like CHERI was common then it would automatically find most security-related memory usage bugs, and thus lead to existing software getting fixed for all hardware.

lmm 2y ago
IME you can't reliably extract the intent from the C code, much less the binary, so you can't really fix these bugs without a human rewriting the source. The likes of CHERI might make exploitation harder, but it seems to me that ROP-style workarounds will always be possible, because fundamentally if the program is doing things that look like what it was meant to do then the hardware can never distinguish whether it's actually doing what it was meant to do or not. Even if you were able to come up with a system that ensured that standards-compliant C programs did not have memory bugs (which is already unlikely), that would still require a software rewrite approach in practice because all nontrivial C programs/libraries have latent undefined behaviour.
- wakawaka28 2y ago
  There may be some cases where code would need to be adjusted or annotated to use CHERI well, but that has to be easier than translating to or interfacing with another language.
- gw2 2y ago
  > IME you can't reliably extract the intent from the C code, much less the binary, so you can't really fix these bugs without a human rewriting the source. I am pretty sure that the parent is talking about hardware memory safety which doesn't require any "human rewriting the source".
  - lmm 2y ago
    > I am pretty sure that the parent is talking about hardware memory safety which doesn't require any "human rewriting the source". It does though. The hardware might catch an error (or an "error") and halt the program, but you still need a human to fix it.
    - kazinator 2y ago
      The human might say, sorry my C program is not compatible with your hardware memory safety device. I won't/can't fix that.
      - wakawaka28 2y ago
        That's possible but unlikely. I would be OK with requiring software bugs like that to be fixed, unless it can be explained away as impossible for some reason. We could almost certainly move toward requiring this kind of stuff to be fixed much more easily than we could do the commonly proposed "rewrite it in another language bro" path.
    - gw2 2y ago
      > but you still need a human to fix it. The same thing can be said about a Rust vector OOB panic or any other bug in any safe language. Bugs happen which is why programmers are employed in the first place!
      - lmm 2y ago
        > The same thing can be said about a Rust vector OOB panic or any other bug in any safe language. Bugs happen which is why programmers are employed in the first place! Sure, the point is you're going to need the programmer either way, so "hardware security lets us detect the problem without rewriting the code" isn't really a compelling advantage for that approach.
    - wakawaka28 2y ago
      If a program halts, that is a narrow security issue that will not leak data. Humans need to fix bugs, but that is nothing new. A memory bug with such features would be hardly more significant than any other bug, and people would get better at fixing them over time because they would be easier to detect.
  - kazinator 2y ago
    There's no such thing as hardware memory safety, with absolutely no change to the semantics of the machine as seen by the compiled C program. There are going to be false positives.
    - gw2 2y ago
      > There are going to be false positives Of course, but compare it with rewriting it to a completely different language.

lmm 2y ago

IME you can't reliably extract the intent from the C code, much less the binary, so you can't really fix these bugs without a human rewriting the source. The likes of CHERI might make exploitation harder, but it seems to me that ROP-style workarounds will always be possible, because fundamentally if the program is doing things that look like what it was meant to do then the hardware can never distinguish whether it's actually doing what it was meant to do or not. Even if you were able to come up with a system that ensured that standards-compliant C programs did not have memory bugs (which is already unlikely), that would still require a software rewrite approach in practice because all nontrivial C programs/libraries have latent undefined behaviour.

wakawaka28 2y ago
There may be some cases where code would need to be adjusted or annotated to use CHERI well, but that has to be easier than translating to or interfacing with another language.
gw2 2y ago
> IME you can't reliably extract the intent from the C code, much less the binary, so you can't really fix these bugs without a human rewriting the source. I am pretty sure that the parent is talking about hardware memory safety which doesn't require any "human rewriting the source".
- lmm 2y ago
  > I am pretty sure that the parent is talking about hardware memory safety which doesn't require any "human rewriting the source". It does though. The hardware might catch an error (or an "error") and halt the program, but you still need a human to fix it.
  - kazinator 2y ago
    The human might say, sorry my C program is not compatible with your hardware memory safety device. I won't/can't fix that.
    - wakawaka28 2y ago
      That's possible but unlikely. I would be OK with requiring software bugs like that to be fixed, unless it can be explained away as impossible for some reason. We could almost certainly move toward requiring this kind of stuff to be fixed much more easily than we could do the commonly proposed "rewrite it in another language bro" path.
  - gw2 2y ago
    > but you still need a human to fix it. The same thing can be said about a Rust vector OOB panic or any other bug in any safe language. Bugs happen which is why programmers are employed in the first place!
    - lmm 2y ago
      > The same thing can be said about a Rust vector OOB panic or any other bug in any safe language. Bugs happen which is why programmers are employed in the first place! Sure, the point is you're going to need the programmer either way, so "hardware security lets us detect the problem without rewriting the code" isn't really a compelling advantage for that approach.
  - wakawaka28 2y ago
    If a program halts, that is a narrow security issue that will not leak data. Humans need to fix bugs, but that is nothing new. A memory bug with such features would be hardly more significant than any other bug, and people would get better at fixing them over time because they would be easier to detect.
- kazinator 2y ago
  There's no such thing as hardware memory safety, with absolutely no change to the semantics of the machine as seen by the compiled C program. There are going to be false positives.
  - gw2 2y ago
    > There are going to be false positives Of course, but compare it with rewriting it to a completely different language.