back to article Running on Intel? If you want security, disable hyper-threading, says Linux kernel maintainer

Linux kernel dev Greg Kroah-Hartman reckons Intel Simultaneous Multithreading (SMT) - also known as hyper-threading - should be disabled for security due to MDS (Microarchitectural Data Sampling) bugs. Kroah-Hartman, who was speaking at the Open Source summit in Lyons, has opened up on the subject before. "I gave a talk last …

Page:

          1. Anonymous Coward
            Anonymous Coward

            Re: Buying Intel

            "I get all that cheering for underdog, but rng returning all ffff... getting past qa means no amd CPUs for me in near future. This slappy beyond believe - can't believe all of you just shrugging it off!"

            The problem can be summarised as a BIOS bug that prevents machines booting in certain circumstances and a fix has been released by AMD but may not have been released by all motherboard manufacturers.

            It's annoying and there are workarounds if you are unlucky enough to be affected and in a few months it will largely be addressed.

            In the meantime, back to the real security issues with Intel Hyperthreading that can't be addressed other than by disabling a feature (hyperthreading) and suffering a performance hit as a result. The fix for which is a new CPU.

            If you find these comparable rather than one inconvenient and the other challenging to address in any large scale environment then....*shrug*

      1. BinkyTheMagicPaperclip Silver badge

        Re: Buying Intel

        Not very scary. Fixable via a BIOS update, or a kernel boot parameter, or an updated kernel.

  1. Anonymous Coward
    Anonymous Coward

    Roll up roll up. get your AMD EPYC Romes here.

  2. ExampleOne

    If you're running on Intel, but want to be secure: best practice is to disable hyper-threading and keep your BIOS and kernel up to date.

    Surely, if the problems are exclusive to Intel hardware, the best practice is to stop running Intel hardware and get non-broken hardware from vendors who didn’t cut corners with security to win benchmarks?

    1. This post has been deleted by its author

    2. Norman Nescio

      Updating Firmware isn't easy

      If you're running on Intel, but want to be secure: best practice is to disable hyper-threading and keep your BIOS and kernel up to date.

      Updated Linux kernels are easily and freely available.

      BIOS - not so much. Many OEMs provide firmware (which could be BIOS, or a whole host of other things) updates as Windows-only executables. FreeDOS and the Linux Vendor Firmware Service don't cover all the hardware out there, which means that there are an awful lot of systems with out-of-date firmware out there. This is not good, but I can't see a realistic and easy answer.

      1. Doctor Syntax Silver badge

        Re: Updating Firmware isn't easy

        "Updated Linux kernels are easily and freely available."

        Yes, and even those are only chasing the problems that they've discovered. The implication is that there are still many out there to be discovered - and maybe some have been discovered by someone else.

        1. amanfromMars 1 Silver badge

          Re: Updating Firmware isn't easy on Prime Candidates for Change in Perverse Corrupt Systems Admins

          Yes, and even those are only chasing the problems that they've discovered. The implication is that there are still many out there to be discovered - and maybe some have been discovered by someone else. ..... Doctor Syntax

          :-) ..... and what can/should one do with such an attractive promiscuous beast and wild child, Doctor Syntax, should it ever be thought possible to be able to do anything at all effective and worthwhile in so many fields in which ignorance and arrogance would claim to exercise reign?

          Whenever nothing at all effective and worthwhile is the true answer, who and/or what suffers and benefits the most from such as is as Madness and Mayhem for CHAOS in Confusion?

          Any advance on Intelligence and Sanity?

      2. vtcodger Silver badge

        Re: Updating Firmware isn't easy

        Updating OS kernels is (usually) tractable. I can test the new kernel for hardware compatibility and other issues without destroying my system. Or if the testing failed to show a problem that becomes all too apparent later. I can (probably) recover from a problemetic update one way or another.

        BIOS and other firmware upgrades OTOH have the potential to be a "final solution". If I brick the hardware, am I going to be able to unbrick it?

      3. Roo
        Windows

        Re: Updating Firmware isn't easy

        There is an easy answer, but the vendors and "power users" aren't going to like it.

        The hundreds of megabytes of Flash, the tweaking guff, weird Windows backwards compatibility widgers (eg: "A20" config), PXE boot loaders can and should get shit-canned. This allows a customer to have some confidence + control over what is actually executed and some assurance that their M/B can't be perma-bricked by some tosser at the other end of an Ethernet cable.

        This could be achieved very simply and cheaply by replacing the Flash memory + fscking BIOS / UEFI with a tiny *ROM* bootloader that loads a few bytes off a bootstrap storage device (eg: a MicroSD card on the motherboard) and executes it. That ROM bootloader should do nothing other than load those bytes and execute them - everything else is to be done by the code on the MicroSD card that is firmly under customer control.

  3. Peter Prof Fox

    Surely...

    If I'm in a high performance environment then I've already done boundary stuff or weeded out fringe activities. No screen-savers for me while I'm AI-ing the next national lottery numbers.

    For the rest of us why not enable whizzo cache stuff only when CPU usage exceeds 85%? That way most of the time there is no point in poking around with fancy caches and long before Mr. Black Hat has winkled-out any cross-contaminated trivia I'll have detected or changed.

    1. Glen Turner 666

      Re: Surely...

      If an attacker wants to defeat the Spectre mitigations then all they need to do is run a tight loop in their code and the mitigations will switch themselves off?

      1. Venerable and Fragrant Wind of Change
        Terminator

        Re: Surely...

        If my load is consistently high, it'll trigger an investigation. At whatever depth it takes.

        Corollary: if malware lands on my system, it'll have much longer life expectancy if it refrains from doing anything to advertise itself.

        1. Any other name

          Re: Surely...

          Since we are talking about HPC systems, let me fix that for you:

          If my load is consistently low high, it'll trigger an investigation. At whatever depth it takes.

          There!

  4. Traveller from the outer rim

    Same process = no problem

    If two threads from the same process shares a core, then there is no problem. Hyperthreading only becomes a problem when threads from different processes shares a core. Thus, the kernel should allow hyperthreading within a process.

    1. Peter Gathercole Silver badge

      Re: Same process = no problem @Traveller

      Whilst in general I agree, it is now the case that within a browser, each tab is run in a separate thread, with protection between the threads (there was an article about this in Firefox a few months ago).

      As each tab could be running client side code downloaded from different servers, each in their own thread, it is necessary to have some degree of protection to prevent code in one tab getting information from another tab (imagine if you are doing some online banking in one tab, which could be spied on from a tab running some 4Chan or LOLcats pages in another).

      So it is not safe to have hyperthreading turned on even inside a single process.

      In addition to this, as most OSes schedule at a thread level, not a process level, it is practically impossible to have hyperthreading turned on in one process and not in another. Maybe on a core-by-core basis, but then you have all sorts of core affinity problems, and that does not solve any problems!

      1. Traveller from the outer rim

        Re: Same process = no problem @Traveller

        I think the issue that your are touching is much broader. If you host a service (e.g. a web browser) that expose a Turing machine (e.g. a javascript engine) to external parties (e.g. websites), then you need to be very careful about what is available to that Turing machine. Ensuring that code is not able to exploit speculative execution bugs in that closed environment should be easy (and to my understanding it has been solved).

        With regards to scheduling, then it would be similar to being NUMA-aware when scheduling.

  5. LordVader

    Desktops and browsers

    Most of the code running on your desktop or laptop comes from signed rpms and operates on input written by you. So it's fine. The risk is really browser tabs spying on each other. A few years ago in most browsers those weren't separate processes anyway (just threads) and we weren't too bothered, but the simplest mitigation is just to close your whole browser and reopen only one window if you need to login to your bank account etc.

    1. Peter Gathercole Silver badge

      Re: Desktops and browsers @LordVader

      This is not really the case. Yes, much of the code is in signed RPMs or DEBs, but that only goes so far.

      There are many other routes to get code on your system, which include Perl CPAN modules, browser extensions, desktop extensions, Java and Javascript running outside of a browser, and pretty much any high capability scripting language, especially those that allow the use of online code repositories, of which there are now plenty.

      The flexibility of having client side code execution comes with many, many security implications, many of which are not even obvious unless you look at how these features are implemented.

      Also, using a browser to execute complex applications is becoming much more normal with the G-suite, Office365 and all the other cloud based services. It soon won't be a minor piece of functionality, but the norm, as it is on Chromebooks now.

    2. DuncanLarge Silver badge

      Re: Desktops and browsers

      Its not just browser tabs spying on each other.

      Its the browser tab running in your VM spying on the host too!

      Also signing does not guarantee the program is not malicious, it only guarantees that the program is undamaged/unaltered from the repo. Once the GPG keys get compromised or the Git tree modified under the nose of the developer signing means very little beying confirming that the malicious package you just downloaded did in fact get signed by those keys and was not modified.

    3. Aitor 1 Silver badge

      Re: Desktops and browsers

      Or browser tabs spying on my kernel...

  6. TeeCee Gold badge
    Meh

    "Making that switch means one, two, three more data centres....

    Or swapping to AMD CPUs a) because "All the issues that came out this year, were reported not to be an issue on AMD," and b) because they have better multithreaded performance even before you cripple the Intel ones.

    You might want to be shorting Intel about now...

    1. Anonymous Coward
      Anonymous Coward

      >You might want to be shorting Intel about now...

      I already did when they fell on their arse with 10nm, this just adds grist to the mill.

  7. david 12 Silver badge

    Hyperthreading

    Cripes. The whole article is a mass of confusion, which seems to originate in the direct quotes, between threading, hyperthreading, shared cache and multi-core processors. Was English not the first language of some of these guys?

  8. amanfromMars 1 Silver badge

    It is not only what you know, but how you also say and share it too that matters ‽ .

    Cripes. The whole article is a mass of confusion, which seems to originate in the direct quotes, between threading, hyperthreading, shared cache and multi-core processors. Was English not the first language of some of these guys? .... david 12

    david 12,

    The whole gist of the argument is that virtually all practical machinery is commanded and controlled with the use of patented words. It is why certain strings of words are so terrifying as to be absolutely worthless in anything worthy of enjoying and employing/engaging and exploring possibilities with.

    Whose words are drivering your vast mute geopolitically astute machines .... you know, the Source Servers of Current Present Confections Holding Media Hostage with a Dodgy Past Catalogue of Very Early Exceptional Successes to Protect and Prune/Prime Time Performance Enhance. ‽

    You might find now there are more than just a precious few, and the precious few are confounded and confused to be so easily recognised and liable to follow up questioning on future plans.

    Things then can easily very quickly go super critical frenetic and crazy ballistic if that is your only proposed plan .... to hold worlds to ransom with almighty worthless weapons .... for that is Universally Unacceptable and Punishments are Certain Death and Immense Destruction. It is as a Purge and at all times necessary whenever a Blockage to the Surge. :-)

    1. Anonymous Coward
      Anonymous Coward

      Re: It is not only what you know, but how you also say and share it too that matters ‽ .

      > Whose words are drivering your vast mute geopolitically astute machines .... you know, the Source Servers of Current Present Confections Holding Media Hostage with a Dodgy Past Catalogue of Very Early Exceptional Successes to Protect and Prune/Prime Time Performance Enhance. ‽

      Man people go to secret prisons for saying stuff like that.

  9. simbalion
    Stop

    It would only burn intel

    It would not burn down the world to publish all the bugs you're fixing. It would only burn down intel.

    Why the hell is anyone still buying Intel's chips? They have been inferior, overpriced junk, since the 1990s.

    AMD doesn't have this issue? And threadripper CPUs are _killing it_. Google would not build 3 new datacenters, they'd replace all their Intel CPUs with AMD. So would Facebook, Twitter, so on and so forth. Intel would enter bankruptcy _overnight_.

    Which would be good for all of us, BECAUSE INTEL HAS ALWAYS SUCKED.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019