Hacker News Reader

Comment by CyberRabbi | Hacker News Reader

Debating whether things should be in process or out of process just seems so 80s. Ideally everything would just be in a single process. Why are new systems exposing the ability to dereference raw pointers to user programs? There was a brief period in the 00s where it seemed like systems research was moving in the direction of only running safe code, obsoleting the need for hardware isolation. Rust proves it’s possible to do efficiently. One day we’ll get there.

View on HN

Processes provide better security isolation than just language based security (I think that's what you're talking about). For example with Spectre vulnerabilities they only work within a process (at least the original ones).

There are OSes that use the language for safety and have a single process but having to use memory safe languages is a pretty big limitation! Plus I would imagine it is easier to prove process security than language security.

Security was not the goal for software-isolated processes, but performance and getting rid of task-switches. Who knows, maybe this is what MS recently described as "next windows" (naive hope).

While WinDev keeps pushing their C++ agenda that hope is definitly naive.

We have learned that multiprocessing is the only safe path to program stability, ease of scaling across clusters and less security exploits.

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)

Singularity has a C++ microkernel actually.

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.

"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/...

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.

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.

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.

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.

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/

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.

How does hardware isolation solve that issue? SIP's do the same thing...

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?

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.

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.

So SIP's don't change any of that except maybe the possibility of formal verification and easier patching of discovered flaws.

You get similar guarantees to hardware checks with less overhead thats the point.

Either way you're going to want to pay bounties for bugs hardware or software. Security work is never done.

JAAS and CAS where not SIP, I am not sure why you keep trying to conflate them.

Because Singularity is hardly any different from something like SavaJe OS, in what concerns use of type safe programming language as security boundary.

It was abandoned in 2006 and SIP were never validated in production under real attacks.

Even Midori had more real use, having powered Asian Bing subnet for a while.

To worship it in 2021 is just theory without pratical results.

I have concerns about hardware as a security boundary as well, more so lately, as should you I hope and it's much more difficult to patch hardware.

Again Midori used SIP's so it was validated in production, right?

Projecting worship on to me is not productive, no need to be childish about this. All the points you bring up for software isolation exist with hardware isolation, formal verification could help both and there is a lot of work in that area.

I think software needs to become safe by default, the endless buffer overflows need to stop. If you then take the stance user land software must be written in a safe language then the need for hardware isolation might not need to exist in it's current form and thats very interesting to me, thats all.

You are ignoring the remaining 30% of security exploits that safe languages don't protect you from, including SIP.

Which are what? How does hardware isolation protect against them?

> Rust proves it’s possible to do efficiently. One day we’ll get there.

Rust is only memory-safe and only as long as you stay away from unsafe code. It is not magic pixie dust.

What is only running safe code? How could then we build a browser with JIT compilation?

First thing that comes to mind is the approach that Jurassic javascript [1] does using .Net IL generation, run that on a .Net based OS like Singularity [2].

1. https://github.com/paulbartrum/jurassic

2. https://en.wikipedia.org/wiki/Singularity_(operating_system)

Inferno is another example of a system that did not expose the ability to dereference raw pointers to user programs: https://en.m.wikipedia.org/wiki/Inferno_(operating_system)

So just run a different JIT compiler? Also, the Jurassic name is quite funny when talking about security :D

The point is your jitting to an intermediate language thats verified and a system level jit actually turns that into machine code, you are never allowed to write machine code directly to memory and execute.

V8 basically does this internally with its bytecode, if your whole system was built on that bytecode then you can do software isolation rather than hardware.

I don't really agree, as someone who advocates for Rust usage.

> Ideally everything would just be in a single process.

Processes are an amazing boundary, probably the most powerful abstraction in existence.

> Why are new systems exposing the ability to dereference raw pointers to user programs?

This shouldn't be possible today - SMAP/SMEP are standard now.

> obsoleting the need for hardware isolation

I think if the last 3 years (sidechannel frenzy) has taught us anything, it's that software-isolation is extremely difficult. Even hardare isolation is difficult.

> Ideally everything would just be in a single process.

Any real example where this makes sense on an internet-connected device?

JavaScript

Everything in a single process? Assuming that everything running on the computer is benevolent is a very "so 80s" notion.

Rust programmers use unsafe escape hatches all the time BTW.

Software isolation, the subject of my comment, was not common in the 80s. You’re referring to systems that had no isolation at all.

Reply on news.ycombinator.com