4 ms·

AFAIK, TempleOS seems to be the only operating system running everything in supervisor mode. I wonder what would happen if we can find a way to build software

AFAIK, TempleOS seems to be the only operating system running everything in supervisor mode. I wonder what would happen if we can find a way to build software protection in supervisor mode, ditching user mode and associated context switches.

zozbot234 6y ago
MS-DOS did the same, as do most embedded OS's today. Separate address spaces are definitely needed these days in order to avoid Spectre vulnerabilities, but that's only an information disclosure concern. Ideally, OS's would explicitly support information protection domains (after all, this is already a feature in some niche, specialized OS's) and only sensitive info/data would be protected by a switch to a different protection domain. Most user tasks which deal entirely with non-critical data could simply run in a shared address space.
- qayxc 6y ago
  > Separate address spaces are definitely needed these days in order to avoid Spectre vulnerabilities That's nonsense! Separate address spaces have nothing to do with hardware vulnerabilities. The MMU uses address spaces to isolate processes from each other, which is required for proper multi-tasking. If you don't use process isolation, every task can overwrite the heap and stack of every other running task (including the OS kernel and drivers!). Information disclosure (in this context) is only relevant in virtual environments, where multiple tenants have to be strictly isolated from each other and affects (hardware) VM supervisors. It's a different topic entirely.
  - zozbot234 6y ago
    > If you don't use process isolation, every task can overwrite the heap and stack of every other running task (including the OS kernel and drivers!). This is not a concern if all code is rigorously checked for memory safety which is quite feasible in principle, and possibly already the case for some uses of WASM/WASI. (Native binary code would need to be annotated with low-level proofs, to be checked by the OS.)
    - qayxc 6y ago
      Right. That's why no sandbox has ever been broken... So no. WASM relies on process isolation like every other system. It's impossible to automatically check memory safety at compile time as that implies solving the Halting Problem. Runtime checks would need to rely on the compiler enforcing these checks in the RTL. This, however, can easily circumvented using return-oriented programming (remember: you don't want the MMU to protect stack spaces). No amount of software-based sandboxing or compile-time checks can effectively prevent non-isolated processes from accessing and corrupting each other's state. That's exactly why MMU were introduced in the first place. Experiments using Software-Isolated Processes like Microsoft's Singularity [1] rely on complete toolchains from OS kernel to "safe" languages and runtimes and are not suitable for every requirement (e.g. hard real-time becomes near impossible). The SIP concept also just shifts the burden of proving correctness from app and system developers to compiler and toolchain developers and we all know that those guys never make mistakes ;) [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/osr2007_rethinkingsoftwarestack.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
      - zozbot234 6y ago
        I agree that current sandboxes and even current compilers/toolchains do not provide these rigorous guarantees, as of yet. WASM/WASI is however quite simple, and could thus be up to the challenge. It's certainly simpler than MS's Singularity approach.
        qayxc 6y ago
        Singularity just was a PoC, though. I'm not saying it can't be done, it's just not practical for every use case.
      - jfkebwjsbx 6y ago
        > It's impossible to automatically check memory safety at compile time as that implies solving the Halting Problem. For the general case, yeah. And while I agree that I would not remove process isolation, I think they have a point about "almost guaranteed to be safe" languages could be potentially used without isolation (not with zero risk, of course).
  - josefx 6y ago
    > If you don't use process isolation, every task can overwrite the heap and stack of every other running task We have a lot of modern languages that are memory safe at least in theory. However quite a few rely on the OS using these safety features in the background. For example the Java Runtime uses segfaults to catch null pointers instead of actively checking for them, at least as far as I remember.
cturner 6y ago
Agree this is interesting, and user mode looks like legacy for some major domains. For example, if you are building a grid computer, you don't need mechanisms that were designed to protect university students from one another. Consider if everything is driven from a single codebase. Your type system can provide protections that have traditionally been done by the kernel. I am currently playing with this. Have a boot loader up, and a handoff to c++. Today I am looking at page-management. There are some interesting trade-offs that come from unconventional approaches like this. For example, I have read that if you make SIMD registers available to the kernel, it hurts the performance of context-switching. (https://os.phil-opp.com/minimal-rust-kernel/ https://os.phil-opp.com/minimal-rust-kernel/) A mitigation I am considering: do all interrupt handling on one core, and then have all other cores for work-processing. Use channels to communicate between the burnt interrupt core and the worker cores. Downside of this: worker cores would need to poll for new messages. In low-activity periods, I could slow the poll interval. I would be interested to hear from anyone who has gone deep on this, or knows of papers.
- dirtydroog 6y ago
  Technologies such as DPDK are designed to get the kernel out of the way. For some applications it has no reason to play a part once the system has booted, it's just an overhead. For what you're doing I recall reading about IncludeOS[1] which seems to have similar goals [1] https://www.includeos.org https://www.includeos.org
  - cturner 6y ago
    Thanks for the reference to includeos. They do seem to have built something in the spirit of what I have been looking into.
smokeyfish 6y ago
God mode

zozbot234 6y ago

MS-DOS did the same, as do most embedded OS's today. Separate address spaces are definitely needed these days in order to avoid Spectre vulnerabilities, but that's only an information disclosure concern. Ideally, OS's would explicitly support information protection domains (after all, this is already a feature in some niche, specialized OS's) and only sensitive info/data would be protected by a switch to a different protection domain. Most user tasks which deal entirely with non-critical data could simply run in a shared address space.

qayxc 6y ago
> Separate address spaces are definitely needed these days in order to avoid Spectre vulnerabilities That's nonsense! Separate address spaces have nothing to do with hardware vulnerabilities. The MMU uses address spaces to isolate processes from each other, which is required for proper multi-tasking. If you don't use process isolation, every task can overwrite the heap and stack of every other running task (including the OS kernel and drivers!). Information disclosure (in this context) is only relevant in virtual environments, where multiple tenants have to be strictly isolated from each other and affects (hardware) VM supervisors. It's a different topic entirely.
- zozbot234 6y ago
  > If you don't use process isolation, every task can overwrite the heap and stack of every other running task (including the OS kernel and drivers!). This is not a concern if all code is rigorously checked for memory safety which is quite feasible in principle, and possibly already the case for some uses of WASM/WASI. (Native binary code would need to be annotated with low-level proofs, to be checked by the OS.)
  - qayxc 6y ago
    Right. That's why no sandbox has ever been broken... So no. WASM relies on process isolation like every other system. It's impossible to automatically check memory safety at compile time as that implies solving the Halting Problem. Runtime checks would need to rely on the compiler enforcing these checks in the RTL. This, however, can easily circumvented using return-oriented programming (remember: you don't want the MMU to protect stack spaces). No amount of software-based sandboxing or compile-time checks can effectively prevent non-isolated processes from accessing and corrupting each other's state. That's exactly why MMU were introduced in the first place. Experiments using Software-Isolated Processes like Microsoft's Singularity [1] rely on complete toolchains from OS kernel to "safe" languages and runtimes and are not suitable for every requirement (e.g. hard real-time becomes near impossible). The SIP concept also just shifts the burden of proving correctness from app and system developers to compiler and toolchain developers and we all know that those guys never make mistakes ;) [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/osr2007_rethinkingsoftwarestack.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
    - zozbot234 6y ago
      I agree that current sandboxes and even current compilers/toolchains do not provide these rigorous guarantees, as of yet. WASM/WASI is however quite simple, and could thus be up to the challenge. It's certainly simpler than MS's Singularity approach.
      - qayxc 6y ago
        Singularity just was a PoC, though. I'm not saying it can't be done, it's just not practical for every use case.
    - jfkebwjsbx 6y ago
      > It's impossible to automatically check memory safety at compile time as that implies solving the Halting Problem. For the general case, yeah. And while I agree that I would not remove process isolation, I think they have a point about "almost guaranteed to be safe" languages could be potentially used without isolation (not with zero risk, of course).
- josefx 6y ago
  > If you don't use process isolation, every task can overwrite the heap and stack of every other running task We have a lot of modern languages that are memory safe at least in theory. However quite a few rely on the OS using these safety features in the background. For example the Java Runtime uses segfaults to catch null pointers instead of actively checking for them, at least as far as I remember.

cturner 6y ago

Agree this is interesting, and user mode looks like legacy for some major domains. For example, if you are building a grid computer, you don't need mechanisms that were designed to protect university students from one another. Consider if everything is driven from a single codebase. Your type system can provide protections that have traditionally been done by the kernel. I am currently playing with this. Have a boot loader up, and a handoff to c++. Today I am looking at page-management. There are some interesting trade-offs that come from unconventional approaches like this. For example, I have read that if you make SIMD registers available to the kernel, it hurts the performance of context-switching. (https://os.phil-opp.com/minimal-rust-kernel/ https://os.phil-opp.com/minimal-rust-kernel/) A mitigation I am considering: do all interrupt handling on one core, and then have all other cores for work-processing. Use channels to communicate between the burnt interrupt core and the worker cores. Downside of this: worker cores would need to poll for new messages. In low-activity periods, I could slow the poll interval. I would be interested to hear from anyone who has gone deep on this, or knows of papers.

dirtydroog 6y ago
Technologies such as DPDK are designed to get the kernel out of the way. For some applications it has no reason to play a part once the system has booted, it's just an overhead. For what you're doing I recall reading about IncludeOS[1] which seems to have similar goals [1] https://www.includeos.org https://www.includeos.org
- cturner 6y ago
  Thanks for the reference to includeos. They do seem to have built something in the spirit of what I have been looking into.

smokeyfish 6y ago

God mode