Reply To: ASLR (security)

By “well-structured” I mean “a structure that would be secure on a non-Mill”, typically through use of processes where a Mill would use services.

In this context your login example is poorly structured. On a conventional machine, the exploit can be eliminated by putting the password checker/secret keeper in a separate process that records and returns (via IPC) a pass/fail boolean. The (buggy) UI can suffer buffer overwrite and be arbitrarily perverted by the attacker, but the keeper cannot be because it is getting its arguments via IPC rather than via read().

This well-structured and secure, but expensive and inconvenient on a conventional. The same basic strategy can be applied to any app on any machine: put threat-facing code in one protection domain and secret-keeping code in another, and use a trusted interface (IPC on a conventional, portal calls on a Mill) to communicate between them.

I’m well aware of the exploits you describe, but don’t feel they are an argument for ASLR. ASLR does not prevent such exploits, merely makes them more difficult; good structure prevents them and makes ASLR pointless. The reason why major software (like browsers) is not well structured is cost, in performance and convenience. That’s the same reason that people write passwords on Post-its. The Mill lowers the cost of good structure; we’re still working on the Post-its.