4 ms·

"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 syste

"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.
        SigmundA 5y ago
        How does hardware isolation solve that issue? SIP's do the same thing...
        pjmlp 5y ago
        SIPs don't do nothing for "We have learned that multiprocessing is the only safe path to program stability, ease of scaling across clusters and less security exploits." Which was my whole point since the beggining. Yeah SIPs are nice, hardly any different from other managed OSes since the 60's, with Burroughs being the first one. Many of those actually were used in production, while Singularity never left the crib, it died on version 2.0 with nothing more than a CLI interface. Then everyone moved into other projects, hardly any security assessement was done to the whole stack, so how can you assert SIP capabilities to withstand a black hat attack?

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.
      - SigmundA 5y ago
        How does hardware isolation solve that issue? SIP's do the same thing...
        pjmlp 5y ago
        SIPs don't do nothing for "We have learned that multiprocessing is the only safe path to program stability, ease of scaling across clusters and less security exploits." Which was my whole point since the beggining. Yeah SIPs are nice, hardly any different from other managed OSes since the 60's, with Burroughs being the first one. Many of those actually were used in production, while Singularity never left the crib, it died on version 2.0 with nothing more than a CLI interface. Then everyone moved into other projects, hardly any security assessement was done to the whole stack, so how can you assert SIP capabilities to withstand a black hat attack?