Hacker News Reader

Comment by josephg | Hacker News Reader

Something I keep coming back to in all this is that maybe we should be surprised that it’s even possible to share a CPU between mutually untrusted programs, let alone do it in so many contexts.

How do we stop his entire class of bugs? What is the Rust for CPU design?

View on HN

CPUs tend to have multiple cores these days, would it be possible to assign (in software) all kernal space work to one or more dedicated cores to mitigate some of the risks?

With a shared cache.

Some of the newer Intel server CPUs allow statically partitioning the shared L3 cache between cores. It might (or not) work as a way to reduce side channel communications between cores.

Yes, well, close.

> Since the 2010 Westmere microarchitecture Intel 64 processors also support 12-bit "process-context identifiers" (PCIDs), which allow retaining TLB entries for multiple linear-address spaces, with only those that match the current PCID being used for address translation.[19][20]

https://en.wikipedia.org/wiki/Translation_lookaside_buffer#P...

HN discussion: https://news.ycombinator.com/item?id=16094349

That's just Meltdown workaround.

Spectre was more relevant to context.

I always liked the https://en.wikipedia.org/wiki/J%E2%80%93Machine idea: gobs of processors each with a small private memory (nothing shared), in a fast mesh network. It fits with physics: accessing local memory can be fast, while distant memory physically just can't. But even if it's really all that, it's just so different from the architectures we've put so much work into or on top of.

That sounds like a more extreme version of what the Cell[1] was supposed to be. Developers seemed to think that developing for that architecture was really painful, specially compared to other contemporary console platforms. I'd love it if the progress being made in the industry got us to actually being able to exploit the full potential of such architectures.

[1]: https://en.wikipedia.org/wiki/Cell_(microprocessor)

It was painful - mostly because we don't have good tools for that sort of thing and most of our programming sort of hides the idea of multiple CPUs and pretends it's all working at once (in terms of us writing the code anyhow).

It's all abstracted in a very linear way.

Changing all that will take a lot of time if we do.

Actually multiple CPUs are not normally hidden in mainstream programming languages [1]: i.e. threads are visible. The fiction that it is maintained by the programming languages and hardware is that of a single, coherent address space, which Cell very much did not have.

[1] outside of parallel iteration/folding constructs.

Yeah. Erlang seems to show that there is a path from here to there, but the Erlang-ish world is tiny relative to the whole industry.

> I'd love it if the progress being made in the industry got us to actually being able to exploit the full potential of such architectures.

If they had ever released it as a general purpose computer instead of a locked down game console people could've experimented with it enough to unlock its full potential.

If they were smart they'd dust off the old chips, throw them on a RasberryPi type system and laugh all the way to the bank.

There were PCI-Express cards with Cells on them, for numbercrunching or something. These even used the "good" Cells with full 64-bit floating point numbers needed for scientific workloads.

I vaguely remember that the price tag I saw was so outrageous I can understand why that didn't go anywhere.

Would have been interesting, though, I agree.

> What is the Rust for CPU design?

Intel iAPX 432 could have been it, but they did a lousy job implementing it.

https://en.wikipedia.org/wiki/Intel_iAPX_432

Yes, we need a many-core CPU. Then every program can run on a core. And we can use MPI, CILK, etc to run parallel programs. Each CPU could run its own small operating system, or using a micro kernel OS.

Writing algorithms in parallel manner isn't as complicated as make to believe you, a lot can be rewritten based on cookbooks/patterns.

Intel developed a many-core CPU (72 CPU cores) called Xeon Phi: https://en.wikipedia.org/wiki/Xeon_Phi

Unfortunately they drifted of the target (instead of making it the successor of x86-64).

For Javascript engines, it would help if the offer an optional fallback "Javascript interpreter" instead of JIT. A JIT is basically at the moment insecure, especially when running untrusted code. The same goes for WebAssembly, let the user deactivate execution/support of it. Please allow end user to enable an alternative JS interpreter for high security things like online banking.

Well, Meltdown mitigation involves unmapping as much Kernel as possible when switching modes. It’s so much overhead that I wonder if uK messaging and process context switching is cheaper and faster.

Interpreters generally do a lot of branches, so they are also vulnerable to Spectre.

Reply on news.ycombinator.com