4 ms·

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 secu

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?
        SigmundA 5y ago
        SIP are not new, those previous systems you mentioned are a form of them, many shared hardware address space across all processes and relied on the programming language being safe for isolation but they where built in a time when running untrusted code was not really thought about, it was more about not crashing the whole system by accident. SIP are a form of multiprocess designed for safety and stability reducing exploits and potentially scaling across clusters. Singularity and Midori heavily relied on message passing for IPC which would have allowed cluster scale out. These where research projects there was plenty the security work available some of it I linked. Much of the work revolved around verifiability of the code to guarantee no cross process breakout without hardware checks. How do you assert hardware checks can withstand a black hat attack? They obviously haven't been lately.
        pjmlp 5y ago
        By doing what Azure Sphere project has done, paying bounties to researches to actually exploit systems in production, not just theory. JAAS and CAS were also secure until black hats started to look into them, and since they are beyond repair, have now been thrown away, replaced by OS containers and multiprocesses.
CyberRabbi 5y ago
Indeed. The existence of Rust as a safe language without a GC shows that a system that can only run safe code can be as efficient as systems that expose raw hardware. In 90s and 00s they did this with languages similar to Java because low level safe languages weren’t yet invented. If this idea ever resurfaces it will be done with languages similar to rust and will be competitive with and likely more efficient than unsafe systems. This will potentially be a nice convergence with power-efficient RISCV chips that don’t include an MMU or a supervisor mode.

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?
      - SigmundA 5y ago
        SIP are not new, those previous systems you mentioned are a form of them, many shared hardware address space across all processes and relied on the programming language being safe for isolation but they where built in a time when running untrusted code was not really thought about, it was more about not crashing the whole system by accident. SIP are a form of multiprocess designed for safety and stability reducing exploits and potentially scaling across clusters. Singularity and Midori heavily relied on message passing for IPC which would have allowed cluster scale out. These where research projects there was plenty the security work available some of it I linked. Much of the work revolved around verifiability of the code to guarantee no cross process breakout without hardware checks. How do you assert hardware checks can withstand a black hat attack? They obviously haven't been lately.
        pjmlp 5y ago
        By doing what Azure Sphere project has done, paying bounties to researches to actually exploit systems in production, not just theory. JAAS and CAS were also secure until black hats started to look into them, and since they are beyond repair, have now been thrown away, replaced by OS containers and multiprocesses.

CyberRabbi 5y ago

Indeed. The existence of Rust as a safe language without a GC shows that a system that can only run safe code can be as efficient as systems that expose raw hardware. In 90s and 00s they did this with languages similar to Java because low level safe languages weren’t yet invented. If this idea ever resurfaces it will be done with languages similar to rust and will be competitive with and likely more efficient than unsafe systems. This will potentially be a nice convergence with power-efficient RISCV chips that don’t include an MMU or a supervisor mode.