1. 47
  1.  

  2. 8

    The thread of security issues unveiled during the last few months in Intel CPU and similar architectures is an industrial nightmare. It’s difficult to accept that a whole industry could have been built on a such fragile basis…

    1. 25

      I mean, have you seen the software the world runs on?

      1. 6

        It’s difficult to accept that a whole industry could have been built on a such fragile basis…

        See also car software.

        1. 5

          For me, it was easy after seeing how much better older stuff was that they ignored for money. Intel did try to make their own better stuff which failed repeatedly. They tried three times with i432, i960, and Itanium. Each had good and bad (i960 my favorite) but Intel was punished hard for all of them. Customers did buy billions in x86’s based on performance (most important), cost, and watts. Predictably, Intel decided to keep doing what people paid billions for instead of what cost them billions. I blame the buyers as much as them given I’ve tried to sell lots of them on secure, usable products that were free or cost almost nothing. Usually unsuccessful due to some aspect of human nature.

          Like in most other tech products. It was surprising to me that Intel’s products weren’t worse than they are. Well, maybe they were as the bugs keep coming in as those assessing them predicted. They weren’t designed for strong security since market doesn’t pay for that. So, they have a lot of security problems. The hackers ignored them way longer than I thought they would, though.

          1. 4

            What shocks me most is how long we have been using these techniques without widespread awareness of these issues or the potential for this class of issues.

            Some people predicted these problems, sure, but their concerns were mostly dismissed. So over the course of decades, we’ve seen other chip makers and architectures adopt the same techniques and thus enable these same bug classes.

            For a young initiative like RISC-V, this is a great opportunity. They have not sunk years and years of development in features which may never be entirely safe to implement (speculative execution, hyperthreading, …) and are now able to take these new threats into account, quite early in their development. This could be a boon for industrial adoption, especially while many competitors are forced to rethink so many man-years of performance improvements.

          2. 2

            Does anyone know if it is possible to permanently disable hyperthreading on recent MacBook Pros without using XCode? (I think some automated software hack at startup is good enough for me)

            1. 3

              CPUSetter looks like it should be able to do it.

            2. 2

              I’m not sure I agree with Theo on this one. I don’t think it makes sense to always disable SMT. Single-tenant configurations that don’t locally execute remotely-fetched resources (for example, a browser) would be fine to keep SMT enabled. For example, a physical server (so, no multi-tenant virtualization) that only acts as a VPN server should be fine with SMT enabled.

              1. 5

                In a perfect world, yes.

                But since these vulnerabilities allow memory reads from other threads (including kernel threads) running on the other hyperthread of a core, it means that this escalates a code execution vulnerability (even in a limited, sandboxed environment) to kernel (or just other userspace process) memory reads, which could be a springboard in a more serious exploit chain.

                SMT can still be safely used in some scenarios, like multiple threads of the same process if no isolation exists between those threads anyway, or when executing multithreaded code in the same sandbox, perhaps.

                1. 2

                  It is demonstrably true that there are workloads that benefit from Hyperthreading. I agree that we also see a subset of these use cases where the performance trade-off from disabling this feature is being contrasted with a security issue that is not directly exploitable.

                  I think the OpenBSD team, and others, have made a compelling case for not only preventing directly exploitable security issues but also that proactively fixing security issues can prevent exploits that require a chain or series of exploits, information leaks, or crashes.

                  While you can construct scenarios where this single exploit doesn’t apply, being vulnerable to it means that it can be composed or combined with other vulnerabilities where it may turn out to be necessary even when it’s not sufficient to successfully attack.

                  1. 2

                    I think the OpenBSD team, and others, have made a compelling case for not only preventing directly exploitable security issues but also that proactively fixing security issues can prevent exploits that require a chain or series of exploits, information leaks, or crashes.

                    Of course. Both HardenedBSD and OpenBSD are doing wonderful work in this regard. I didn’t mean to convey that OpenBSD’s work was without merit or meaningless.

                    Instead, what I meant to convey is: with proper risk analysis and management, users can and should be able to decide for themselves whether to disable SMT.

                    While you can construct scenarios where this single exploit doesn’t apply, being vulnerable to it means that it can be composed or combined with other vulnerabilities where it may turn out to be necessary even when it’s not sufficient to successfully attack.

                    Sure. But at that point, local code execution is gained. It’s already game over at that point.

                  2. 2

                    Basically, in light of these vulnerabilities, SMT is a risk whenever the system might be running untrusted code. The reality of today’s computing environment is that you’re almost always running unprivileged but untrusted code to some degree or another. Web browsers and multi-tenant VMs are the most obvious examples. The systems in the world which run only “trusted” code are few and far between. Some examples that I can think of are:

                    • HPC/research clusters with specialized applications in which nearly all code is written in-house
                    • Certain Enterprise appliances like storage servers that don’t allow running non-vendor-provided code
                    • Small general-purpose systems with all of their hardware dedicated to one specific task, like my backup server at home

                    And even these aren’t necessarily 100% safe because there might be a remote exploit of some kind that then allows an attacker to run some unprivileged code which can then abuse SMT for privilege elevation and then you have a rooted appliance. In which case, the only truly secure box with SMT enabled is an air-gapped one.

                    The only good news here is that these kinds of exploits seems to be quite difficult to actually pull off but as The Bearded One says, attackers only get better over time and attacks only get easier.

                    1. 1

                      Through this discussion, my thoughts on the matter have changed somewhat. I still think that SMT should be supported, but disabled by default. After proper risk analysis and management are performed, users should decide whether to opt in to SMT.

                      there might be a remote exploit of some kind that then allows an attacker to run some unprivileged code

                      I view it as: if the attacker has gained reliable remote code execution, it’s already game over. SMT doesn’t matter anymore.