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 …

  1. amanfromMars 1 Silver badge

    Creating things which just aren't normally there is an Ancient Art ....

    .... with Post Modernist Fact for Present Current Fictional Tales Ploughing Almighty Virtual Trails

    "They're not that hard to exploit," Kroah-Hartman said. "The research has proved how to do it. The hard part is, you can't tell if somebody is exploiting it. But it is a known problem, you can reproduce it yourself. The Zombieland guys have a great demo. It's a real issue, you need to fix it."

    But it is not broken or in dire need of a fix whenever bounty delivers its temptations. You might like to realise and enjoy it as a SMARTR Stealthy Feature in a Bug Infested and Virus Invested PlayScape.

    1. Anonymous Coward
      Anonymous Coward

      Re: Creating things which just aren't normally there is an Ancient Art ....

      I raise my space helmet to you, man from Mars, for your eloquence. I do hope you came in peace.

  2. RichardBarrell

    Props to Kroah-Hartman for giving credit to the OpenBSD people for getting paranoid about SMT first. ;)

    1. Yet Another Anonymous coward Silver badge

      Or for deciding for you that you are building 2-3 new data centers

      1. Natalie Gritpants Jr

        How many organisations that run data centres just take the distro defaults?

        1. DougS Silver badge

          Most of them, if you count RHEL as a distro default.

      2. BinkyTheMagicPaperclip Silver badge

        OpenBSD is concerned about security before all else. If you want to re-enable smt, you can via sysctl.

  3. Anonymous Coward
    Anonymous Coward

    Must have a lot of minions

    To do 20 patches a day. Fully regressed non-trivial fixes (that is, understand, create, test, release) are more like 2 fixes a week per person... Oh, and don't forget to provide performance impact for at least 4 different workloads. And go to conferences to tout those 20 patches a day... or maybe the implication is just applying 20 patches a day, that seems more reasonable, someone else does the heavy lifting. But then the comment about creating CVEs is meaningless, that is a job for whoever is doing the heavy lifting...

    1. Bronek Kozicki Silver badge
      Linux

      Re: Must have a lot of minions

      His main job is merging the fixes from the main branch into stable kernel releases. He needs to understand them, but is not writing them from the ground up.

  4. Dan 55 Silver badge
    Trollface

    "Open BSD was right, he said."

    Those who do not understand Open BSD are condemned to reinvent it, poorly.

    1. asdf Silver badge

      Re: "Open BSD was right, he said."

      Now if Firefox on X Windows could run for more than few minutes before freezing the display (even alt control F2 etc doesn't work) under OpenBSD on my banking USB stick on my work Thinkpad. Secure by default yes but decent hardware support not so much.

      1. cb7

        Re: "Open BSD was right, he said."

        Try a decent USB stick

        1. asdf Silver badge

          Re: "Open BSD was right, he said."

          Patriot XT so yeah your probably right. Honestly I think it might be because of the docking station hardware support not being so robust.

          1. asdf Silver badge

            Re: "Open BSD was right, he said."

            Badly off topic now granted by for kicks installed i386 version instead and voila no lock up. Woot at least until they kill off the architecture but hopefully by then whatever is fubar (guessing an X video driver extension or something) in amd64 will be resolved. If I was a good netizen I would track it down, report it and give back and all that but meh I suck. Works for now will do for now.

  5. Baldrickk Silver badge

    Quick question

    How many attacks exploiting spectre and it's ilk have been discovered in the wild so far?

    I'm curious.

    1. doublelayer Silver badge

      Re: Quick question

      That question is difficult to answer. The main reason is that these aren't of particular concern to single-user machines. Of course one might want access to protected memory on those, but an evil person is more likely to have a better way of gaining access to data on a less secure user machine. This type of vulnerability is more useful in penetrating the protections in place on a machine running VMs for multiple people or for multiple purposes. The other problem is that you can't easily detect this by a signature or other file characteristic. Only by observing the operation of a program can the behavior be detected, and the overhead required to do that to everything is prohibitive.

      All that said, the best answer is "not very many". It's not easy to do, it's relatively slow, and it's only useful in a few circumstances. You probably shouldn't fear this vulnerability as much as many others. But that's not to say it's unimportant, as there are lots of things someone could do with it.

      1. big_D Silver badge

        Re: Quick question

        Yes. If you are running a web server or are running on a cloud, it is an issue.

        For businesses who run on-premises or for individual users on their PCs, it is less of an issue.

        The proof of concepts have been shown to get the private keys from other instances over a hypervisor. That is a serious risk for multi-tenant servers. But it would only be highly targeted attacks, which means they would be hard to detect and you have to find it, before you know you are being attacked - and if the attack is running on somebody else's instance on the shared server, you may never know, especially if they don't have any AV software or other security in place.

        1. Michael Wojcik Silver badge

          Re: Quick question

          The original Javascript SPECTRE attack might well have been a big deal had fixes not been pushed out before publication, because it would have been easy to deploy against normal users. It's a good example of responsible disclosure working as intended.

    2. jeffdyer

      Re: Quick question

      I would say none. It's hard enough to write your own multi threaded application and synchronize data between threads. But even if you can read someone else's bytes, actually knowing what that data represents (in someone else's application) is impossible.

      1. Traveller from the outer rim

        Re: Quick question

        This is not a lot harder than exploiting buffer overruns. You still need to understand the code and memory space of the process you are trying to attack. The cool thing with this is that you can do it without anyone noticing it ...

      2. Stuart Castle

        Re: Quick question

        Knowing what that data represents is difficult. Not impossible. It's made a lot easier if you have some knowledge of the format the data is likely to take. This is possible if the data is from, for example, a widely-used library or application. You could even potentially look for credit or debit card numbers (as these follow a strict format).

      3. Anonymous Coward
        Anonymous Coward

        Re: Quick question

        If you know what you’re looking for e.g. a sequence of bytes that looks like a private key, and you have the source code of the system, then it becomes much easier.

      4. Michael Wojcik Silver badge

        Re: Quick question

        But even if you can read someone else's bytes, actually knowing what that data represents (in someone else's application) is impossible.

        The many successful MDS demonstrations, going back to the original SPECTRE paper, show that you are utterly incorrect.

        So do many other untargeted-exfiltration exploits, such as Heartbleed. In fact it's often very easy to determine how to correctly interpret exfiltrated data.

        When the Morris Worm came out, there was much public sentiment that Morris was some sort of wunderkind and overflowing the fingerd stack was a stroke of genius, unlikely to be reproduced any time soon. Then Levy published "Smashing the Stack for Fun and Profit" in phrack, demonstrating that it was actually quite easy to develop a stack-smashing exploit, and suddenly everyone and their basement-dwelling cousin was doing it.

    3. DuncanLarge Silver badge

      Re: Quick question

      That was answered in the article, its not known how many because its not something you can easily detect.

      Its easy to exploit and hard to detect. win win for the black hats.

      I'd be more interested in if metasplot has this built in allowing any script kiddie to create something that exploits it after they get home from school.

    4. Hans 1 Silver badge
      Holmes

      Re: Quick question

      How many attacks exploiting spectre and it's ilk have been discovered in the wild so far?

      I'm curious.

      Hard to tell as attacks are very hard to detect.

      Do not pay attention to the others who replied to you as they did NOT read the article properly (and I cannot be bothered to downvote the lot):

      "MDS is where one program can read another program's data. That's a bad thing when you are running in a shared environment such as cloud computing, even between browser tabs."

      This "probably" means it is exploitable via JavaScript, so, basically, you're 0wned by a web page.

      So, yeah, it is a problem for average Joe if he has more than one program or browser tab open at the same time. The rest is wishful thinking.

      1. Michael Wojcik Silver badge

        Re: Quick question

        This "probably" means it is exploitable via JavaScript, so, basically, you're 0wned by a web page.

        If you read the original SPECTRE paper, you'll see that one of their demonstrations was indeed implemented in Javascript. Before the paper (and associated CVEs) went public, major browser manufacturers implemented mitigations for that particular attack. Subsequently other MDS issues in browser Javascript engines were pointed out, and then mitigated, over a number of iterations.

        These days, it's likely difficult to mount a successful MDS attack in Javascript under a recent release of a major browser, particularly when hardware / firmware / OS mitigations against the most useful side channels are also enabled. I wouldn't rule it out, though.

  6. bolac

    It is not «almost» two years, it is literally two years. I am sure Greg and friends were working on these fixes before the issue went public (because of amazing investigation skills of El Reg).

    1. Michael Wojcik Silver badge

      Thanks. I'd forgotten the Register broke the story. (I'd only learned of it myself a week or so earlier, in an embargoed announcement by CERT. Sometimes there are benefits to being on a PSRT.)

  7. Nate Amsden

    makes sense

    If you are super paranoid and wanting to be the most secure you can be. Security is like backups. You have to judge for yourself what you are protecting against, and how best to protect that. What are the risks vs costs of the mitigation? For me it's easy, I believe these side channel attacks are WAY overblown and as such have actively avoided firmware updates from my vendors to patch them. At some point I'll buy a new enough system that it will probably include some of those firmware fixes, but so far I have not.

    But it's nice the firmware updates are there for those that want it.

    I also don't run cloud stuff. I have hosted my own email on my own server for more than 20 years now(same with my websites). I have managed internet facing infrastructure (100s of systems) for more than 20 years without a single known security incident(I have been involved in other security incidents with things that were managed by other teams or people though). So my track record and confidence is high with that in mind. I also don't run things that I'd rate as high risks for attacks, so that factors in as well. I admit that my situation is far from common, but it does annoy me to see so many folks treat security as an absolute. It's either secure or it's not. That's not true at all because there will always be security patches and vulnerabilities. Just because they haven't been publicly disclosed doesn't mean they aren't there, and in many cases doesn't mean they aren't actively being(perhaps highly targeted) exploited. Goes back to risk again of course.

    If you're one of those folks that doesn't feel secure unless they have the latest patch then well go do that, but security is a lot more than just making sure you have the latest patch (and in my opinion it's the other bits that count a lot more towards security than having the software up to the latest patch).

    1. Anonymous Coward
      Anonymous Coward

      Re: makes sense

      @Nate Amsden belief's and realiity

      You say you have managed "100s of systems" for more than 20 years and yet you also say that you have had no responsibility for security issues in that time and noticed no security issues whatsoever on kit you "managed". You go on admit that whilst "you" never had any security problems others working on what I presume to be these same systems did have?

      What exactly does "managing" systems in your opinion mean? I take it to mean that you had nothing to do with firewalls, antivirus, OS and application updates, would I be wrong in this assessment?

      You say you ran your own email server without any security issues for 20 years? is this server perchance running on your home LAN and was it switched on and accessible to the internet at any point?

      I ask as there have been lots of emails attacks of all kinds over the last 20 years going to all IPs with any email ports open and if you never noticed any of these then either you were very very lucky, blind or someone else did the "hard work" of protecting your system for you.

      Personally I am thinking the latter since no day has passed for me over the last 20 years even on my home network where there were no attacks blocked by my firewall.

      So in conclusion, whilst you do not believe that security is something you need to worry about and then when you admit that you have been oblivious to the security problems everyone else has seen for 20 years then I am not going to take your opinion on security very seriously, sorry even if you are running NIX then there have still been enough security issues for you to know that they exists in reality

      1. jtaylor

        Re: makes sense

        @Anon

        I appreciate Nate's nuanced and relevant comment. Not every server is multi-tenant, and mitigating sidechannel attacks has significant costs. He didn't say what you claim or in the way you claim it. I will reply from my own experience managing Internet-facing sites.

        What exactly does "managing" systems in your opinion mean? I take it to mean that you had nothing to do with firewalls, antivirus, OS and application updates, would I be wrong in this assessment?

        What an odd statement. Firewalls and antivirus servers are designed to survive in hostile environments. I've managed a few of these and never saw one compromised. "OS and application updates" is very broad and shouldn't be lumped in with security appliances.

        I ask as there have been lots of emails attacks of all kinds over the last 20 years going to all IPs with any email ports open and if you never noticed any of these then...[insults]

        Sure, that's Internet Background Radiation. SMTP is some of the less interesting stuff we see. What do you find remarkable about it?

        whilst you do not believe that security is something you need to worry about and then when you admit that you have been oblivious to the security problems everyone else has seen for 20 years then I am not going to take your opinion on security very seriously, sorry even if you are running NIX then there have still been enough security issues for you to know that they exists in reality

        You grasped the wrong end of the stick. Read again for comprehension. And consider how much we might care whether an anonymous person with incoherent ideas about Internet security will "take [our] opinion very seriously."

    2. Kiwi Silver badge
      Pint

      Re: makes sense

      Well said and thanks for posting.

      I'm the same (though not at the same scale) - I've not had reason to believe anything I've worked with has been compromised. Under attack, even DDoS level of attack (just once thankfully, lasting 14 or so hours IIRC, but nothing compromised. I did go over stuff heavily after the DDoS, removing the server's drive and rebuilding from good known sources then scoured the original drive (including checksum checks against original sources) for signs of compromise, but not one single byte out of place or failed checksum/date/size check.

      I even used to run a repair shop network where we often had infected machines connected to my network. Simple things could save a lot of headaches (eg the file store the customer machines could reach was built on RO DVD's housed in ROM-only drivers (not DVD-RWx, plain old DVD-R) - even if the 'nix permissions were somehow bypassed, it was physically impossible to write to the disks!)

      In that time I too was involved in hundreds of incidents involving others, but not my stuff.

      The AC who replied doesn't seem to grasp the basic concept of "managed by other teams or people" likely means systems you weren't responsible for and maybe not even using at any time. I did help clean up after some attacks and help some companies recover and rebuild their systems, but they weren't things I designed or built or ran, in fact often the first time I even heard of the firm was when they came to me for help.

    3. Robert Grant

      Re: makes sense

      security is a lot more than just making sure you have the latest patch

      As you correctly imply, it includes having the latest patch

  8. 9Rune5

    Intel inside embedded

    All those embedded devices out there

    Are there many embedded systems using an Intel HT-capable CPU? (where upgrades won't come easily?)

    I enjoyed his answer vis-a-vis AMD. I'm very happy with my Ryzen CPU that I bought a year ago.

    1. Bronek Kozicki Silver badge
      Linux

      Re: Intel inside embedded

      There are two different issues here:

      1. old kernels have bugs, all kinds of them. Many of the bugs are security holes. Embedded devices are built on some old, randomly selected kernel and never updated - so they "accumulate" (in a passive manner) security holes which are never patched. The same applies to Android phones which do not receive vendor updates, BTW.

      2. some of the security bugs are not in the kernel; the patches in the kernel are just workarounds for security related bugs in the CPU hardware itself, e.g. timing attacks which can read one-bit-at-a-time from some hypothetically protected part of the address space. Computers are fast and one-bit-at-a-time can leak a significant amount of data e.g. a private key. The workarounds in the kernel come with performance overhead and also hit intel much more frequently than they do hit AMD. In particular, there either are no good workarounds for some security bugs related to Intel hyperthreading, or GKH is so fed up with merging those that he does not trust the whole edifice. Meanwhile, the equivalent AMD technology appears to be safe.

    2. werdsmith Silver badge

      Re: Intel inside embedded

      I enjoyed his answer vis-a-vis AMD. I'm very happy with my Ryzen CPU that I bought a year ago.

      ---

      That's good. I'm not sure our personal PCs is where he was aiming though.

      1. 9Rune5

        Re: Intel inside embedded

        I'm not sure our personal PCs is where he was aiming though.

        Sure, but... I have been asked in the past to cough up suggestions for what server hardware to buy, and who knows, I might be asked again (retirement is still 20+ years away).

        So, based on my experience with my own personal rig and articles like this one, I am very likely to push for AMD at every opportunity I get.

        Regardless of all that, it is good to see AMD being competitive again. Quite a relief actually.

    3. DuncanLarge Silver badge

      Re: Intel inside embedded

      Speculative execution is a very old bit of tech and exists in some form in many CPU designs from all sorts of architectures.

      Embedded intel devices may be running on a 386, 486 or pentium if they are older and dont have this issue but anything that embeds a pentium 4, xeon or Atom does. The question is if it is enabled.

    4. phuzz Silver badge

      Re: Intel inside embedded

      But embedded devices are unlikely to be running multi-tennat VMs, which is the main risk for this type of bug.

      To exploit this type of bug, an attacker has to have some way of running code on your computer. If your embedded device is (eg) a firewall, that's not going to happen unless they can leverage some other kind of flaw in order to execute code of their choosing, and most bugs of that type will give them full root access anyway (the state of embedded security being what it is), so by that point they don't need to use Spectre.

      So if your choice is between something running Intel SMT, but with well written software that's continually supported, or a different CPU but standard embedded software (ie release once then abandon), I'd go for the Intel.

      1. amanfromMars 1 Silver badge

        Re: Intel inside embedded and enmeshed

        To exploit this type of bug, an attacker has to have some way of running code on your computer. If your embedded device is (eg) a firewall, that's not going to happen unless they can leverage some other kind of flaw in order to execute code of their choosing, and most bugs of that type will give them full root access anyway (the state of embedded security being what it is), so by that point they don't need to use Spectre. ... fuzz

        If attacked by this type of computer bug exploitation, is the target of interest the computer user, which may or may not be your very good self.

        Whenever not all bugs are bad are some AWEsomely Great and well worthy of Prime Private/ Premium Pirate Consideration in Future Virtual Operations Spaces ..... with Spookily IntelAIgently Serviced and Servered Places.

        And one can't buy them for they are exceptionally expensive. It is just as well then there are countless innovative buy-in schemes with SMARTR Investors in Futures Delivering Plots.

        Are we chatting outsider/insider information dealing there? I'd be wonderfully surprised to hear of any financial or of any possible computer code violations forthcoming from that shared intelligence. It is not as if it is secret whenever all is so surely shared here ...... and for Showing New Pleasant Present Creations to Vast IntelAIgent Audiences.

        Would you Like to Help Assist and get Thoroughly Excited by the Simply Addictive Process which Drivers Full Wilfull Participation to Explosive Mutually Beneficial Climaxes.

        Tell me that aint Holy Grail Central and we may both still have a lot to learn, but for now I'll just stick to the tales and trails that try passionate temptation to prove that it is. :-)

        That sounds like a Search for Heavenly Grounds has Supplied Almighty Bounty there. What's not to like?

        1. Anonymous Coward
          Anonymous Coward

          Re: Intel... ...enmeshed

          The post is required, and must contain zeroes and ones

          alright then

          https://youtu.be/70iHe2zNtII

          jesus jones -- zeroes and ones

          (-;

  9. Richard Boyce

    Buying Intel

    Is it time, or past time, to fire people for buying Intel?

    1. vgrig_us

      Re: Buying Intel

      And do what? Buy amd ryzen 3000 series with broken rng making systems unbootable? Google it and see for yourself how scary amd bug is.

      1. Dan 55 Silver badge

        Re: Buying Intel

        It's only systemd distros which are unbootable. Poettering decided calling the kernel to get a random number wasn't good enough for him. You know, the kernel routine which mixes in other sources of entropy instead of just using the CPU's entropy generator. Instead he just calls RdRand, which also has bugs on some Intel chips and doesn't exist before 2012.

        1. Tomato42 Silver badge

          Re: Buying Intel

          > It's only systemd distros which are unbootable. Poettering decided calling the kernel to get a random number wasn't good enough for him

          get off the bandwagon, you'll end up in a ditch

          the problem was that the kernel needed entropy but it didn't trust RdRand, with no entropy and no services starting the system would lock up because the init system was waiting for kernel random pool initialization (getrandom() won't give out bits before that happens)

          that is fixed with the very newest kernel (5.4) after Linus merged jitter entropy generator: https://lwn.net/Articles/802360/

      2. Hyper72

        Re: Buying Intel

        The RdRand bug was fixed in a BIOS update that all motherboard manufacturers have made available.

        1. phuzz Silver badge
          Stop

          Re: Buying Intel

          It's not available for all motherboards, I know because its not available for my MSI x470 board yet. And that's a board that's still getting regular updates.

      3. Richard Boyce

        Re: Buying Intel

        That's not scary, it's annoying. Big difference. A fix is also being distributed.

        1. vgrig_us

          Re: Buying Intel

          To all of you who don't think rng bug is scary - how many applications use cpu rng only? Do you know? VPN clients? And amd keeping this bug quiet, notifying users only buy email, no posts on their website (as far as I know)?

          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!

          1. Kiwi Silver badge

            Re: Buying Intel

            can't believe all of you just shrugging it off!

            Most of my stuff is AMD. I tend to run one or few VMs on a regular basis, sometimes even play games in some of them sometimes do other stuff.

            Thus far the problem - well the first I heard of it was reading your post a few minutes back. Hasn't been an issue so far and probably won't be, if it ever is I'll deal with it. Till then, enjoy a good hearty shrugging. I'll put it on my to-do list just after taking a post-Boxing Day dump (for the year 2258 - I might not be around then to do something about it though).

          2. 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*

      4. BinkyTheMagicPaperclip Silver badge

        Re: Buying Intel

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

  10. Anonymous Coward
    Anonymous Coward

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

  11. 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.

  12. 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!

  13. 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.

  14. 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...

  15. 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.

  16. 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?

  17. 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.

  18. 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.

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