The software layer for memory protection here is the AOT compiler. As you alluded to yourself, if Mark Dowd finds one of the bugs in your AOT compiler, then you are toast.
The nice thing is that these protections can be applied ahead-of-time rather than at runtime, as the MMU does.
It has been shown (see Native Client) that even a slightly restricted subset of x86 assembler can be made verifiably-safe. In principle, you could do the same thing with C - in fact, you likely wouldn't even have to change the language definition, since the egregious abuses in C mostly result in "undefined behaviour", which allows the implementation to detect and trap them rather than hose the machine. (It is a curious fact that C itself isn't inherently "memory unsafe" - merely almost every implementation of C ever written is).
People have attempted to make C memory safe (i.e. bitc, cyclone), so you could write an OS in that, I guess. My original point however was that C itself is not, and that supporting C means supporting non-memory safe drivers, services, and programs.
If you can come up with a program that verifies whether a C program is memory safe or not (without constraining the language spec), well, hats off to you sir, I think I know a couple of security experts who might want to have a word with you :)
The nice thing is that these protections can be applied ahead-of-time rather than at runtime, as the MMU does.
It has been shown (see Native Client) that even a slightly restricted subset of x86 assembler can be made verifiably-safe. In principle, you could do the same thing with C - in fact, you likely wouldn't even have to change the language definition, since the egregious abuses in C mostly result in "undefined behaviour", which allows the implementation to detect and trap them rather than hose the machine. (It is a curious fact that C itself isn't inherently "memory unsafe" - merely almost every implementation of C ever written is).