Hacker News Reader

Comment by aftbit | Hacker News Reader

I wonder how the Apple M1 hardware stacks up. I don't know if they are vulnerable to any existing Spectre attacks but surely they are still using speculative execution and thus have to be aware of similar side-channels.

View on HN

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.

Could someone with an M1 try and run some Spectre gadgets?

Obviously read the source first but there are a few implementations of the basic ones on GitHub, not sure about the higher versions of spectre (I don't know whether CVE's require an implementation to be published).

If I can find I'll link a paper that describes a system to try to automatically characterize these types of side channels.

I think there still aren't any spectre/meltdown attacks, just proof of concepts. On my home PC I might deactivate mitigation since I rarely execute unknown code. On the other hand CPU power isn't really a bottleneck for me.

It is a memory leakage problem and in the world of today with apps stealing info left and right, I am almost unsure if I should care about it that much. Maybe attackers might be able to steal a key here and there, but I managed to stay quite cool when the architectural flaws were published.

I believe I saw a demonstration about the M1 not being affected by these side channel attacks, but I have no source.

Is it possible to attack via JS/WASM through the browser? That's pretty much the only unknown code I am running.

In theory, yes, it should be possible.

But I don't think anybody managed to, due to the amount of noise the browsers sandboxes add into the necessary syscalls.

That's not true at all. Some of the first proof of concept attacks were done in JS.

Now the question would be are those attacks still viable given the additional hardening browsers have done independent of the kernel mitigations?

That is why I got NoScript when the attacks were discovered

Although many pages do not work with it, so I disable it quite often

I wonder if it is possible to activate the mitigations only for the browser?

Or only for one user? I have created a separate user for the browser, so it cannot change my actual files

Almost certainly the M1 is still "vulnerable" to the same attacks that other current gen CPUs are. The M1 is of course a speculating CPU (and quite a deep one at that), and there doesn't appear to be any rollback for modifications to L1/L2 during that speculation when a branch miss occurs.

Reply on news.ycombinator.com