4 ms·

> 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 kno

• ljhsiung 6y ago
  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 https://news.ycombinator.com/item?id=25665276 [1] https://gist.github.com/anonymous/99a72c9c1003f8ae0707b4927ec1bd8a https://gist.github.com/anonymous/99a72c9c1003f8ae0707b4927e...
  • eloff 6y ago
    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.
    • ljhsiung 6y ago
      >> One can simply "check off the list" of attacks >> The more difficult/interesting problem is being future-proof
      • eloff 6y ago
        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.
        • eyelidlessness 6y ago
          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?
          • tptacek 6y ago
            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.
            • eloff 6y ago
              Yes, you've put your finger right on it, I think that's where he's coming from.
  • saagarjha 6y ago
    TIL you can make an anonymous gist?
    • toomuchtodo 6y ago
      This functionality was phased out by Github ~2 years ago. Existing anonymous gists previously created still stand.
• colejohnson66 6y ago
  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?
  • haimez 6y ago
    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)
    • deleted 6y ago
      [deleted]
    • wasdfff 6y ago
      If you had a machine that was gapped could you disable the flushing?
      • wokkel 6y ago
        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.
  • eloff 6y ago
    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.
• volta87 6y ago
  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.
  • guenthert 6y ago
    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.
    • volta87 6y ago
      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.