Hacker News Reader

Comment by 0x0 | Hacker News Reader

The linked paper contains a quote and a reference to Microsoft Singularity that really is an interesting thought experiment. Imagine we were all running next-gen systems designed like Singularity by now, which relies on type safety and managed code instead of memory protection to provide application level security. Spectre would have been a lot more devastating then, if we couldn't have hardware-assisted virtual memory protection separating processes from each other?

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

View on HN

Mark Aiken wrote a paper on Singularity with and and without Memory Protection:

https://www.microsoft.com/en-us/research/publication/deconst...

By design, Singularity didn't support dynamic code loading so untrusted code would run in another software isolated process (SIP) and separated by a channel boundary (IPC). With Spectre, you'd need to rethink what happens with IPC to and fro the untrusted processes. The core of the system wouldn't need this though.

Singularity also looked to proof carrying code as a way of building reliable systems. Unfortunately, it'd be hard to prove there isn't a Spectre style attack lurking in a piece of code.

Even if the untrusted code is in another SIP, if it was susceptible to Spectre you'd be able to break down that boundary.

In Singularity, the system gets to decide what happens at SIP boundaries (and the kernel ABI boundary).

HIP is the full address space change, but any mitigation steps can be introduced in the IPC hand-off between SIPs (or at the kernel ABI) compiled into the untrusted process. This code is compiler controlled. The system is in ring-0 so IPC code gets full access to available instructions (such as mitigation is possible there).

Of course doing this makes channel communication in both directions slow for untrusted processes, but that is the cost of doing business with Spectre. And if someone wrote a browser that didn't use channels for talking to the JS engine, then all bets would be off.

With Spectre, malicious processea doesn't need to have code execution cross a SIP boundary in order to break confidentiality of other colocated SIPs. As a malicious SIP, I can just read out the rest of the hardware visible context.

How does the hardware visible context get suitably updated if the confidential data in the other SIP isn't touched by execution (speculative or otherwise)? Doesn't something need to be pulling that state into the visible context?

As far as the hardware is concerned, the confidential information in the other SIP is already visible.

This was stupid comment, long day. Totally looking at this the wrong way.

Singularity heavily relies on capabilities. What if accessing the current wall clock time was a zealously guarded capability? I wonder what percentage of apps could function with no access to (real time) timers at all, or an extremely granular one?

I can't find a link at the moment, but I recall a paper showing even a very granular clock will suffice for Spectre exploits, albeit with lower bandwidth. Also, something else would need to be done about multithreading, as an application could always just spin up another thread counting as fast as it can to make a poor man's timer.

> I can't find a link at the moment, but I recall a paper showing even a very granular clock will suffice for Spectre exploits, albeit with lower bandwidth.

The linked article mentions this and the linked paper gives some references: https://gruss.cc/files/fantastictimers.pdf

I may be wrong, but isn't there an almost unlimited amount of ways that you could determine wallclock time?

Any kind of networking access can get it (with enough samples, you can get some crazy precision over even the most inconsistent networks), and really any kind of I/O could be abused when combined with another exploits.

And if your permissions system doesn't allow I/O, is there really a lot that your program can do?

You don't even need networking. If you can create a temp file, you can probably get the creation or modified time on the file.

Hell, you can make a passable timer for these purposes as long as you have two threads. No need to leave your process.

Singularity also let you use hardware protection in addition to SIPs. Basically it let you map a set of SIPs to a hardware domain.

Reply on news.ycombinator.com