Hi - On Sun, Mar 02, 2008 at 09:30:25AM -0500, Robert Dewar wrote:
> [...] Safety-critical and security-critical software are two > totally different concepts. Be careful not to confuse them. In > safety-critical software, e.g. avionics system, it is not acceptable > for the system to crash. In this context, the metaphorical "better > to die", becomes all too real! (Off topic, but I'd expect that avionics software is engineered with enough layers of protection, including catching traps, so that a -ftrapv hit would not cause a deep impact.) > [...] However, in practice, it is hard to imagine a > security-critical piece of software that would not take equal care > to avoid any possibility of exceptional conditions at run time. Maybe, but we just don't live in that world. > For general security issues, especially with type unsafe languages, > anything you can do at run-time to increase type safety certainly > helps. Right, but gcc's approach is unsympathetic. With -fstrict-overflow becoming default in the usual "-O2 -g" builds, latent signed-overflow bugs might become even harder to find. It's as if GCC is sending the a message like "Security is your problem - we favour 100% Pure C Code.". > However, I would suspect that -ftrapv is likely to be viewed and > used only as a debugging aid in C, rather than something you > routinely deploy in delivered software to improve security. I guess it depends on how robust (=> predictable to experts) the mechanism becomes. The glibc fortify widget (enabled by some robust gcc extensions) has found lots of use. - FChE
