the ideas of turning off the checks for release mode is exactly what makes a language memory unsafe. that workflow protects you from accidental problems but is pretty much useless against the sorts of buffer overflows etc that enable attacks. Your test suite doesn’t test every pathological edge case. if the compiler can’t prove that a check is unnecessary, there’s a pretty good chance it’s needed.
@oscardssmith yes, I think you are describing a different use case: security. To prevent malicious attacks, then you indeed cannot turn off checks. So you are describing the ReleaseSafe mode.
ReleaseSafe indeed has performance penalties. The most obvious one is bounds checking for arrays. Rust for example also has a runtime overhead and keeps bounds checking on all the time. The Rust compiler might be able to optimize out such checks in many cases, but not all cases. I think Fortran has traditionally not been used in the ReleaseSafe mode, but you can do it today with Fortran compilers: keep bounds checks and enable all optimizations. But I think that compilers have not been very optimized for this use case, so the optimizations of bounds checks might not be as good as Rust’s.
Security has to be discussed in the context of the goals of the system. Scientific problems require efficient use of the hardware, and that probably requires “unsafe” code. So-called “safe” code is code that can be mechanically proven to be free of dangling pointers (ie. Rust’s borrow checker implements this). There are many perfectly correct programs that make use of “unsafe” code, like circularly linked lists.
This is why I think these issues of memory safety are outside of the scope of Fortran proper; a well designed system should be robust to issues like this. This was Andrew Tannenbaum’s argument in this presentation at EuroBSD a few years back.
The issue of various software flaws that lead to vulnerabilities and exploits need to be addressed at multiple levels. First, at the application level, very close attention to expected inputs needs to be paid. The inputs to software can be thought of as a formal language, and the software is a recognizer for that language. The language theoretic security approach elaborates on this using computational theory. The security properties of any piece of software can only be verifiable if the input language is either regular or context free.
I recommend this presentation by Meredith Patterson:
At the OS level, any code that can be run in user space, should be. This is the principle of least authority, and violation of it is common practice among all widely implemented operating systems.
1 Like