6 ms·

You still have processes, they just are software isolated rather than hardware isolated. You write everything in a language that can guarantee no unsafe behavio

You still have processes, they just are software isolated rather than hardware isolated. You write everything in a language that can guarantee no unsafe behavior then no hardware checks are needed or any task switching and most of the safety checks are done at compile time: https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system)

pjmlp 5y ago
Singularity has a C++ microkernel actually. https://github.com/lastweek/source-singularity/tree/master/base/Kernel/Native https://github.com/lastweek/source-singularity/tree/master/b... Microsoft and Oracle have removed CAS and JAAS from CLR/JVM respectively as they have failed to provided the software isolated model that was expected from them.
- SigmundA 5y ago
  "The lowest-level x86 interrupt dispatch code is written in assembly language and C. Once this code has done its job, it invokes the kernel, which runtime system and garbage collector are written in Sing# (an extended version of Spec#, itself an extension of C#) and runs in unprotected mode. The hardware abstraction layer is written in C++ and runs in protected mode." The point is that drivers and apps are managed code and can be software isolated, obviously some of the kernel is unsafe. CAS was fined grain runtime model that added significant overhead and was never close to being verified, software isolation was coarse grained just like a hardware process and had much less overhead with the goal of verification, more here: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/EuroSys2007_SealedProcesses.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
  - pjmlp 5y ago
    Software isolation can still be exploited thanks to logical bugs, this was the whole issue with security exploits in Java applets. Hence why there is really no alternative to multi-processes for security critical code. You refer to Singularity, yet after Singularity, Microsoft Research was went down the path of exploriing other alternatives. If the security model was so great, they would have doubled down on it. Instead, after so many interactions, the main researchers have come out with Azure Sphere, which uses C (!) with a custom Linux kernel, and all the security layers are enforced via hardware.
    - SigmundA 5y ago
      Hardware isolation can be exploited due to bugs too and have been quite a bit lately so the alternative doesn't solve that problem. Conflating Java applet security with software isolated processes as implemented in Singularity is not doing a service to the research work done there. Much of the SIP design was in response to the lessons learned in Java and .Net. The problem with SIP is everything to be isolated must be written in a managed language. That means everyone has to get on board with a managed runtime most likely GC'd. At one point MS thought they could get everyone on board to .Net but at some point they realized that wasn't going to happen and decided its better to go with the status quo of C/C++ development. Maybe we will see a resurgence of SIP with Rust or Webassembly. The idea of verifiably safe code where all safety checks are done ahead of time by the compiler has many advantages that can't be ignored forever.
      - pjmlp 5y ago
        I still fail to see your point, because Sing# also allowed for unsafe code, plus those designs were not adopted in Midori, nor Barrelfish. Plus SIP as managed OS aren't that different from Mesa/Cedar, Lisp Machines, Smalltalk, Oberon. Modula-3. Yes, the overrall security is way better than C and its descendants, but that doesn't make it fullproof.
        SigmundA 5y ago
        The GC was written in an unsafe dialect of Sing#, again app code was not allowed to be unsafe which allowed software rather than hardware isolation. Also Midori used SIP's see "Execution Model" here: http://joeduffyblog.com/2015/11/19/asynchronous-everything/ http://joeduffyblog.com/2015/11/19/asynchronous-everything/
        pjmlp 5y ago
        I am more interested in papers proving that SIPs aren't able to be exploited via logic errors attacks, like it happened in Java Applets due to logic errors on the serialisation library.

pjmlp 5y ago

Singularity has a C++ microkernel actually. https://github.com/lastweek/source-singularity/tree/master/base/Kernel/Native https://github.com/lastweek/source-singularity/tree/master/b... Microsoft and Oracle have removed CAS and JAAS from CLR/JVM respectively as they have failed to provided the software isolated model that was expected from them.

SigmundA 5y ago
"The lowest-level x86 interrupt dispatch code is written in assembly language and C. Once this code has done its job, it invokes the kernel, which runtime system and garbage collector are written in Sing# (an extended version of Spec#, itself an extension of C#) and runs in unprotected mode. The hardware abstraction layer is written in C++ and runs in protected mode." The point is that drivers and apps are managed code and can be software isolated, obviously some of the kernel is unsafe. CAS was fined grain runtime model that added significant overhead and was never close to being verified, software isolation was coarse grained just like a hardware process and had much less overhead with the goal of verification, more here: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/EuroSys2007_SealedProcesses.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
- pjmlp 5y ago
  Software isolation can still be exploited thanks to logical bugs, this was the whole issue with security exploits in Java applets. Hence why there is really no alternative to multi-processes for security critical code. You refer to Singularity, yet after Singularity, Microsoft Research was went down the path of exploriing other alternatives. If the security model was so great, they would have doubled down on it. Instead, after so many interactions, the main researchers have come out with Azure Sphere, which uses C (!) with a custom Linux kernel, and all the security layers are enforced via hardware.
  - SigmundA 5y ago
    Hardware isolation can be exploited due to bugs too and have been quite a bit lately so the alternative doesn't solve that problem. Conflating Java applet security with software isolated processes as implemented in Singularity is not doing a service to the research work done there. Much of the SIP design was in response to the lessons learned in Java and .Net. The problem with SIP is everything to be isolated must be written in a managed language. That means everyone has to get on board with a managed runtime most likely GC'd. At one point MS thought they could get everyone on board to .Net but at some point they realized that wasn't going to happen and decided its better to go with the status quo of C/C++ development. Maybe we will see a resurgence of SIP with Rust or Webassembly. The idea of verifiably safe code where all safety checks are done ahead of time by the compiler has many advantages that can't be ignored forever.
    - pjmlp 5y ago
      I still fail to see your point, because Sing# also allowed for unsafe code, plus those designs were not adopted in Midori, nor Barrelfish. Plus SIP as managed OS aren't that different from Mesa/Cedar, Lisp Machines, Smalltalk, Oberon. Modula-3. Yes, the overrall security is way better than C and its descendants, but that doesn't make it fullproof.
      - SigmundA 5y ago
        The GC was written in an unsafe dialect of Sing#, again app code was not allowed to be unsafe which allowed software rather than hardware isolation. Also Midori used SIP's see "Execution Model" here: http://joeduffyblog.com/2015/11/19/asynchronous-everything/ http://joeduffyblog.com/2015/11/19/asynchronous-everything/
        pjmlp 5y ago
        I am more interested in papers proving that SIPs aren't able to be exploited via logic errors attacks, like it happened in Java Applets due to logic errors on the serialisation library.