Announcement

Collapse
No announcement yet.

OpenBSD Disabling SMT / Hyper Threading Due To Security Concerns

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Djhg2000 View Post
    If the argument is that different security domains shouldn't share the same physical core, wouldn't it make more sense to enforce that policy at the process scheduler level rather than disabling SMT altogether?
    This was addressed in the article.....

    "OpenBSD could improve their kernel's scheduler to workaround this, but given that is a large feat, at least for now they have decided to disable Hyper Threading by default."

    Comment


    • #12
      Originally posted by edenist View Post

      This was addressed in the article.....

      "OpenBSD could improve their kernel's scheduler to workaround this, but given that is a large feat, at least for now they have decided to disable Hyper Threading by default."
      Yeah but disabling SMT completely still seems to me like fixing a broken leg with an amputation. Those who fear "cross threading" attacks (in lack of a better term) will have manually disabled SMT anyway and those hunting performance will just manually enable SMT again, so who is this really for?

      Moreover, why can't they temporarily force the scheduler to have the kernel run strictly on physical core 0 and userspace stuff strictly on 1+? IIRC that's something you can do already with the existing schedulers in Linux through a boot parameter and a bit of scripting. From a quick web search about the same result should be achievable with OpenBSD in its current form as well.

      Comment


      • #13
        Hmmm....wonder if the old AMD Bulldozer architecture of "Clustered Multithreading (CMT)" which led to Piledriver and Excavator, which of course was what the Carrizo and Bristol Ridge APU was based on is as vunerable as Intel's application of SMT? I know it was sort of a "hobbled" version of SMT because of the way AMD designed the cores.

        And then further...what about Zen and Raven Ridge APU's? Didn't AMD go to full blown proper SMT with this architecture ?

        Comment


        • #14
          At the rate AMD is pumping out cores per socket, SMT will become somewhat irrelevant in the near future. It will eventually fall into a niche best suited for specialized applications. DB2 on POWER uses SMT very well and one can see its use case pretty clearly. SMT on Intel has been nothing but a PITA since Day 1. Always misunderstood in its use and capability for many years. Virtualization made it go from tolerable to downright miserable. Try to find a cap planner who has a clue how to calculate oversubscription rates on HT Xeons.

          Comment


          • #15
            The same people also claim that the linear-interpolation resampler in their audio subsystem does not produce audible distortions. Which is wrong.

            Comment


            • #16
              Originally posted by patrakov View Post
              The same people also claim that the linear-interpolation resampler in their audio subsystem does not produce audible distortions. Which is wrong.
              Being an audiophile is an interesting pass time. I care that the music I listen to sounds good.

              that said I also listen to lossy compressed audio over my works computers onboard audio because it is "good enough".

              Comment


              • #17
                SMT was just a hack to cover the fact that branch prediction misses in the long-pipeline "NetBurst" ( fire whoever came up with that name ) architecture were punishing performance. The proper solution would be to abandon the NetBurst architecture, which they did ( returned to the PIII architecture, but called it 'Core' ), but then brought bits of NetBurst back for some reason? Probably so they could flog dual-core systems as quad-core. Personally I disable SMT because it's horrible for realtime scheduling.

                Comment


                • #18
                  That moment when you have so much security that the device fails to function for its intended purpose..

                  Comment


                  • #19
                    SMH. I understand the concerns with Intel CPUs but the OpenBSD team has been making a lot of changes to their OS that makes it... Less usable. Losing Linux emulation (as rudimentary as it was, it worked), LKMs, and now this really is disappointing, but I can't really say I'm surprised. They are the kind of devs to do something like this. LibreSSL, OpenNTPD and OpenSSH aside though, OpenBSD is not an OS I use.

                    Comment


                    • #20
                      Originally posted by nazar-pc View Post

                      For some applications yes, but there are also many applications where SMT allows to almost double performance. So disabling it by default is at very least controversial decision.
                      I'd argue that OpenBSD is primarily focused on security sensitive applications...

                      Comment

                      Working...
                      X