Secure Modular Runtimes | Hacker News Reader

Secure Modular Runtimes

guybedford.com

43 pointsispivey9 comments

This is an excellent, in-depth and thoughtful article. I'd say the only thing it omits, and I do think is crucial, is not using X where X is unnecessary. You can close a lot of security holes just by doing that. Still a great read.

Spectre seems serious. Even the E family of languages (E, Monte, Joule, Grace), which have similar lineage to ECMAScript but have always been focused on isolation, don't have ready answers for how to mitigate Spectre and related attacks.

I think that hardware-effect attacks are going to be the primary thorn in our side for the next few decades, even if we all agree to switch to object-capability systems immediately.

Guy's arguing that there are still benefits to applying security boundaries within execution envs which are vulnerable to spectre memory reads since it would limit the ability to exfiltrate. (There was a variant which could write to memory as well [1].) There was some discussion on twitter about this which I found interesting [2].

1 https://arxiv.org/abs/1807.03757v1

2 https://twitter.com/domenic/status/1298045068633407490

Definitely agree that we should switch to object-capability systems.

Also, both hardware and software could be hardened through formal verification. Usually the focus is software, but given the recently exposed flaws, hardware verification seems sorely needed.

Standardizing on ECC memory and encrypted memory would help. Looks like encrypted memory is happening on all new x86 business-focused processors, but ECC is still far too uncommon which means RowHammer is still an issue.

And greatly simplified instruction sets would help, but that is probably the least likely to happen.

> could be hardened through formal verification

Yeah... but that only works by you verifying your assumptions. If your assumptions are wrong, you remain screwed. I'm all for it but it's not perfection.

AIUI spectre is pretty much unrelated to this. The article is mainly about securing JS. Spectre allows sidestepping anything. The only point where spectre and capabilities touch, that I can see, is

"The second thing to note here is that if you have a true capability system and can carefully control network access, then the capability to exfiltrate (basically to use fetch), can itself be treated as a critical permission. Secrets might be discovered but not as easily shared"

which is a very interesting point.

Read again, but from the other side of the looking-glass; imagine that you have a bunch of code in E or some other object-capability-safe language, and you want to audit it for Spectre vulnerabilities. As the article makes clear, other concerns are taken care of structurally by E's design; how might E be changed to also help mitigate Spectre?

Capabilities can mitigate exfiltration of spectre'd data exactly as described in the bit I quoted. That's mitigation of, not proof against, but it's something. I'm afraid I don't see your point.

Why would I rely on hard and slow to execute hardware attacks if I can just have you run my shellcode before you've even started to run my packaged library? The amount of insanity that people get away with in their installer scripts that you invoke via `npm install` is insane as is.

Reply on news.ycombinator.com