No, I am not saying that every project in the wild has a bad "coding strategy". Some of the most reliable software I use everyday is written in C. Some of this I use for decades without every encountering a crash or similar bug. So the meme that "all C code crashes all the time because of UB" is clearly wrong. It is not intractable, in my experience you just have to document some rules and occasionally make sure they are followed. But I agree that a formal system to enforce ownership is desirable.
back
1 comments
> So the meme that "all C code crashes all the time because of UB" is clearly wrong.
It's not about crash at all, but “all software has security vulnerabilities because of UB” is unfortunately true.
> It is not intractable, in my experience you just have to document some rules and occasionally make sure they are followed.
If even DJB couldn't get that part perfectly I'm pretty certain you cannot either.
Not all software is security relevant. I run a lot of large simulations. I do not care at all if that software would crash on specially prepared inputs. I do care that it's as fast as possible.
> Not all software is security relevant
You're right, only software that has actual users cares about security.
> I run a lot of large simulations. I do not care at all if that software would crash on specially prepared inputs.
But it's not the 50s anymore and digital simulation is a tiny fraction of the code ever written nowadays so it's not a very good argument.
> I do care that it's as fast as possible.
You don't realize it but it ruins your entire argument. If speed is all that matters for your use-case then:
- there's no way you can use runtime bound-checks, and you unconditionally need the compiler to optimize as much as possible around UB, even if it breaks your program every once in a while.
- you likely can't afford dynamic memory allocation, which makes the UAF/double free kind of bugs irrelevant. Not out of “good coding strategy” but because you never free in the first place…
These are hypothesis that don't apply to software industry at large.
Right and there are other ways to achieve strong security guarantees than memory safety, e.g. at the OS level by sandboxing critical operations.
1. It's much more expensive that using a memory-safe language in the first place (maybe cheaper it if you have a big codebase already, but still very expensive and not worth it at all for new code)
2. Sandbox escapes are commonplace, and not everything can even be sandboxed at all.