3 ms·

I appreciate memory safety, but feel memory safety is often discussed to a panacea-like degree, like in this article, that ignores the risks of rewriting to ach

by trimbo 4y ago

I appreciate memory safety, but feel memory safety is often discussed to a panacea-like degree, like in this article, that ignores the risks of rewriting to achieve it. From your example, the idea of porting existing C and C++ code in the kernel or Chrome that has been stable in production for years, or sometimes decades, to Rust. The rewrite itself can create new exploits via the logic, especially considering the level of code being rewritten combined with Hyrum's Law. So is it a higher or lower risk to continue to solidify existing code with better practices and tools (asan, msan, smart pointers, etc), or to rewrite it all in Rust? I don't know the answer. Because I don't think there's a clear way to evaluate and compare that risk profile ahead of time for any particular piece of non-trivial code. But I do think too many people are discussing rewrites at scale with the justification of memory safety, without considering the risk the nature of a rewrite adds back.

thesuperbigfrog 4y ago
>> I appreciate memory safety, but feel memory safety is often discussed to a panacea-like degree, like in this article, that ignores the risks of rewriting to achieve it. You are correct. Rewriting working code is a risk, especially for stable, mature projects. The "panacea-like degree" is probably due to the refreshment, relief, and liberation that developers feel when working in a memory safe environment. When an estimated 70% of errors are due to memory safety issues, the excitement that developers feel is palpable. >> The rewrite itself can create new exploits via the logic, especially considering the level of code being rewritten combined with Hyrum's Law. So is it a higher or lower risk to continue to solidify existing code with better practices and tools (asan, msan, smart pointers, etc), or to rewrite it all in Rust? The risks are real and vary on a per-project basis. I think it depends on the needs and expectations of the project. For example, a mature project that is not adding new features and is not in a critical role or likely to be targetted for security exploitation probably does not need to be changed. Other projects under active development or in more critical roles may need to be partially rewritten to protect sensitive functionality (e.g. network handling code, input handling, parsers, etc.) New projects should choose memory safe languages unless there is simply no other option. >> I don't think there's a clear way to evaluate and compare that risk profile ahead of time for any particular piece of non-trivial code. Sometimes we don't fully understand the problems until we start writing code. It is part of the nature of software development.

by trimbo 4y ago

thesuperbigfrog 4y ago

>> I appreciate memory safety, but feel memory safety is often discussed to a panacea-like degree, like in this article, that ignores the risks of rewriting to achieve it. You are correct. Rewriting working code is a risk, especially for stable, mature projects. The "panacea-like degree" is probably due to the refreshment, relief, and liberation that developers feel when working in a memory safe environment. When an estimated 70% of errors are due to memory safety issues, the excitement that developers feel is palpable. >> The rewrite itself can create new exploits via the logic, especially considering the level of code being rewritten combined with Hyrum's Law. So is it a higher or lower risk to continue to solidify existing code with better practices and tools (asan, msan, smart pointers, etc), or to rewrite it all in Rust? The risks are real and vary on a per-project basis. I think it depends on the needs and expectations of the project. For example, a mature project that is not adding new features and is not in a critical role or likely to be targetted for security exploitation probably does not need to be changed. Other projects under active development or in more critical roles may need to be partially rewritten to protect sensitive functionality (e.g. network handling code, input handling, parsers, etc.) New projects should choose memory safe languages unless there is simply no other option. >> I don't think there's a clear way to evaluate and compare that risk profile ahead of time for any particular piece of non-trivial code. Sometimes we don't fully understand the problems until we start writing code. It is part of the nature of software development.