Comment by ljhsiung | Hacker News Reader

Comment by ljhsiung | Hacker News Reader

Parent Full thread

Incredibly doubtful. Current attacks are, by this point, pretty well understood. One can simply "check off the list" of attacks and simulate the code gadgets to see what happens (EDIT: e.g. https://github.com/IAIK/transientfail provides a SoK with simple PoCs). In other words, I'm positive that no "script kiddie" can exploit any silicon using current attacks, not just the M1. *

The more difficult/interesting problem is being future-proof to whatever else undiscovered. Many Spectre attacks are heavily timing based, and even a single cycle variation in pipeline stages or flushing structures will spawn a new variant (see, MDS vs. Spectre). This is actually partially why a current trend in hardware research is trending towards fuzzing-type stuff [1].

Something also worth noting is that it's incredibly difficult to quantify "leakage". There's a pretty big difference between vulnerable and exploitable-- e.g. original Spectre papers had 10KB/s of kernel dumping, which is a big reason it was scary, but would it really be a big deal if it had <1b/s? Not going to explicitly name and shame, but there've been a handful of reasonable high profile "vulns" with cute domain names that I'm shocked to even see accepted at conferences due to how contrived the exploit was and tiny their leakage rates were.

I personally don't really know how to address the quantification problem, but I very much think it's necessary in any discussion of a bug's impact/severity. Definitely gets exhausting when every cute name gets a headline, and it's easy to blow things out of proportion without some grounding in reality.

* NOTE: I do think script kiddies have their place still. Definitely important to have automation to determine whether a system has updated security [2], it's just that I doubt such a scenario is applicable to Apple.

[1] https://www.usenix.org/conference/usenixsecurity20/presentat...

[2] https://owasp.org/www-project-top-ten/2017/A6_2017-Security_...

> I'm positive that no "script kiddie" can exploit any silicon using current attacks, not just the M1. *

Oh, do tell how spectre is solved. I would love to know, defending against it is a real problem I currently have. If you allow untrusted code to execute on your machine (e.g. JavaScript) then you're vulnerable to it. There are no practical attacks in the wild that I'm aware of, and it's tricky to do, but it's not impossible and the only defense really is to make it harder and more time consuming. This is the approach that I and others have taken.

Run this [1].

If it works, flush your caches or just update your kernel. If it doesn't, you checked off an item on your list.

I misspoke, silicon should be more like "system". Said it in this comment more about silicon fixes https://news.ycombinator.com/item?id=25665276

[1] https://gist.github.com/anonymous/99a72c9c1003f8ae0707b4927e...

I don't think you understand spectre. Defending against a single POC is not the same thing as defending against this class of side channel vulnerabilities.

Also your references to flushing caches and updating the kernel underlines to me that you don't know what you're talking about.

>> One can simply "check off the list" of attacks

>> The more difficult/interesting problem is being future-proof

I feel like you're not communicating well here. What does checking an attack off your list mean to you? If it means you're safe from it now and in the future, then obviously you're wrong. I feel like that's a strawman and not your actual argument though.

I read it as: defending against known vulnerabilities is well defined, defending against future exploits in the same vein is unknown. Pretty reasonable analysis unless there’s some doubt about the known part?

The impedance mismatch here is that someone is talking about defending against "vulnerabilities" when what they're really defending against is "exploits". Defending against exploits is antivirus, not security. Spectre is a broad class of attacks; there are categorical defenses, but you can't verify them by running a single POC.

Yes, you've put your finger right on it, I think that's where he's coming from.

TIL you can make an anonymous gist?

This functionality was phased out by Github ~2 years ago. Existing anonymous gists previously created still stand.

Doesn’t Spectre/Meltdown rely on hyperthreading? In that case, not doing that would stop it, no? Or am I misinformed and it would affect multi core single threaded chips as well?

There were multiple attack vectors and some of them were significantly better at leaking information with hyperthreading enabled but the basic cache side channel leak worked just fine in single core systems before kernel patches mitigated the impact by flushing hardware buffers as part of the context switch (at a significant performance cost)

If you had a machine that was gapped could you disable the flushing?

Any machine that runs only verified code (ie. no JavaScript in the browser, no downloading nifty things and running them) don't need the flushes. Problem is (as shown by the Solarwind hack) even code you should be able to trust can be backdoored. However: if that is the attack vector, spectre and its' offspring are not your real concern: there are much more efficient and effective ways to compromise your machine if a blob of binary ends of being backdoored.

Yes and no. Yes I think it will protect independent processes sharing a computer that's fully patched. No it will not protect you if you run multiple untrusted scripts in the same process. This is partly why Chrome moved to isolate tabs in their own process after the V8 team eventually admitted defeat in implementing spectre mitigations.

Use a CPU that does constant-time everything (e.g. has no caches). Most of the super-simple in-order RISC-V cores that are available on github will do. Just put one of them in an FPGA, and you are set up.

Most of those CPUs are designed by CS or EE students taking a computer architecture class, so... in a sense... one can argue that defending against Spectre-like attacks is actually super simple: just use a simple CPU design.

To actually become vulnerable to Spectre, you need a very complex CPU design, so in the same way, it can be argue, that making a CPU vulnerable to Spectre is actually hard, since it takes a lot of work to create such a CPU design.

Now, if what you want is a CPU that's both fast and secure, then I'm sorry to tell you that such thing cannot exist. Those two goals are at tension. You can either get a F1 or a tank, but no vehicle that offers the same amount of protection as a tank is going to be able to compete against a F1 car, and vice-versa.

Caches aren't the problem (in the context of SPECTRE), branch prediction is. Getting rid of caches would be very costly performance-wise. VLIW CPUs don't predict branches themselves, but rely on the compiler to generate optimal code ahead of time. I was actually expecting an updated Itanium after the SPECTRE debacle.

AFAIK branch prediction enables the attack by enabling speculative execution, but the data is not leaked through the branch predictor, but rather through the timing differences observed due to speculative loads bringing data to cache.

I guess if you remove the branch predictor, you might avoid spectre while keeping caches, but I think you can keep the branch predictor and remove caches to also avoid spectre.

The downside I see in keeping the caches is that you keep the _source_ of the timing differences, so an attacker just needs to find a different attack vector to create a new timing attack.

If you remove the caches, you kill the source of most timing attacks.

I'm not an expert on this though.

Reply on news.ycombinator.com