5 ms·
I don't see compiler writers being thrilled by having to harden the entire compiler toolchain against actively malicious input. And there would be no way to ver
by infogulch 10y ago
I don't see compiler writers being thrilled by having to harden the entire compiler toolchain against actively malicious input. And there would be no way to verify the binary by itself, you'd have to have every binary built on and signed by a trusted build server. Oh, and now any binary built with a compiler that has bugs can now compromise the entire OS.
No, if you want to keep security you need some kind of external memory protection system. Memory isolation gives that and takes away performance. Mill gives both.
- elihu 10y agoYou're right, compiler writers wouldn't want to be responsible for system security in the same way that OS kernel authors are now, and commercial closed-source software doesn't fit well with the scheme I describe. If Mill can drop the cost of context switches down to the point where they're indistinguishable from function calls, then that's pretty awesome and it would presumably work well with the software we have now, which is a strong point in its favor. (I haven't seen any Mill talks about security/memory protection, so I don't know what the implementation details are.) I'm just trying to make the point that reducing the cost of context switches isn't the only solution, and that we could eliminate context switches altogether by making different tradeoffs. I think both approaches are promising and will appeal to different audiences.
- gpderetta 10y ago> And there would be no way to verify the binary by itself. Doesn't Java do exactly that?
- infogulch 10y agoNo, the JVM provides security in this scenario by being the trusted compiler and inserting memory safety checks itself.