The concept of memory-safe languages is within the information currently. C/C++ is known for being the world’s system language (that runs most issues) but in addition notorious for being unsafe. Many wish to remedy this by hard-forking the world’s system code, both by altering C/C++ into one thing that’s memory-safe, or rewriting all the pieces in Rust.
Forking is a silly thought. The core precept of computer-science is that we have to stay with legacy, not abandon it.
And there’s no want. Fashionable C compilers have already got the flexibility to be memory-safe, we simply have to make minor — and appropriate — adjustments to show it on. As a substitute of a hard-fork that abandons legacy system, this may be a soft-fork that permits memory-safety for brand new methods.
Think about the newest memory-safety flaw in OpenSSL. They fixed it by first including a memory-bounds, then placing each entry to the reminiscence behind a macro PUSHC() that checks the memory-bounds:
A greater (however at the moment hypothetical) repair could be one thing like the next:
size_t maxsize CHK_SIZE(outptr) = out ? *outlen : 0;
This may hyperlink the memory-bounds maxsize with the reminiscence outptr. The compiler can then be relied upon to do all of the bounds checking to stop buffer overflows, the remainder of the code wouldn’t have to be modified.
An excellent higher (and hypothetical) repair could be to alter the operate declaration like the next:
int ossl_a2ulabel(const char *in, char *out, size_t *outlen CHK_INOUT_SIZE(out));
That’s the intent anyway, that *outlen is the memory-bounds of out on enter, and receives a shorter bounds on output.
This particular function isn’t in compilers. However gcc and clang already produce other comparable options. They’ve solely been midway applied. This function could be comparatively straightforward so as to add. I’m at the moment learning the code to see how I can add it myself. I may simply largely copy what’s finished for the alloc_size attribute. However there’s a substantial studying curve, I’d reasonably simply persuade an present developer of gcc or clang so as to add the brand new attributes for me.
When you give the programmer the flexibility to repair memory-safety issues like the answer above, you’ll be able to then allow warnings for unsafe code. The compiler knew the above code was unsafe, however since there’s no sensible technique to repair it, it’s pointless nagging the programmer about it. With this new options comes warnings about failing to make use of it.
In different phrases, it turns into compiler-guided refactoring. Forking code is tough, refactoring is simple.
Because the above operate reveals, the OpenSSL code is already considerably reminiscence secure, simply based mostly upon the flawed precept of relying upon diligent programmers. We’d like the compiler to implement it. With such options, the hole is relative small, largely simply altering operate parameter lists and information buildings to hyperlink a pointer with its memory-bounds. The refactoring effort could be small, reasonably than a serious rewrite.
This may be a soft-fork. The memory-bounds would work solely when compiled with new compilers. The macro could be ignored on older methods.
This memory-safety is an issue. The concept of abandoning C/C++ isn’t an answer. We have already got the beginnings of an answer in trendy gcc and clang compilers. We simply want to increase that answer.
*** It is a Safety Bloggers Community syndicated weblog from Errata Security authored by Robert Graham. Learn the unique submit at: https://blog.erratasec.com/2023/02/c-can-be-memory-safe.html
