| > Everything that matters is I/O and this goes through syscalls, so there security can be enforced. I don't think "good" I/O and "bad" I/O are necessarily distinguishable by the OS ahead of time and/or in general. The OS isn't going to know whether the program wrote out a proper file or complete gibberish, or whether the numbers you're displaying were derived from uninitialized values, or whether what you're sending over the wire is what you intended (e.g., Heartbleed), etc., but those are very much things one should care about! > Why do you care about corrupting process memory? The memory state itself is totally irrelevant. Strong disagree here. If memory is corrupted all bets are off, especially if you know your program is actually supposed to perform some I/O. > The only thing that matters is the deletion of the file, you don't actually care about the memory safety. You would care if memory safety issues directly led to file deletion! > Thus, what you actually want is the computer to know that the file is not supposed to be deleted, when you have that, the memory can be trashed like the program likes to. So what happens if you know a file is supposed to be deleted but memory corruption led to the wrong one being deleted? |