Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Another nail in the casket lake. Is the solution just to throw everything out and start again? Do we just abandon speculative execution?


The problem for most of these is not speculative, it's not doing proper acl during speculation. Just because the cpu is speculating doesn't mean it shouldn't check if you are allowed to access this or that, but that's what Intel did, and they only did the security check at the end before giving back the result, except at this point its too late you've already accessed it.

Other manufacturers AMD included didn't get affected by those variants.


I wonder what the performance costs of those ACL checks are.


A single one might not be that big, but they add up (if there are several suchs checks to do in your speculated branch, instead of doing them when they appear during speculation intel chips pooled them up all at the end), and they disappear if the speculation was wrong (speculated the wrong branch ? Didn't lose any time on permission check).

They're the >~10% of cpu perf intel chips have lost in the last few years with all the mitigations.


> They're the >~10% of cpu perf intel chips have lost in the last few years with all the mitigations.

Given AMD's Zen 2 has comparable IPC to Intel at this point without doing the ACL check late it's not evident that the difference in when the ACL is done was a key efficiency gain.


I was not talking about intel's 10% lead over AMD, I was talking about chips from 3-4 years ago, when tested again now with mitigations, perform 10% worse or more in affected workload (see https://www.phoronix.com/scan.php?page=article&item=intel-ic... for exemple)


Surely the mitigations are not the same as "doing proper acl during speculation" in the first place and have a worse performance hit?


They get that IPC on a better process. Shorter gate delays let you pack more into each cycle. IPC can't be divorced from process when comparing architectures.


IPC is from design not from transistor density. Clock speed is what can't be divorced from process. IPC can be. More transistors could enable new designs not previously feasible, but we've loooong since past that point (hence why most new transistors are just being dumped into L3 cache)


Part of the driver of IPC is how many layers of logic you can fit between each pipeline register. We’re not talking density we’re talking logic gate delay.

Each process has different delay, setup, and hold times. On one process I might be able to fit 15 layers of logic before I have to add a pipeline stage. On another I might be able to fit 20 at the same frequency. Pipeline stages are also not free with each adding additional overhead.

This determines how advanced I can make things like my branch predictor or cache pre-fetcher while still meeting timing requirements. For example I might want a larger lookback buffer but I can’t use a larger memory - not because of how much area it takes but because it simply takes too long to do the look up now.


AMD and others are fine. Just have security people on the team during microarchitecture design.

Spectre variant 1 is probably unavoidable so security inside a single virtual address space is kinda dead. Use separate processes and mmu.


Or we abandon sharing the same hardware for trusted and untrusted code. (Yes, that includes things like whitelisting JS.)


Abandoning speculation entirely is too much. If you just go to in order with a reasonable pipeline length nobody has yet figured a way to smuggle out speculative state on something like an ARM A53. That means giving up performance but only a factor of 4 or so. Giving up speculation entirely would mean an order of magnitude larger performance loss.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: