> can express your notion of streams with pipes to input files Not if you've disabled syscalls. As it turns out, process isolation is incredibly complex. Milli

> can express your notion of streams with pipes to input files Not if you've disabled syscalls. As it turns out, process isolation is incredibly complex. Millions of lines of code between in kernels and container systems are dedicated to this issue that could be trivially solved with a software based approach, if only files were distributed in a source format. > The insecurity of machine code on Linux is an artifact of OS design providing things like an innate right for processes to access a file system, not anything to do with the machine code This design decision is intimately related to the format in which code is distributed, the linking and loading of ELF files, as well as the compilation of software. Otherwise containerisation would be as simple as giving each process a private file-system. > As soon as you modify that program to operate correctly according to your model it then becomes trivial to precisely provide the same dependencies to the machine code variant as long as your OS supports such abstractions. Okay, so you take some information from the source and add it to the machine code to solve the problem. Let's say another problem comes up and you do that again. The limit of the process is source-based distribution, and maybe some kind of cached IR (similar to what Java does). The more information you add to machine code, the less it resembles machine code. But when you modify the machine code format, you have to modify your operating system, which is wasteful when this problem has been effectively solved in user-space for decades. The argument against this is always "we can modify the OS to achieve the same thing as you could without the OS", which is always true but not exactly useful. Why is it better to implement these things in a complicated way in the operating system? Modern computers are fast enough to JIT compile Java software, so I see no reason to still use binary formats which require all this extra effort. > CPU bugs are extremely rare compared to software bugs You should be comparing to the kind of software bug you are mentioning here. Specifically one where a bit of basically interpreted code that can't even read or write files somehow gains total control over the process its running in. Preventing this is so simple that it just isn't logical for such a bug to exist. You might think it likely because of the frequency of bugs in operating systems that use binary programs, but that is because securing a binary program is much more complicated than securing one which is interpreted. > But, in that case you would expect proof-of-concepts demonstrating feasibility and proven protection in the equivalent, but non-performant model, and only then optimizing the performance by leveraging language-level protections. Until that is done there is precisely zero reason to believe any language-level protections are robust. Well using Haskell as an easy example here, the language is fairly performant, and you know all functions without side-effects are safe. By redefining the IO monad, you can then at a software level control every file access that the program attempts and guarantee that it does nothing malicious at minimal overhead. Obviously if I were implementing a practical version of this, I wouldn't chose Haskell for it, but the point still stands that Haskell proves the feasibility of such a system.