Hacker News Reader

Comment by daxfohl | Hacker News Reader

Would a hardware fix also eliminate the perf degradation that the software fixes introduced? Or does it just increase security?

View on HN

I'd say both Spectre 2 and Meltdown are fairly straightforward to fix in hardware without performance degradation (though probably at the cost of a bit more circuitry), so that's most likely what they did.

For Meltdown, you need to just never load data from L1$ when permissions checks fail. Since address translation is already on the L1$, doing permissions checks there as well is not a big burden. This is quite natural to do, and also why Meltdown specifically affected Intel, and not everybody.

For Spectre 2, you need to add some bits to the branch target buffer to tag entries by the privilege level and ideally PCID (to protect user level processes from each other). And then you just don't use BTB entries with the wrong tag.

It'd still be interesting to know the details, e.g. what exactly they changed for Spectre 2.

Your proposal doesn't fix Spectre 2 in general; just the cross-privilege level (or at best cross-process) aspect. Anyone trying to create a sandbox still has to worry about the sandboxed stuff being able to read all of the sandbox memory, for example.

That's a good point.

Ideally the ISA would allow user level code to also toggle a flag that affects the BTB. That would allow embedding JIT code while guarding against Spectre 2 (fixing the BTB injection).

I don't think you really need more than that though. Reading arbitrary memory would seem to require a Spectre 1-type attack instead. Unless you have an explicit counterexample in mind?

For the JIT'ed code, Spectre 1 can probably be mostly avoided using the bitmask trick or something equivalent, which we seem to be moving in the direction of anyway (thinking about the WASM execution environment specifically), and for the "host" code inside the sandbox, the same kind of selective software fixes are required as in the kernel.

I suspect you can get arbitrary memory read with Spectre 2 as well; just have to find the right gadgets. Which in a big program of the sort that would have a sandbox inside is somewhat likely...

(I can't comment on specific counterexamples in more detail than that, even if I know of any.)

I don't see how that could be.

Spectre 2 is about code in a less trusted domain A introducing an otherwise impossible branch target used by branch prediction on code in a trusted domain B. So a solution that adds tag bits to the BTB to distinguish between those domains should be a 100% effective fix. The only arguments are about how many tag bits & who gets to set them, i.e. a user-mode JIT sandbox would want to be able to control at least one tag bit for this, but if it can, it'd be fully effective.

Unless you start thinking about protecting different JITted code domains in the same address space from each other... I guess at some point you just have to bite the bullet and invalidate the BTB.

I suppose an additional problem would be if the BTB just "hallucinated" random indirect branch target destinations somehow, which could allow untrusted domain A code to jump (in speculation) to code that would normally be unreachable. A kind of "reverse Spectre 2", if you will, although the same tag approach should fix that at the same time as the original Spectre 2.

Spectre 1 attacks from JIT'ed code against the outside code are definitely possible though.

> The only arguments are about how many tag bits & who gets to set them

That's fair. I guess I've seen no indication that bits will be provided by ISAs and OSes to userland (past the bit that distinguishes userland from kernel code)...

> Unless you start thinking about protecting different > JITted code domains in the same address space from each > other

That's also fair. As a browser developer, this is my world right now. ;)

It should (depending on how they implement it), as long as the software is re-modified to run the original way on only this platform and later. The performance degradation at least would move into hardware instead of software.

How are they going to fix it without some performance penalty. If the memory is in cache isn't there going to be a timing difference? or an extra check will have to be made which is going to have to slow down the lookup?

From what I underst and this fixes variants two and three which are cross ring and cross process data extraction. I believe their hardware mitigation is to separate the caches between those (or something to that effect). So there will still be a minor penalty hit for running multiple identical process compared to before.

That's my interpretation though, I don't know enough to say that's the correct interpretation.

Does the hardware on x86 even know which cache is owned by which process? It knows which is elevated (kernel Vs. User Vs. Hypervisor, etc) but process isolation on x86 is largely a kernel API construct rather than a hardware one.

Unless I'm mistaken.

The answer is yes, if the processor supports PCID: https://news.ycombinator.com/item?id=16094349

  Simplistically, it allows TLB-cached page table contents to be tagged with a 
  context identifier, and limits the lookups in the TLB to only match within 
  the currently allowed context. TLB cached entires with a different PCID will 
  be ignored.

I think you are confusing the TLB and processor data caches.

PCIDs exist for virtual addresses and are implemented in the TLB, not the processor caches. The processor caches are physically indexed, not virtually indexed.

So, does the processor cache have a mechanism to tell which "process" to which a given line belongs? Nope. Two processes (or a process and the kernel) that share memory can be in two PCIDs, but share the processor caches.

You are correct. My assumption was that the original question is not focused on the data cache itself, and so the DTLB does qualify for "knowing" what belongs to which context.

> to fix it without some performance penalty.

10nm + higher frequency?

An additional check can be made in the same time in parallel if there's extra hardware (specific gates) assigned to do that.

We can't really know, since we don't have something to compare it to. Only they know what the performance could have been if the fix were not implemented in silicon, and they won't be releasing new versions of old chips that ONLY have this hardware fix, so we will never be able to compare the two. Only they will ever know, however if we see comparable or worse performance (or just barely better) in these new chips then we can know that there was some performance hit.

From the intel press release:

>"As we bring these new products to market, ensuring that they deliver the performance improvements people expect from us is critical. Our goal is to offer not only the best performance, but also the best secure performance." https://newsroom.intel.com/editorials/advancing-security-sil...

That's a non-answer answer.

It doesn't say there will be no degradation. Only that that might be minimised.

Isn't it clear? Performance is top priority and security is also top priority.

edit: apparently sarcasm on the web doesn't work very well.

...and an almost fanatical devotion to the Pope, and nice red uniforms.

It (sarcasm) never has, though, yes.

And reliability is also top priority. And minimizing cost is also top priority. [/sarcasm]

It’s pretty well known that when you say you have multiple top priorities, what you really mean to say is that marketing is your top priority.

They probably aren't sure yet.

That thought has also occurred. Intel could have said as much, but did not.

It's doubtful Intel would delay plans too much to work on such subject, and its even more doubtful the result would even be better for anybody: we would have to use the old completely unpatched chips for longer...

It's better for everybody to have more frequent gradual fixes, even if the firsts are not 100% complete.

Only in that you don’t be able to directly measure it anymore because the mitigation is buried in the performance data of a new processor.

Would this result in 32bit, x64, x64CPUpost2018 versions of software, as from my limited understanding apps (such as v8 engine) are being compiled with workarounds for such that won't be needed once fixed in hardware?

Reply on news.ycombinator.com