Hacker News Reader

Comment by samth | Hacker News Reader

Like many with a background in programming languages and their implementations, the idea that safe languages enforce a proper abstraction boundary, not allowing well-typed programs to read arbitrary memory, has been a guarantee upon which our mental models have been built. It is a depressing conclusion that our models were wrong — this guarantee is not true on today’s hardware. Of course, we still believe that safe languages have great engineering benefits and will continue to be the basis for the future, but… on today’s hardware they leak a little.

We should all be more angry at chip makers for this. Intel isn't willing to admit that they broke things because then they'd have to fix it, but we shouldn't accept that kind of approach.

View on HN

Chip makers never “broke” anything. Resistance to side channel attacks was never part of the protection model. Remember, these protection models were designed when if an attacker was running code in your address space things had already gone completely sideways. To the extent anyone is at fault, it’s the folks who designed browsers with in-process JS engines without realizing that they were assuming the hardware was providing protections that the hardware didn’t claim to provide.

Why do comments like this get rated down so quickly. The process boundary was supposed to be the level of protection. Preventing your own process from accessing itself was never part of the memory model.

Chip manufacturers have known about JavaScript and it's implementations for decades.

ARM for instance had gone so far as to make JS specific instructions (FJCVTZS, Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero), and before that they had instructions to help a JIT (ThumbEE).

Not sure why we're buying the chip companies' shtick of "oh, poor us, we never knew people would use our chips like that, we just specifically optimized for it and provided support instructions"

So chip makers should have redesigned their hardware to match the erroneous assumptions JS vendors were making about how memory protection works?

They should have provided mechanisms for multiple memory domains in the same process, so that people can use their chips securely to do the work the expect to do with them, yes.

Got it. Chip makers have an obligation to accommodate (proactively, no less) stupid things developers do, like running untrusted code in the same process. Makes total sense.

They knew since the 90s that people were doing this and expecting it to work, or did you miss that whole Java thing? Java became big as Intel was adding OoOE to their cores.

Hardware and software is codesigned, and yes the onus is on the chip manufacturers to release chips that let you continue to use them securely.

Why don't software developers have the responsibility to write software that uses the existing hardware protection mechanism?

Because chip manufacturers changed their hardware after the fact and kept their changes proprietary.

Not stupid things developers do. Chip makers should accommodate the behaviour of most users of their chips, which does include running javascript.

You're trying to casually brush away the entire field of software fault isolation as "stupid things developers do". In fact, SFI has been a respectable area of systems research since at least 1987.

I'm not trying to casually brush away the whole field. MMU-based protection has been overly limiting ever since MMUs were developed. That doesn't mean that every design for providing isolation beyond what the MMU can guarantee is well-thought-out. Certainly, I see no basis for blaming chip makers for the fact that VM developers came up with an attempt at same-process isolation that doesn't work.

It's like all the whining people do about GCC doing unexpected things when faced with code that relies on undefined behavior. That's not GCC's fault.

> Certainly, I see no basis for blaming chip makers for the fact that VM developers came up with an attempt at same-process isolation that doesn't work.

The issue isn't that there's a bug in their VM implementation, it's that with current hardware general VMs and same process isolation are mutually exclusive.

If hardware architects had intended not to support software fault isolation, then they would have said so back when the field was developed. It's not like people with experience in hardware design weren't in the peer review circles for those papers. Steve Lucco, one of the authors of the 1993 paper, went on to work at Transmeta.

This isn't like GCC, where the C standards bodies officially got together and said "don't do this".

"Be kind. Don't be snarky."

https://news.ycombinator.com/newsguidelines.html

If they were erroneous, why weren't they corrected for two decades by those very same chip makers? It was various security researchers that first warned about something like this, not an Intel engineer saying "y'all are holding it wrong".

> Not sure why we're buying the chip companies' shtick of "oh, poor us, we never knew people would use our chips like that, we just specifically optimized for it and provided support instructions"

Hardware moves slowly and can't be fixed easily. Browsers should just be doing this (which they are with site isolation) instead of hardware trying to hack in patches to cover up bad software architecture.

And you can't fix a bug you didn't know about anyway, so why would you have expected ARM to fix something nobody knew was real in the first place?

Running untrusted code in the same process isn't "bad software architecture". And we've been doing that for as long as microprocessors have had OoOE. Java got big right when the first consumer OoOE chips came out in the 90s.

> And we've been doing that for as long as microprocessors have had OoOE

Prior to web browsers when was such a thing ever widespread? And if you eliminate web browsers from the picture, how many usages are even left?

> Java got big right when the first consumer OoOE chips came out in the 90s.

Java doesn't do this, so how is that relevant?

> Prior to web browsers when was such a thing ever widespread? And if you eliminate web browsers from the picture, how many usages are even left?

BPF has existed since the mid 90s for one example.

> Java doesn't do this, so how is that relevant?

Java and the client web were next to inseparable concepts at the time. Java ran their VM as a shared library in the browser process for applets.

The JVM took responsibility for sandbox isolation. It took until Spectre/Meltdown to widely demonstrate that this was a poor decision, because it turned out in process sandbox isolation is a promise that cannot be kept. And the point of the JVM was to run the same code on all sorts of hardware, so it doesn't get to blame the Intel or Spark or Motorola CPU it happens to be running on.

Meltdown let processes access kernel memory which was supposed to be hardware protected. That is a violation of the chipmakers obligation, not the software obligation.

... yeah.

And that is a different discussion. The article, and the discussion here, is regarding side channels attacks within a single process. I'm pretty sure everyone agrees that the hardware (or some conspiracy of the hardware and kernel) must provide process isolation.

CPU designers have had to deal with in-process isolation for a very long time. The earliest citation I can find is Berkeley Packet Filter in 1987 [1], before the 486 and just two years after the 386 memory protection debuted. If you were to go back in time and ask Intel's chip designers whether they intended to support BPF well, I'm sure they would say yes. Software fault isolation in 1993 (seminal paper at [2]) built on those techniques.

Spectre is simply a subtle oversight in the way different pieces of the system interact.

[1]: https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-2.pdf

[2]: https://homes.cs.washington.edu/~tom/pubs/sfi.pdf

Note that BPF doesn't attempt to provide much of a security barrier.

> This access control mechanism does not in itself protect against malicious or erroneous processes attempting to divert packets; it only works when processes play by the rules. In the research environment for which the packet filter was developed, this has not been a problem, especially since there are many other ways to eavesdrop on an Ethernet.

And even on modern systems, you need to be root to install a packet filter, which is typically also sufficient privilege to simply open /dev/mem and read kernel memory directly. (Or you did, then people started using bpf for everything, but that came many years after the 386 and 486.)

I don't think BPF is a good example of running untrusted code, at least not the early versions, since it wasn't untrusted.

Right, I would contend that the threat model addressed by BPF is preventing trusted but buggy code from taking down the kernel, not protecting against malicious code.

Regardless of whether it's 1987 or 1993 that you want to date the beginning of SFI to, it's certainly the case that SFI is explicitly designed to protect against malicious code. CPU designers have had a long time to deal with that, and you didn't see them telling people not to do it back then.

seccomp-bpf might be a better example than bpf as packet filters, since unprivileged processes are allowed to provide the bpf code.

> Spectre is simply a subtle oversight in the way different pieces of the system interact.

Yes in the sense that I assume chip makers didn't foresee it and don't like its ramifications, but it's also one that's essential to how the chips currently give their users the performance they want.

Great links, SFI is basically the technique behind NaCl(Native Client) and the Go Playground no? I didn't realize this technique was this old.

How do Spectre attacks on kernels and on other processes fit into your model? Mitigating them has required hacks such as Linux's array_index_nospec(), plus newly added microcode features such as IBRS, STIBP, and SSBD, all of which cause significant slowdowns – to such an extent that SSBD at least is off by default in most OSes – yet even enabling all mitigations does not completely prevent Spectre attacks. And there's nothing about the design of modern kernels that's changed in the last several decades to make them more inherently susceptible to Spectre attacks, so the issue was already there when the protection model was designed.

(There is something in Meltdown's case: not flushing the TLB on every context switch is relatively new. But it's directly encouraged by CPU manufacturers via the ASID feature. And Meltdown is a narrower bug anyway, something that's easy to fix in a new hardware design, not like Spectre which is more fundamental to the concept of speculative execution.)

Everybody who studied even a little bit about processor hardware new about speculative execution. And it was never just intel that was using it, (they all were). Until Spectre that technology was not considered controversial.

the crazy thing is that nobody saw this until recently.

"Until event X, doing <thing that X demonstrated was bad> was not considered controversial" is an explanation of behavior, but not really a defense.

Negligence, recklessness, knowledge, or purposefulness are probably the only way actions can be wrongful. To have acted negligently, you at least ought to have known that it carried an unacceptable risk. So you need a story on how it was at least negligent and why they ought to have known the risk before releasing the product.[0]

Mere causation can’t get you there. E.g. when a car hits a pedestrian, the driver and pedestrian equally “caused” the accident. It is only by way of characterizing their behaviors in one of the ways above that we can identify wrongdoing. Perhaps the driver wasn’t paying attention (negligent or reckless) and ran a red light. Or perhaps the pedestrian was intentionally throwing themselves in front of traffic. Etc.

[0] Products liability law on its surface does eschew the moral-wrongdoing requirement in favor of strict liability for some kinds of product defects. But that has to do with economic incentives, practical ability to prove claims, etc.

Here, chip makers never promised to prevent X. Maybe preventing X is desirable now that people do Y, but you can hardly blame them for not preventing something they didn’t promise to prevent.

They promised to develop general purpose chips which can meet as many desktop computing needs as possible, which now implicitly includes need Y (but they didn't anticipate that at the time).

They could of course just reject the necessity of need Y, but if the majority of their clients actually do have need Y, can it really be said that the chip is successful at being general purpose?

Yeah you can. Because the chip provides capabilities so you can do such protections in software if you want, or get more speed if you don't want.

> the crazy thing is that nobody saw this until recently.

Correct me if I'm wrong, but speculative execution attacks (or at least the possibility) were known for several years before Spectre.

You're not wrong - side channel attacks have been around for forever

Not all side channel attacks rely on speculation, although I think all known speculation attacks necessarily rely on side channels to exfiltrate information. I'm not an expert but I think that specifically attacking speculation was novel.

Theo de Raadt was complaining about the possibility 12 years ago. https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

I don't see any mention of speculation there. Any further pointers?

For anyone who hasn't come across it, here's a really interesting blog post about speculative execution and a cache bug in the Xbox360 (2018 post about stuff that happened in 2005):

https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-d...

You say that like if Intel flaws were comparable to the ones from ARM and AMD. They aren't.

And this post isn't about those flaws, so that's irrelevant.

that's victim blaming.

chip consumers missing a communication is very different from intel actively developing this to cut corners for raw performance (which is the only reason they cornered the market) and forcing all other manufacturers to follow up or die.

Speculative execution was developed by IBM in the 1960s, before Intel made CPUs.

To be fair, untrusted code wasn't part of the security model for mainframes for the longest time.

Wait, wasn't it more a part of their model than for Intel? We're talking about the era of mandatory access control and time sharing.

I mean, the 360/91 that he's talking about didn't even have an MMU.

Wait--weren't MMUs available back even on the 65/67?

Only the 67 for the 360s, and there the software hadn't really caught up. On the 370s it was more prevalent, but they had gone back to in order designs at that point.

I don't think this is really correct. From August 1965, multiprogramming was offered using DAT (Dynamic Address Translation)--what they called MMUs back then.

And this feature was used to support not only many programs running at once, but also TSO (Time Sharing Option) which by definition is mutually untrusted code.

TSO didn't depend on hardware boundaries between clients.

Technically, the phrase victim blaming fits this sentence, but I feel like this context is not its intended or commonly accepted use

This is one of the discoveries that you see then slap your forehead saying "Duh of course!"

It's more depressing that some people think of programming as programming a language rather than a machine. Languages are just fluff that all reduce to the same thing when crunched through a compiler or interpreter.

Writing your code in assembly wouldn’t have isolated you from any of these issues; in fact it would make deploying the kinds of mitigations mentioned in the article drastically more difficult. And even if you’re actively thinking about micro-architectural concerns, it is evident that these issues are not obvious, since it took a long time for anybody to put their finger on a concrete problem with speculative execution.

Chip makers favored speed over security to get a leg up in the megahertz wars. They may have even been aware of the risks, but at the time thought they were obscure and difficult to exploit. They made sound decisions at the time, which makes Meltdown and Spectre even scarier, because what sound compromises made since then will come back to bite us in the ass later?

Sometimes I think that humanity is not ready for computers, and it's time to go full-on Butlerian jihad.

Reply on news.ycombinator.com