4 ms·

> Any non-free standing program running on a modern OS on modern hardware trying to access memory its not supposed to will be killed by the OS. This seems like

> Any non-free standing program running on a modern OS on modern hardware trying to access memory its not supposed to will be killed by the OS. This seems like a rather strong statement to me. Do you mind elaborating further?

1718627440 1y ago
I think bugs in the MMU hardware or the kernel accidentally configuring the MMU to allow access across processes that isn't supposed to be are quite rare.
- aw1621107 1y ago
  Sure, but I think illegal interprocess memory accesses is a fairly narrow definition for "access[ing] memory its not supposed to". There's plenty of undesirable memory accesses that are possible without needing to cross process boundaries and I don't think the OS does that much to solve those outside of currently niche hardware.
  - 1718627440 1y ago
    It might be undesirable to you, but you haven't specified this to the computer. Process-boundaries are one way how we specify what is allowed to touch and what not.
    - aw1621107 1y ago
      OK, sure, but there's no reason you can't extend that argument to in-process improper memory accesses either. free() is you specifying that a particular bit of memory isn't supposed to be touched any more, malloc() is you specifying that some amount of memory is legal to access, etc. Language runtimes, inserted/compile-time checks, etc. would be analogous to the OS/MMU here.
      - 1718627440 1y ago
        Yes, but this is not across a trust boundary. Since these are in the same process/program. Rust "only" applies checks at compile time, it doesn't enforce security. Not sure, if I'm clear. Rust is like cooperative multitasking, nice but not guaranteed. My claim here is, that we actually want preemptive multitasking.
        aw1621107 1y ago
        I'm not quite sure I'm understanding your analogy here, but would that effectively mean each allocation lives in its own process?
        1718627440 1y ago
        Maybe? If we try to backport it to the current hardware/software. It would be an improvement to configure the MMU to enforce boundaries below a process. However my point was that not every allocation is a trust boundary. What a program does in its own memory doesn't matter at all, this is gone in an instant. Everything that matters is I/O and this goes through syscalls, so there security can be enforced. Why do you care about corrupting process memory? The memory state itself is totally irrelevant. What annoys you is when it e.g. deletes a file it is not supposed to. Would you rejoice when the file gets still deleted, but the process memory is totally fine? Of course not. The only thing that matters is the deletion of the file, you don't actually care about the memory safety. 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.
        aw1621107 1y ago
        > 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?

1718627440 1y ago

I think bugs in the MMU hardware or the kernel accidentally configuring the MMU to allow access across processes that isn't supposed to be are quite rare.

aw1621107 1y ago
Sure, but I think illegal interprocess memory accesses is a fairly narrow definition for "access[ing] memory its not supposed to". There's plenty of undesirable memory accesses that are possible without needing to cross process boundaries and I don't think the OS does that much to solve those outside of currently niche hardware.
- 1718627440 1y ago
  It might be undesirable to you, but you haven't specified this to the computer. Process-boundaries are one way how we specify what is allowed to touch and what not.
  - aw1621107 1y ago
    OK, sure, but there's no reason you can't extend that argument to in-process improper memory accesses either. free() is you specifying that a particular bit of memory isn't supposed to be touched any more, malloc() is you specifying that some amount of memory is legal to access, etc. Language runtimes, inserted/compile-time checks, etc. would be analogous to the OS/MMU here.
    - 1718627440 1y ago
      Yes, but this is not across a trust boundary. Since these are in the same process/program. Rust "only" applies checks at compile time, it doesn't enforce security. Not sure, if I'm clear. Rust is like cooperative multitasking, nice but not guaranteed. My claim here is, that we actually want preemptive multitasking.
      - aw1621107 1y ago
        I'm not quite sure I'm understanding your analogy here, but would that effectively mean each allocation lives in its own process?
        1718627440 1y ago
        Maybe? If we try to backport it to the current hardware/software. It would be an improvement to configure the MMU to enforce boundaries below a process. However my point was that not every allocation is a trust boundary. What a program does in its own memory doesn't matter at all, this is gone in an instant. Everything that matters is I/O and this goes through syscalls, so there security can be enforced. Why do you care about corrupting process memory? The memory state itself is totally irrelevant. What annoys you is when it e.g. deletes a file it is not supposed to. Would you rejoice when the file gets still deleted, but the process memory is totally fine? Of course not. The only thing that matters is the deletion of the file, you don't actually care about the memory safety. 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.
        aw1621107 1y ago
        > 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?