back to article Meltdown, Spectre: The password theft bugs at the heart of Intel CPUs

The severe design flaw in Intel microprocessors that allows sensitive data, such as passwords and crypto-keys, to be stolen from memory is real – and its details have been revealed. On Tuesday, we warned that a blueprint blunder in Intel's CPUs could allow applications, malware, and JavaScript running in web browsers, to …

  1. lglethal Silver badge
    Go

    Can you clarify?

    Can you clarify what you mean by all out-of-order execution Intel processors?

    I havent heard that terminology before. Are we talking i3/i5/i7 processors? Or just older processors?

    1. Anonymous Coward
      Anonymous Coward

      Re: Can you clarify?

      All out of order execution Intel processors means everything from Pentium Pro on, the only exceptions newer than that are Itanium and Intel Atoms older than 2013, both of which are in-order execution only.

    2. eldakka

      Re: Can you clarify?

      Out-of-order execution

      In computer engineering, out-of-order execution (or more formally dynamic execution) is a paradigm used in most high-performance microprocessors to make use of instruction cycles that would otherwise be wasted by a certain type of costly delay.

      ...

      In 1990s, out-of-order execution became more common, and was featured in the IBM/Motorola PowerPC 601 (1993), Fujitsu/HAL SPARC64 (1995), Intel Pentium Pro (1995), MIPS R10000 (1996), HP PA-8000 (1996), AMD K5 (1996) and DEC Alpha 21264 (1998). Notable exceptions to this trend include the Sun UltraSPARC, HP/Intel Itanium, Transmeta Crusoe, Intel Atom until Silvermont Architecture, and the IBM POWER6.

      ...

      The Intel 'Core' architecture (i3's, i5's, i7's etc) are basically a derivation of the Pentium Pro that, as per the referenced wikipedia page, introduced out-of-order execution in 1995.

      1. lglethal Silver badge
        Thumb Up

        Re: Can you clarify?

        Cheers guys! :)

      2. Daggerchild Silver badge
        WTF?

        Re: Can you clarify?

        "Notable exceptions to this trend include the Sun UltraSPARC ..."

        Wait... you mean my stack of old Sun kit has suddenly turned into a goldmine?

        1. Anonymous Coward
          Stop

          Re: Can you clarify?

          > Notable exceptions to this trend include the Sun UltraSPARC

          Not true. See this link and this link and this link [Warning: last two URLs are PDF].

          Dynamic branch prediction, instruction prefetch+decode and speculative execution were first introduced in the UltraSPARC-IIi.

    3. Anonymous Coward
      Anonymous Coward

      Re: Can you clarify?

      These CPU are well out of order

  2. eldakka

    Error in article

    These have been grouped into two logo'd and branded vulnerabilities: Meltdown (Variants 1 and 2), and Spectre (Variant 3).

    Other way around, based on the preceding CVE list, it should be "Spectre (Variants 1 and 2), and Meltdown (Variant 3)."

    Can't use the corrections link when I don't have an email client installed...

    1. Dan 55 Silver badge

      Re: Error in article

      Also grouping two variants under one name allows Intel PR to work their magic and claim others are affected by the same thing too.

      Well some AMD CPUs are affected in a non-standard kernel.configuration but the fix for that variant doesn't slow down kernel system calls as much.

      1. This post has been deleted by its author

  3. Dwarf

    Extraction rate is a function of RAM capacity.

    If the extraction rate is a function of RAM capacity, then there must be a benefit in Increasing RAM, just like bit lengths are increased to improve resistance to brute force in security functions.

    Cloud vendors and virtualisation providers stack machines high with RAM to get better consolidation ratios, so does it follow they are better protected ?

    1. Anonymous Coward
      Anonymous Coward

      Re: Extraction rate is a function of RAM capacity.

      Given that large amounts of RAM are used to cram in many virtual machines, I'd say they're not "better protected", in fact quite the opposite. You'd have a single physical attack surface containing many machines which can be compromised, which in turn represent many more virtual attack vectors. It might take you longer to dump the physical hosts entire memory, but you'd get access to many more VMs for your increased effort. Also consider that one VM owned by one customer could potentially dump out memory of another customers machine that just happens to be running on the same physical host.

      1. Dwarf

        Re: Extraction rate is a function of RAM capacity.

        Think you missed the point I was trying to make. The volume of data is higher, therefore it will take more time to get anything useful out, hence slowing down the attack. Sifting the useful bits from the non-useful bits takes more time again and who's to say that the couple of bytes you got from VM1 and couple from VM27 are any good without the rest that has not been recovered yet.

        I accept that it doesn't fix the problem, but it would buy a lot of time.

        1. Wayland

          Re: Extraction rate is a function of RAM capacity.

          Dwarf, you're thinking like a monk transcribing the Bible. The printing press was invented and then the computer. It's not going to take a computer very long to sniff out the password and keys from a big memory dump.

  4. Destroy All Monsters Silver badge
    Pint

    Good stuff!

    Maybe there will be a Hollywood movie.

    1. Adam 1

      Re: Good stuff!

      UPLOAD VIRUS

      1. Anonymous Coward
        Anonymous Coward

        Re: Good stuff!

        Bleeep Bleeeep KLAXON

        "Our firewall is getting penetrated"

        "Fsck, I should haven bought Intel gear, I KNEW that discount was suspicious. Help me type on this keyboard, fast!!"

        1. Dan 55 Silver badge
          1. Haku
            Coat

            Re: Good stuff!

            Those NCIS & Castle clips have it all wrong, this is how modern day hacking scenes should be played out, as demonstrated by The Shatner:

            Blinking and beeping and flashing!

            1. MrT

              Re: Good stuff!

              But where's the Unix expert when you need one?

              Cool...

              1. anonymous boring coward Silver badge

                Re: Good stuff!

                Not clicking on the link, I knew it must be from Jurassic.. Classic!

      2. ee_cc

        Re: Good stuff!

        From a Macintosh PowerBook

    2. Haku
      Trollface

      Re: Good stuff!

      Hollywood movie? Don't be silly, they'd just be wasting their time and money, nothing can top the film "Hackers" for its computer hacking realism!

      1. Matthew 17

        Re: Good stuff!

        Hackers was a great documentary, I always ensure the brightness on my terminal is sufficiently bright to project onto my face.

        Also I've seen that War Games is getting a remake, that should be stopped at once.

        Maybe Intel can help.

        1. Florida1920

          Re: Good stuff!

          @Matthew 17

          Also I've seen that War Games is getting a remake, that should be stopped at once.
          Starring Kim Jung Un and Donald Trump. This time it will be for real. And there will be no winner.

          1. Spanker

            Re: Good stuff!

            Remember that Sweeney episode with the hackers?

            Seemed utter science fiction at the time and see how Regan scoffed at the idea of computer crime being of any importance.

          2. PaulFrederick

            Re: Good stuff!

            Don't be such a silly goose. Of course there's going to be a winner. There's always a winner. We're going to be the winners too. Because our button is a lot bigger than Kim's is.

    3. Anonymous Coward
      Anonymous Coward

      Re: Good stuff!

      Maybe a class B movie for TV.

    4. arctic_haze

      Re: Good stuff!

      Maybe there will be a Hollywood movie.

      With billboard sized computer screens and passwords written in size 128.

  5. A Non e-mouse Silver badge

    Intel CEO

    And just before Christmas, who sold most of their stock in Intel? Intel's CEO.

    www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

    1. amanfromMars 1 Silver badge
      Mushroom

      Re: Intel CEO avoiding a personal hit. A dream scenario at best whenever regulators are bought.

      Just a coincidence, A Non e-mouse ........ not.

    2. Anonymous Coward
      Anonymous Coward

      'Who sold most of their stock in Intel?'

      As per Equifux, any investigation will be internal, and will quickly rule that everything the CEO did was fine - nothing to see here!

      1. MrT

        Re: 'Who sold most of their stock in Intel?'

        The Intel CEO process was operating as designed...?

    3. Ken Hagan Gold badge

      Re: Intel CEO

      It was noted in another thread that executives have to give months of notice before trading their own shares, so this is probably innocent. On the other hand, the article indicates that the bug was reported last summer. I don't know how much notice is actually required, but it is possible that there are legitimate questions to answer.

      However, whilst the impact of this bug is obvious to me, it may not be obvious to a CEO. If I went to *my* boss and said there is a flaw in almost every product we've produced in the last 20 years which is financially quantifiable (at least for cloud users, the impact of this bug *can* be measured in dollars) and is by design so we can be sued to pieces ... he might not believe me.

      1. Anonymous Coward
        Anonymous Coward

        "If I went to *my* boss and said there is a flaw"

        That usually depends on who you are - what position you hold in the company, and of course, how much pointy-haired the boss is.

        Anyway, usually bosses may listen when they hard words like "shares downfall" - "legal issues" - "recall and replacements", etc. etc. - even when they can't understand the technical details.

        1. Alistair
          Windows

          Re: "If I went to *my* boss and said there is a flaw"

          "words like "shares downfall" - "legal issues" - "recall and replacements", etc. "

          I've found that the phrase "Legal liability of $xxx,xxx.xx per incident" really gets their attention.

    4. Anonymous Bullard

      Re: Intel CEO

      The CEO didn't realise.

      Think about it - the best fix is to replace the hardware.

    5. Anonymous Coward
      Anonymous Coward

      Re: Intel CEO

      Noted that the reporter was extreamly suspicious of his motives even back then.

      Can you get more blatent insider trading? This guy should stripped of his shares not allowed to profit from them.

      1. The Rambling Man
        Coat

        Re: Intel CEO

        As has been quipped elsewhere: Intel Inside(R) trading

    6. Wilseus

      Re: Intel CEO

      If it's not a coincidence, wouldn't that constitute insider trading?

      (Genuine question)

  6. DropBear

    So... protected once again by sheer anti-establishment pig-headedness and obsolescence...? The just-pre-FX AMD Phenom II series doesn't seem to be mentioned in any context... :P

    1. nematoad
      Unhappy

      Hold on.

      Don't get too complacent.

      From reading some comments and posts both here on El Reg and elsewhere it seems to me as if a blunderbus approach to fixing these snafus is being contemplated.

      Even though AMD have said that their CPUs are only affected minimally from what I have read all CPUs will be targeted by the patches whether they need it or not. So that AMD and ARM will be slowed down as well as Intel stuff.

      Now it may well be that I have got hold of the wrong end of the stick, and I hope I have, but if true then a lot of collateral damage will done and we will all suffer from this mess.

      1. DropBear

        Re: Hold on.

        That's weird, I was under the distinct impression of having read about AMD submitting a patch explicitly to _prevent_ the "fix" activating on its processors. Granted, there's a bit too much confusion going around on what does what / affects precisely what / implies precisely what at the moment.

        1. Known Hero

          Re: Hold on.

          Your both asking the questions I'm interested in !!!

          from what was in the article it seemed as if the researcher's were going out of their way to make it work on AMD and even when they could prove it possible it wasn't easy.

          *Disclaimer I am a bit of a AMD fanboi, not so much that I don't imagine AMD are not affected by this just hoping not.

          1. Naselus

            Re: Hold on.

            AMD are unaffected by Meltdown, but most (including the new Ryzens) are still vulnerable to Spectre. Spectre is harder to perform, but also much harder to patch.

          2. AdamWill

            Re: Hold on.

            "Your both asking the questions I'm interested in !!!"

            The disabling of PTI (and associated performance impact) does not happen on AMD CPUs, in the Linux kernel fixes at least (can't speak to other affected OSes).

            "from what was in the article it seemed as if the researcher's were going out of their way to make it work on AMD"

            Rather the opposite, at least so far as Google's team is concerned: they state in their post "Our research was relatively Haswell-centric so far. It would be interesting to see details e.g. on how the branch prediction of other modern processors works and how well it can be attacked." They did test their PoC exploits against AMD CPUs, and state how badly they are affected by each one, but they appear to have focused on Haswell's design in actually *developing* the attacks.

  7. Anonymous Coward
    Anonymous Coward

    Has the collective IQ of the tech world hit rock bottom?

    Seems like we're sleepwalking to the greatest clusterfuck in tech history. Smart devices everywhere but no actual Smarts. Is there something in the water / air lowering IQ? Speaking of air, mines the PC getting air-gapped.

    "A mega-gaffe by the semiconductor industry. As they souped up their CPUs to race them against each other, they left behind one thing: security."

    1. Anonymous Coward
      Anonymous Coward

      Re: Has the collective IQ of the tech world hit rock bottom?

      It's the curse of the presentation layer people.

      If it looks shiny, ship it. No matter whether it's fit for purpose, no matter whether it's got serious design flaws, which will inevitably come back to bite the purchasers and users in the backside, just ship it. And if anyone dares question the dominance of shiny over well-engineered, the heretics are defined as "not a team player".

      Been that way for at least a couple of decades in quite a few "leading tech companies" and industry sectors. Companies and people that cared about decent engineering have largely vanished from the business.

      1. not.known@this.address

        Re: Has the collective IQ of the tech world hit rock bottom?

        Shiny sells, Marketing and Finance don't care about what might happen a few years down the line as much as the bottom line today. Shareholders don't care about the product as long as they get their dividend. Management don't care about customers other than as a source of income. Customer Support is seen as a necessary evil that gets the bare minimum of funding to put a layer of separation between the people making decisions and the customers who enjoy the "benefits" of those decisions.

        This is obviously an exaggerated description and not representative of many companies in the Real World but it does, unfortunately, seem to bear an annoying resemblance to some of them, from IT suppliers to retail businesses, vehicle manufacturers and holiday companies...

    2. Anonymous Coward
      Anonymous Coward

      Re: Has the collective IQ of the tech world hit rock bottom?

      Perhaps Facebook and smartphones are lowering IQ?

      Also, "natural selection has not stopped": "genetic contributions to intelligence and educational achievement are currently disfavoured by natural selection. In evolutionary terms, it seems, humans are now brainy enough" (https://www.economist.com/news/science-and-technology/21732803-it-does-however-no-longer-seem-favour-braininess-data-half-million)

      But it doesn't matter, because Artificial Intelligence will save us!

      Air-gapping is a bit over-the-top. Disabling JavaScript should mostly solve the problem. Don't run untrusted code.

      1. Dan 55 Silver badge

        Re: Has the collective IQ of the tech world hit rock bottom?

        "Genetic contributions to intelligence and educational achievement are currently disfavoured by natural selection. In evolutionary terms, it seems, humans are now brainy enough"

        As illustrated by Idiocracy.

        1. TRT Silver badge

          Re: Ooh look.... Shiny!!!

          Also known as the hardware distraction layer.

    3. Destroy All Monsters Silver badge
      Coat

      Re: Has the collective IQ of the tech world hit rock bottom?

      Seems like we're sleepwalking to the greatest clusterfuck in tech history. Smart devices everywhere but no actual Smarts. Is there something in the water / air lowering IQ? Speaking of air, mines the PC getting air-gapped.

      Well, people are suffering from infocrap overload everywhere and a sociopath and Wall-Street driven sales cycle. But also...

      The population-weighted cross-national mean IQ-score is 89.03, with SD of 12.89, for 123 nations. There are roughly 550,000 individuals in the included samples.

      So people overall may not be as smart as they think.

      1. Anonymous Coward
        Anonymous Coward

        Re: Has the collective IQ of the tech world hit rock bottom?

        That would imply the IQ test administered was flawed? There are countries exceeding a 100. I thought the test is defined such that the mean is supposed to be a 100.

        1. CrazyOldCatMan Silver badge

          Re: Has the collective IQ of the tech world hit rock bottom?

          That would imply the IQ test administered was flawed? There are countries exceeding a 100

          The only thing that IQ tests measure is how good you are at doing IQ tests..

          (I speak as a once-and-former member of MENSA who took the test as a teenager, specifically to check if I was brighter than my brother. I was - according to MENSA. However, he has a first-class honours degree, a masters and a PhD (in mathematics) whereas I have year 1 of an HND..)

    4. Kiers

      Re: Has the collective IQ of the tech world hit rock bottom?

      yeah...there's something in the air.....STOCK OPTIONS! why do u think it's said "money is the root of all..."

      1. CrazyOldCatMan Silver badge

        Re: Has the collective IQ of the tech world hit rock bottom?

        u think it's said "money is the root of all..."

        Actually - the original phrase is "the *love* of money is the root of all kinds of evil". Money itself is just a tool and a means to an end[1] and is, of itself, not bad.

        Doing anything and everything to gain money, on the other hand, is a Bad Thing[TM].

        As with (pretty much) everything, *why* you do things is as important as what you do.

        [1] The end being "buying stuff that I need to survive - stuff like food, shelter and cats".

    5. anonymous boring coward Silver badge

      Re: Has the collective IQ of the tech world hit rock bottom?

      A few decades isn't such a long time after all.

      I always was suspicious of taking shortcuts for performance reasons. MS had a good thing going with Windows NT, but then had to cram things into the kernel for short term performance gains, for just one irritating example. Auto-run this and that. Thousands of ways to hide auto-start of crap. MS is a friggin master of making things obscure and insecure.

      These things always have a way of catching up with us.

  8. Anonymous Coward
    Anonymous Coward

    Colour me surprised ....

    For years now, I have countered all the FOSS holier-than-thou attitude to security as being an illusion, unless you have checked the underlying silicon yourself. In these very forums.

    Now will people believe me ?

    1. Dave 126 Silver badge

      Re: Colour me surprised ....

      Yeah, because everybody has a hundred thousand dollar's worth of microscope sitting in their clean room, and the skills to remove the casing of the CPU, the years of education to understand what they see and the months to actually analyse it.

      It'd be quicker and cheaper to conduct your secure communications thus: fly to wherever your correspondent lives and go for a nice walk and a chat in the woods.

      1. Anonymous Coward
        Anonymous Coward

        Re: Colour me surprised ....

        I guess you're being obtuse ?

        AC wasn't suggesting you actually tried to verify the silicon.

        Just be aware that if you haven't. it's a potential vector for badness which no amount of open sourced code can counter.

        First rule of secure communications, is to assume that your communications aren't secure.

        1. Ken Hagan Gold badge

          Re: Colour me surprised ....

          "First rule of secure communications, is to assume that your communications aren't secure."

          It sounds nice, but if you take the position that your communications *are not* secure then logically there is no point in taking any steps to secure them.

          What you actually have to do is assume that they *might not be* secure in ways that you don't yet know and you should attempt to mitigate against those by layering security elsewhere and (if you have the resources) supporting attempts (by yourself or others) to learn more about the things you don't yet know. This philosophy is much less memorable, but leads to concrete suggestions for action on your part, so it is more useful.

          1. Naselus

            Re: Colour me surprised ....

            "It sounds nice, but if you take the position that your communications *are not* secure then logically there is no point in taking any steps to secure them."

            No, that's not logical at all. Assume you phone is tapped. Do you decide 'oh well, phone's tapped, may as well just email my secret plan direct to the FBI now'? Or do you just draw up a basic code to use on the phone?

            'Assume compromised' doesn't mean 'give up on security all together', it means 'implement additional layers of security even if you're supposed to be safe'.

      2. Doctor Syntax Silver badge

        Re: Colour me surprised ....

        "fly to wherever your correspondent lives and go for a nice walk and a chat in the woods."

        Remember, even trees have ears: https://www.theregister.co.uk/2015/10/02/win_a_6tb_western_digital_black_hard_drive_with_iel_regi/

        1. DropBear
          Trollface

          Re: Colour me surprised ....

          Easily solved. Just get on the next Space Shuttle sorry Soyuz / Dragon capsule and take a nice long spacewalk with your interlocutor in vacuum*, physically touching your helmets to convey vibrations the good old fashion style.

          * make an effort to try staying aware of any incoming laser beams trying to bounce off your helmet, you know, just to be on the safe side...

    2. Christian Berger

      This is why FOSS hardware designs...

      are actually working on verifying that the designs are correct.

      https://media.ccc.de/v/34c3-8768-end-to-end_formal_isa_verification_of_risc-v_processors_with_riscv-formal

    3. Anonymous Coward
      Anonymous Coward

      Re: Colour me surprised ....

      It's not that people haven't believed that there are problems with the silicon but that you frame it as FOSS issue, possibly. If there's a problem with the silicon it goes well beyond OS unless a particular OS knows to look for that issue and develop around it. That, of course, is a sub-optimal process, but better than none at all.

      1. Dave 126 Silver badge

        Re: Colour me surprised ....

        So... a nice chat in the woods, then? :)

      2. John Brown (no body) Silver badge

        Re: Colour me surprised ....

        "If there's a problem with the silicon it goes well beyond OS unless a particular OS knows to look for that issue and develop around it."

        Ah yes, the bane of FOSS driver devs. GFX cards especially seem to end up with multiple bugs in the silicon and have undocumented s/w workarounds in the drivers (not that they are documented much, if at all, anyway)

    4. Doctor Syntax Silver badge

      Re: Colour me surprised ....

      "Now will people believe me ?"

      You mean we should believe each and every A/C because they're you. Even when you contradict yourself multiple times in the same thread?

    5. Anonymous Coward
      Anonymous Coward

      Re: Colour me surprised ....

      >> Now will people believe me ?

      There's nothing to believe... there is no such thing as perfect security which means every subsequent discussion claiming it is moot. There is no perfectly secure OS, perfectly secure silicon, perfectly secure system operator.

      Perfectly unintelligent claims do look possible.

    6. Mike 125

      Re: Colour me surprised ....

      >Now will people believe me ?

      I won't believe you, because you sound like a 'holier-than-thou' bellend. Just whinging on about how crap everything is helps nobody.

      It's pretty obvious that if we're serious about security, we need open hardware *and* software. The question is how to get there with the hardware.

      1. Dave 126 Silver badge

        Re: Colour me surprised ....

        Atreides Battle Language

        Weird, I have misremembered it as being a language based on chord-typing on someone's skin - long time since I read the Dune books - but the internet says it's just hand signals or specific-use spoken language.

    7. Anonymous Coward
      FAIL

      Re: Colour me surprised ....

      Now will people believe me?

      No, because FOSS has nothing to do with any of these hardware bugs.

      Witness the fact that Microsoft Windows is also affected. That being the farthest thing from FOSS that I can think of, except maybe Oracle's crap.

      You do know the difference between hardware and software, yes?

  9. Dave 126 Silver badge

    Lead time on new CPUs?

    When will Intel be shipping CPUs without these vulnerabilities? And obviously, I'd want to wait a few months after that to allow a window for other people to find any issues.

    I've been thinking about getting a new laptop for a while - lots of useful features have matured since my Core 2 Duo machine. Whilst my workload - causal / CAD - may not incur too much of a slow down, I may as well get a fixed CPU.

    Either that, or take a performance hit (which I won't notice because the CPU will be faster to begin with than the one I'm used to using) and shop around for a discount on existing stock.

    Thoughts?

    1. Anonymous Coward
      Anonymous Coward

      'Thoughts?'

      Get data slurped by Microsoft-Win10 or malware fucked by Intel. What's not to like? I'll be upgrading GPU, that's all. Fuck em both!

      1. Dave 126 Silver badge

        Re: 'Thoughts?'

        Any *constructive* thoughts? :)

    2. MyffyW Silver badge

      Re: Lead time on new CPUs?

      I'm certainly not keen to reward Intel et al with new business at the moment.

      1. Dave 126 Silver badge

        Re: Lead time on new CPUs?

        Well beyond Intel and AMD I don't have much of an option, seeing as my Playstation 3 Cell-powered cluster has achieved self awareness and told me to bugger off and leave it alone to contemplate its own navel.

        Hence the twofold question: Can this issue be rectified in new silicon, and what's the lead time on implementing fixes on modern CPUs?

    3. Ken Hagan Gold badge

      Re: Lead time on new CPUs?

      MS have previously said that they would not support Win7 on new Intel processors like Kaby Lake. Throwing away your old CPU may not be an option for some corporates.

      1. John Brown (no body) Silver badge

        Re: Lead time on new CPUs?

        "MS have previously said that they would not support Win7 on new Intel processors like Kaby Lake. Throwing away your old CPU may not be an option for some corporates."

        Does this mean Win7 won't run on Kabylake or just that they don't "support" it to the extent that some on-chip features or optimisations won't work and they won't be fixing that?

      2. anonymous boring coward Silver badge

        Re: Lead time on new CPUs?

        "MS have previously said that they would not support Win7 on new Intel processors like Kaby Lake. Throwing away your old CPU may not be an option for some corporates."

        This would be a good time then to make MS support Win 7 on newer processors. And, while we are at it, make them promise to never again break things just to try to sell new shiny crap. (To the tune a a few billion dollar's worth of a fine.)

    4. Anonymous Coward
      Anonymous Coward

      Re: Lead time on new CPUs?

      I think based on information to date that people *might* want to be asking about "lead time on OLD CPUs" (ie ones that don't have speculative/out of order execution).

      If people's systems can't cope without speculative/OoO execution, perhaps people might want to look into the benefits of older simpler software, that wasn't so bloated with shininess as to need the joys of inadequately tested processors underneath.

      Any experts on "product liability" laws care to comment here? It would seem unfortunate if the manufacturer of the defective products is the one who ultimately benefits because their customers have to pay again for hardware that wasn't fit for purpose when sold, because it wasn't properly architected, wasn't properly implemented, wasn't properly tested.

      And yes I have worked with a team validating an out-of-order microprocessor implemetation. It didn't need to do OoO but having it OoO made it shinier. It also made it less likely to be implemented correctly and less likely to be properly tested.

      And look where that leads.

    5. ByTheSea

      Re: Lead time on new CPUs?

      "I've been thinking about getting a new laptop for a while - lots of useful features have matured since my Core 2 Duo machine."

      Ditto my desktop. So I'm certainly interested in when, if ever, Intel will fix this in hardware.

      1. phuzz Silver badge

        Re: Lead time on new CPUs?

        Why keep looking at Intel?

        Early reports are that the kernel patches for part of this problem are causing 5-30% performance loss on Intel processors, and AMD chips tend to lag Intel by only about 5-30% for less money. So just go AMD.

    6. Anonymous Coward
      Anonymous Coward

      "When will Intel be shipping CPUs without these vulnerabilities? "

      Maybe Intel will attempt to sell Itanium again.

      Jokes aside, it needs a silicon redesign. Memory accesses should be checked anyway for privileges before moving anything to the cache, and probably performance will suffer as well.

      There could be other solutions, but they may be even more complex. And of course there are inventories to to sell... it can take many months.

    7. Anonymous Coward
      Devil

      Re: Lead time on new CPUs?

      > When will Intel be shipping CPUs without these vulnerabilities?

      Real Soon Now.

    8. CrazyOldCatMan Silver badge

      Re: Lead time on new CPUs?

      When will Intel be shipping CPUs without these vulnerabilities

      Don't hold your breath. First, they will have to negotiate *again* with AMD for the rights to the architecture...

  10. IHateWearingATie

    Maybe we dodged a bullet?

    Given it's taken super-boffins to find this one and no one has yet reported exploits in the wild, have we dodged a bullet on this one?

    Lots of fundamental development process rethinking required in the semi-conductor world required....

    1. MyffyW Silver badge

      Re: Maybe we dodged a bullet?

      Perhaps a little too early to reach that conclusion, hun. I'm placing more emphasis on patching than popping open the fizzy wine at the moment...

      1. Anonymous Coward
        Anonymous Coward

        Re: Maybe we dodged a bullet?

        Remember that entire disk open source encryption software that got canned a couple of years ago? Due to an unreported possible exploit not in the software?

        Possibly related?

      2. CrazyOldCatMan Silver badge

        Re: Maybe we dodged a bullet?

        more emphasis on patching than popping open the fizzy wine

        Live a little and do both. After all, what's the worst that could happen?

    2. jmch Silver badge

      Re: Maybe we dodged a bullet?

      "Given it's taken super-boffins to find this one and no one has yet reported exploits in the wild..."

      because NSA-types don't report such vulnerabilities. Who knows how long they've been exploiting it without anyone else knowing?

      1. Ken Hagan Gold badge

        Re: Maybe we dodged a bullet?

        @jmch: Yes, and for the avoidance of doubt let me say that your phrase "NSA-types" should be taken to include all the bad guys. We should not forget that whilst 99% of humanity does not look for ways to screw each other over, 99% of those who do are the kind of folks who won't share when they find a new way to do that.

        1. Will Godfrey Silver badge
          Happy

          Re: Maybe we dodged a bullet?

          @Ken Hagan

          I thought "NSA-types" was the all-inclusive term for bad types.

      2. Jim 68
        Black Helicopters

        Re: Maybe we dodged a bullet?

        I think NSA told me to avoid side-channels back in the 1980s.

    3. Doctor Syntax Silver badge

      Re: Maybe we dodged a bullet?

      "Lots of fundamental development process rethinking required in the semi-conductor world required."

      Or go back to some old ideas.

      Does anyone remember the Z80? Two sets of registers and an instruction to swap between them. It made for quick context swaps. There were no security advantages, of course, because back then there was no concept of security rings on an 8-bit processor.

      The same thing could be adapted to the modern world. Two sets of registers and two sets of cache (OK, for any given number of transistors it would mean reduced cache sizes for each half). That would mean that an independent address space could be kept for the kernel with only a single instruction to swap the context with one set having security privileges. Extra Brownie points if the cache split can be tuned to suit workloads. There might even be scope for adding more sets for quick changes between running processes.

      1. HmmmYes

        Re: Maybe we dodged a bullet?

        Surely that requires a single threaded kernel?

      2. Mage Silver badge

        Re: Z80 dual registers

        I used that for a round robin cooperative multi-tasking OS in early 1980s. The alternate registers used ONLY for the scheduler. It meant lower overhead and better reliability. Previously, like many others, I'd used it for the NMI to reduce latency.

      3. AndyD 8-)₹

        Re: Maybe we dodged a bullet?

        "Two sets of registers and two sets of cache" pretty much *is* the problem!

    4. Roo
      Windows

      Re: Maybe we dodged a bullet?

      "Lots of fundamental development process rethinking required in the semi-conductor world required...."

      Broadly agreeing - but I don't see this as an industry wide problem. There are plenty of well established tools and techniques in place that would catch this kind of thinko - but they all require a precise, complete and self-consistent definition of how the chip is meant to work. The x86 doesn't have such a definition in the public domain, and given the nature of the errata over the years there is plenty of evidence that Intel doesn't have one (or make use of one) in their design process either.

  11. Pen-y-gors

    " don't run untrusted code"

    For 99.9% of the planet that could be tricky. Disabling Javascript totally rather breaks the interwebs these days.Of course they could uninstall their browsers, and go back to Lynx, but realistically..?

    1. tiggity Silver badge

      Re: " don't run untrusted code"

      I have JS disabled on many sites, would be very happy if we returned to a JS free web!

    2. Christian Berger

      Re: " don't run untrusted code"

      "For 99.9% of the planet that could be tricky."

      That's actually a very big problem. For years people have believed that you can somehow "sandbox" code, so it won't be able to harm your system, and for years people have warned that this might be an illusion. Now we actually see yet another proof that it was.

      Now if we had some decent people at the W3C we would see Javascript being phased out.

      1. Doctor Syntax Silver badge
        Unhappy

        Re: " don't run untrusted code"

        More likely

        Now if we had some decent people at the W3C we would see Javascript being phased out them being ignored

    3. Doctor Syntax Silver badge

      Re: " don't run untrusted code"

      "Disabling Javascript totally rather breaks the interwebs these days."

      Most of the time I'll simply ignore a site that won't work at all without Javascript. If I think I really need it I'll see if I can selectively enable enough domains to make it work or see if the Google cached version is sufficient. Some sites manage to use so much Javascript as to break on some browsers even when fully enabled; eBay, I'm looking at your recent inability to display images in Seamonkey.

      1. Claptrap314 Silver badge

        Re: " don't run untrusted code"

        Don't try to apply for a job. Ever.

    4. Anonymous Coward
      Anonymous Coward

      Re: " don't run untrusted code"

      "Disabling Javascript totally rather breaks the interwebs these days.Of course they could uninstall their browsers, and go back to Lynx, but realistically..?"

      The trick is not to go back to Lynx, but to set your Firefox/Chrome user agent to it. I do this (using an eLinks user agent string), and enjoy simplified JS free versions of Office365 and gmail.

      Decent sites recognise it, and provide the simplified view above, others ignore it and you're in the same boat.

    5. Mage Silver badge

      Re: " don't run untrusted code"

      Install uMatrix plugin on Firefox. NoScript doesn't work on 52 ESR since 52.5.3

      1. John Gamble
        WTF?

        Re: " don't run untrusted code"

        ???

        I'm using 52.5.3 now, with NoScript working as per usual.

        1. Marrkk

          Re: " don't run untrusted code"

          I'm not surprised, as he said it's not working SINCE version 52.5.3, i.e., he found it to work on 52.5.3, but not subsequent versions. Congratulations, you have locked onto the last working version!

        2. Mage Silver badge

          Re: using 52.5.3 now, with NoScript working

          Yes, it should be working, No idea why the update to it disabled everything. I uninstalled and re-installed which got back everything except NoScript. However uMatrix seems less bother.

  12. Anonymous Coward
    Anonymous Coward

    Not only Chip Makers...

    "On Tuesday, we warned that a blueprint blunder in Intel's CPUs could allow applications, malware, and **JavaScript** running in web browsers"...

    You could argue it's not only the chip designers that have messed this up, you can leverage JavaScript to exploit this? That wonderfully high level, secure, scripted, sandboxed scripting language? :(

    1. Dan 55 Silver badge

      Re: Not only Chip Makers...

      As much as I hate to defend JavaScript, it's not JavaScript, it's the browsers' JIT compilers.

      One of the variants requires that compilers be changed and software recompiled, which means there's no real fix for malware written in assembler or someone still using an old compiler or software.

    2. Christian Berger

      Re: Not only Chip Makers...

      Well languages are essentially created equal, while exploits using this in JS might be less stable, there is no hard reason why it shouldn't be possible. After all, you only need attempts at memory access.

    3. Christian Berger

      Re: Not only Chip Makers...

      Well if the sandboxing depends on broken features of your CPU, then one CPU problem can cause all of that. We need to finally accept that running untrustable code from webservers on the client was a _really_ bad idea.

  13. Joerg

    Yeah sure.. AMD and ARM the sweet angels..! PLEASE!

    So Intel "the big evil" would be the one hit hardest by design flaws that AMD and ARM have too, uh?

    Because AMD and ARM are so sweet angels and their bugs and flaws don't stink as much, uh?

    AMD statements are beyond silly. Also it is pretty clear that AMD employees have been spread all over the 'net to attack Intel just like a few weeks ago they did using an Intel Management Engine bug as it was the end of the world and couldn't be fixed...

    1. Ken Hagan Gold badge

      Re: Yeah sure.. AMD and ARM the sweet angels..! PLEASE!

      "AMD statements are beyond silly."

      Are they? We appear to have proof-of-concept demos that work on Intel. If those don't work on AMD then the onus is on you (or, more likely, Intel) to demonstrate that it can be done. New information is coming to light at quite a rate and such demos may already exist or may exist by the time you read this reply, but it is not obvious to me that all OoO processors are necessarily vulnerable or are vulnerable in ways that cannot be patched in software, so "beyond silly" seems rather harsh.

    2. Destroy All Monsters Silver badge
      Meh

      Re: Yeah sure.. AMD and ARM the sweet angels..! PLEASE!

      How's the weather down in Santa Clara?

  14. tiggity Silver badge

    Upgarde

    A lot of people will be stuck as unable ti upgrade OS / browser.

    Plenty of old kit does not meet hardware spec of newer OS versions so has to stay marooned (and Firefox, Chrome etc only support a few latest & greatest OS versions - they do not support "vintage" systems)

    I would like to see OS fixes for older OSes (and browsers supporting older OSes)

    Plenty of people cannot afford to chuck out and replace old (running) kit - and its a real waste of resources to get rid of stuff that still works - I have various bits of kit with OSes that cannot be upgraded further.

    With most vulns, being sensible on scripting and sensible set up in firewall layers and intrusion monitoring software can make older OSes relatively safe, but these vulns cannot really be mitigated in that way & a game changer for trying to run vintage kit securely.

    1. BinkyTheMagicPaperclip Silver badge

      Re: Upgarde

      Supported OS will be patched. For everything unsupported, you shouldn't be connecting it to the Internet. End of story.

      If the hardware runs a multi million pound piece of equipment and can't easily be upgraded, air gap it.

      1. Anonymous Coward
        Black Helicopters

        Re: Upgarde

        But the control centre for my nuclear reactor only works on XP, and the emoticons for it don't work without an internet connection.

        1. Anonymous Coward
          Anonymous Coward

          Re: Upgarde

          > But the control centre for my nuclear reactor only works on XP

          Windows Embedded 2009 uses the NT 5.1 kernel and has extended support through 2019. I wonder if Microsoft has enough customers with support contracts that they'll be pressured into back-porting this fix to that old code tree.

      2. Anonymous Coward
        Anonymous Coward

        Re: Airgap shit

        "If the hardware runs a multi million pound piece of equipment and can't easily be upgraded, air gap it."

        That worked so well with Stuxnet didn't it. And Stuxnet was just the one that got the most publicity (which you apparently didn't see or don't want to understand). Lots of similar methods of defeating "airgaps" have existed and will exist.

        Get a clue or STFU.

        edit: Ill-inforrmed ignoramuses who have ended up in roles way beyond their competence carry much responsibility for the untrustworthy and dangerous mess which is today's InternetofThings, and now it also seems similar (but worse) trustworthiness problems apply to lots of other rather more expensive gear which have been built to favour shiny shit over simple and trustworthy.

        1. BinkyTheMagicPaperclip Silver badge

          Re: Airgap shit

          Airgaps include scanning removable media for viruses, and not allowing autorun facilities. Stuxnet was a state sponsored hacking tool deliberately designed to wreck infrastructure.

          If you have a nation state determined to infiltrate your systems you'd better be certain that all your security is watertight.

          Which includes making sure systems are fully up to date. So, fuck off.

          For practically everyone else, an airgap suffices.

          1. Anonymous Coward
            Anonymous Coward

            Re: Airgap shit

            "Airgaps include scanning removable media for viruses, and not allowing autorun facilities."

            How does even an up to date and uncompromised virus scanner detect a previously unpublicised exploit method ?

            How does trying to disable autorun prevent e.g. the kind of "specially crafted JPEG(or whatever) may cause unauthorised code execution" vuln which has been happening in commodity OSes for decades?

            Suggestions welcome.

    2. fnusnu

      Re: Upgarde

      Stop calling it vintage and start calling it for the obsolete crap that it is.

      1. Dr Dan Holdsworth
        Happy

        Re: Upgarde

        I wonder if, in the light of all this mess, Oracle will consider resuming development of SPARC processors...?

        1. captain_solo

          Re: Upgarde

          I wonder about that also...All of a sudden the mockery of the SPARC M7 Silicon Secured Memory scheme seems to have been premature.

          1. Anonymous Coward
            Mushroom

            Re: Upgarde

            > bla-bla-bla ... SPARC M7 ... bla-bla-bla

            How exactly do you know that SPARC M7 or M-whatever isn't affected by Spectre?

            Do you have a PoC program proving that it is not? If you do, please post the source code for it, in the open, for everyone to download, compile and test.

            I take it you don't have such a program, and you never will.

            You don't seem to understand even the basics of the Spectre hardware vulnerability.

  15. jon jon

    is this a surprise

    I've been wondering for some time how our overlords have been accessing pretty much anything they like with apparent impunity for years. Not any more.

    Basic design flaw, not picked up by any chip manufacturer.....sure.

    Makes complete sense.

  16. chrisbyrneham

    When do the lawsuits begin ? Class actions...

    So are these things fit for purpose now that they will have to run some 30% s l o w e r ?

    1. Ken Hagan Gold badge

      Re: When do the lawsuits begin ? Class actions...

      For anyone who pays for their time on a platform, "30% slower" equates pretty directly to a figure for damages. We won't necessarily see a class action though. Instead, we may find that cloud providers simply lower their charges for Intel-based VMs (to avoid being sued by their own customers) and then turn around to Intel and ask for a lump sum to cover it.

      For anyone running a system on average at anything below 70% of its rated power, it would be harder to come up with (and defend in court) a particular figure for damages. Those cases would be messy, so I don't expect too many of the little guys will take Intel to court.

    2. Anonymous Coward
      Anonymous Coward

      Re: When do the lawsuits begin ? Class actions...

      IANAL . but this is tricky to argue I think.

      If anything it's the SW vendor that you sue, they are creating the performance degradation. If there is some intel documentation stating that it is guaranteed to be secure, then yes a lawsuit would have potential.

      Intel instead would argue that the pre-KPTI implementation is a performance feature and does not guarantee security, and that SW should use a KPTI like implementation if security is to be improved. They will also not promise KPTI is secure either. This fits with the Intel PR blurb that stuff is working as expected.

      And SW vendors sell SW on an as-is basis - for eg you cannot sue them for any patches/bugs.

      Neither Intel nor the SW vendors promised anything here.. it's caveat emptor. So unless you can prove your evaluation of the processor and/or SW was affected by misleading statements from these vendors, the products are not sold guaranteeing security.

      So the court could rule that how you evaluated whether it was fit for your purpose was what was flawed.

  17. tiggity Silver badge

    Obligataory brexit link

    I noticed on the meltdown / spectre page small print:

    "This work was supported in part by the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 681402)."

    1. Paul Greavy

      Re: Obligataory brexit link

      Yeah, but seriously, what has the EU ever done for us.

    2. John Brown (no body) Silver badge

      Re: Obligataory brexit link

      "This work was supported in part by the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 681402)."

      One of the teams was an Austrian university so it's not a huge leap to realise one or more of the team or their resources was grant funded rather than a specific grant to do this specific research,

  18. Ken Hagan Gold badge

    Puzzled

    The description in the article would seem to allow a fairly simple fix in the OS.

    When the original page fault occurs, control is passed from user-space (or guest space) to kernel space (or host space). The handler can determine whether the faulting address is outside user-space or not. In fact, it probably already has to do that in order to process the fault. If not, the fault is legitimate and will be related to (say) stack guard pages or virtual memory paging. We wouldn't want to penalise those, so we proceed as usual.

    However, if it *is* outside user-space, I can't see any reason not to "punish" the application program (or guest kernel) by performing a full cache flush. This blocks the information disclosure. It is obviously quite costly, but as long as the bill is charged to the offending application (or guest, and in the case of cloud providers that will really mean *charged* so the provider is still happy) then it doesn't count as a DoS attack and no properly written application will ever have to pay the bill.

    What have I missed?

    1. Anonymous Coward
      Anonymous Coward

      Re: Puzzled

      You don't need to have a page fault in order to succeed at the exploit.

      Because the program contained two (or more) possible paths of execution, and the CPU took all of them speculatively, the fault is inhibited because the naughtiness took place in a branch that ultimately the program wasn't supposes to take. Somehow the data leaks over from the path it wasn't supposed to take.

      Imagine you have a time travel gizmo. The only catch is that your memory gets erased when you travel back in time. You try to break into some highly secure facility to steal some documents. You systematically take every possible corridor, and push the button in the gizmo to send you back in time just before the guards shoot you. Down one corridor you find the secret documents but get shot every time. Somehow you find a way to trick the forced amnesia, and get away with seeing the secret documents without technically ever seeing them because time paradox.

      Anonymous, because there's no such thing as time travel.

      1. Ken Hagan Gold badge

        Re: Puzzled

        Thanks. Yes, I had missed the implications of the "speculative" bit, which is a little embarrassing. Since it is speculative, there is no actual page fault as far as the kernel (or host) is concerned.

        Quite unpleasant really ...

        1. Anonymous Coward
          Anonymous Coward

          Re: Puzzled

          "Yes, I had missed the implications of the "speculative" bit, which is a little embarrassing."

          Assuming you're an outsider, you're excused. Those chip architects, designers, verification teams, etc, implicated here don't have that excuse, and nor do their mismanagement chains.

          1. Claptrap314 Silver badge

            Re: Puzzled

            I spent 10 years doing microprocessor validation. This was my first idea. Then I realized that the OS never sees the instructions that fetch the cache line. <doh> Note that it might be easier for attack code to do a divide by zero to cause an exception than to outsmart the branch prediction hardware.

            During my ten years, I did my share of fussin' & cussin' about designers just doing things wrong. But I'm also a mathematician. My brain is wired for this stuff, and it STILL took years & years of my professors pointing out where my errors were before they even began to think about letting me into the program.

            This is a side-channel attack on the warmth of the cache. If you think you can, please detail how the hardware can prevent such an attack without substantially compromising performance. I've got some ideas, but after realizing that my OS fix would not work, I'm going to shut up about them for a while...

            1. Anonymous Coward
              Angel

              Re: Puzzled

              > [ ... ] please detail how the hardware can prevent such an attack without substantially compromising performance.

              All the compiler-based mitigation measures that I've seen thus far carry a performance penalty. How much of a penalty, YMMV. It's execution context-dependent.

    2. Anonymous Coward
      Angel

      Re: Puzzled

      > by performing a full cache flush

      That's where the bug is. The speculatively executed instructions are not retired, because they were executed in a branch mispredict context.

  19. Locky
    Boffin

    Note to El Reg and commantards

    Someone has spent a lot of time on the branding of this to create some cool images, please make sure use them. This is clearly more important than actually trying to fix the thing, obviously;

    https://meltdownattack.com/

    Seems VMware have been sparked into life too, and have released some patches for ESXi Workstation and Fusion;

    https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html

  20. I Am Spartacus
    Pint

    Well reported, Sir

    Nicely written piece. Good prototype for other el Reg reporters to follow when writing technical articles.

    Have a beer

  21. Anonymous Coward
    Anonymous Coward

    Lies, damned lies and statistics

    AMD is unnaffected. So much FUD.

    http://www.youtube.com/watch?v=qgiUuTmXyGs

    It's physically impossible on EPYC.

    Also.

    https://twitter.com/timgostony/status/948682862844248065

    1. Anonymous Coward
      Anonymous Coward

      Re: Lies, damned lies and statistics

      According to CERT/Homeland Security, Vulnerability Note VU#584653 claims that AMD is affected by Meltdown/Spectre. https://www.kb.cert.org/vuls/id/584653

      1. Dan 55 Silver badge

        Re: Lies, damned lies and statistics

        AMD is affected by one variant of Spectre, on Linux only, with a non-standard kernel option. It is not affected by Meltdown.

  22. rob_leady
    Facepalm

    Oracle caught napping ?

    So all of the big vendors have already got patches out, or on the way, yet there's notably none from Oracle as yet...

    1. Locky

      Re: Oracle caught napping ?

      They are trying to work out the costing model for the patch. One that is per core effected

      1. Anonymous Coward
        Anonymous Coward

        Re: Oracle caught napping ?

        Interesting that according to CERT, Oracle SPARC is not listed as affected. Maybe this is one of the only CPU's not affected by SPECTRE/MELTDOWN due to its Silicon Secured Memory? https://www.kb.cert.org/vuls/id/584653

      2. Anonymous Coward
        Joke

        "One that is per core effected"

        Could I suggest Oracle to base it on caches sizes?

  23. Christian Berger

    Hmm, If I was working at a secret agency

    I would be trying to make sure CPU designers "overlook" that problem deliberately. I mean all CPU vendors have plausible deniability since this could just as likely have been an accident.

    It's just like UEFI or ME. It looks like simple stupidity, but it greatly benefits certain agencies.

    1. sysconfig

      Re: Hmm, If I was working at a secret agency

      [...] it greatly benefits certain agencies

      Exactly that. Especially given that Intel and AMD are American, and ARM is British, but their chips are used globally. From an agency and gov point of view: What's not to like? I bet they are more upset that this has come to light than they ever were about the existence of those flaws.

      I'd also be inclined to wager that there are more flaws like this in CPUs and other chips/hardware. It's no secret after all that the 5 Eyes would like to see backdoors and reversible encryption everywhere.

      1. Doctor Syntax Silver badge

        Re: Hmm, If I was working at a secret agency

        "ARM is British"

        Was.

        1. fredj

          Re: Hmm, If I was working at a secret agency

          Japanese and probably with all the intellectual property as well?

    2. Paul Crawford Silver badge

      Re: Hmm, If I was working at a secret agency

      Lets face it, the underlying problem is the "need for speed" and the resulting mismatch between the CPU core at ~3GHz and main memory in the ~1GHz and below range. So lets throw hardware at it, millions and billions of transistors to try and play God/quantum by plying out all possible paths within the instruction pipeline.

      And they got it wrong. Not massively so in normal terms, but they did not design based on the assumption of bad actors abusing this. Because no one bought hardware that was slow and secure, at least, not the majority of PC gamers or business managers chasing the ever-bloating OS and web browser problems. Make it fast, make it now. Ship it when its half-baked and if we get too many problems then put out a microcode update which users may (or probably not, given the shittyness of many motherboard makers) apply.

      Sorry, but in most cases like this it is simple "incompetence" for not really planning high security from the original start because that is not what the boss will get bonuses for.

      1. Doctor Syntax Silver badge

        Re: Hmm, If I was working at a secret agency

        "play God/quantum"

        You raise an interesting point. Try mitigating this on a quantum computer taking all branches simultaneously.

      2. misterinformed

        Re: Hmm, If I was working at a secret agency

        "... they did not design based on the assumption of bad actors abusing this."

        I agree. For illustration, have a look at this Intel manual page from 1986, explaining why CPU-enforced sandboxing was introduced: the focus was entirely on detecting, and confining the damage of, "bugs". I think this is understandable because malware wasn't such an issue back then, but it has been obvious for a long time now that Protected Mode is a critical security defence, not just a stability feature, and there is no excuse for holes in its sandboxes in recent CPUs.

  24. Anonymous Coward
    Anonymous Coward

    Intel = 007-Spectre

    'Trusted Computing' Model 2.0'...

    "....."The design choice of putting a secretive, unmodifiable management chip in every computer was terrible, and leaving their customers exposed to these risks without an opt-out is an act of extreme irresponsibility," (EFF)..."

    http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html

  25. Zippy_UK

    Is this going to be Y2K all over again ? Does this mean rates will go up ?

    1. Anonymous Coward
      Anonymous Coward

      Rates going up? Probably, because the vast software suites that councils use to detect vitally important things like miscreants daring to put too much rubbish in their tiny bins that are only emptied every three weeks will now cost more to run.

  26. Alan Sharkey

    Some real world results

    OK - as a home user, here's a couple of data points for you to consider.

    MS have issued the patch for Windows 10. which takes you from build .125 up to build.192.

    I ran a handbrake video conversion before and after and also ran the passmark test before and after. This was on my I7-3770.

    Handbrake. Before: average FPS 168. Time taken - 18mins.

    Handbrake. After: average FPS 167.5. Time taken 18 mins 20 seconds.

    Passmark. Before After

    Total 3219.7 3228.7

    CPU 8214 8224

    2D 557 561

    3D 3585 3605

    Mem 1752 1758

    Disk 2444 2409

    So, the only thing that seems to have suffered is disk I/O and that by around 1.5%

    YMMV - this is just what I found.

    1. Anonymous Coward
      Anonymous Coward

      Re: Some real world results

      Yes, I saw the patch was out for the kool kiddies. Meanwhile, most of the Windows userbase is still vulnerable.

      1. Alan Sharkey

        Re: Some real world results

        The patch is available for anyone who does a Windows Update. Number KB4056892

        Alan

        1. digi

          Re: Some real world results

          But only for Win10 Version 1709 , not for 1703.

          1. Alan Sharkey

            Re: Some real world results

            and, your point is?

            I tested before and after applying the patch. Nothing else changed. So any other discrepancy you find is the result of other changes (1703 to 1709 for example).

            1709 is the current release. Not a future version.

            Alan

    2. Doctor Syntax Silver badge

      Re: Some real world results

      "YMMV"

      Pretty much what Linus said. If you don't make many kernel calls (computationally intensive, in other words) you shouldn't see much. If you make a lot of kernel calls then you get hit. It's the userland/kernel/userland transitions that are slowed down.

      1. Alan Sharkey

        Re: Some real world results

        Yes, but nothing approaching the 30% that has been bandied about.

        1. Anonymous Coward
          Anonymous Coward

          Re: "the 30% that has been bandied about."

          "the 30% that has been bandied about." needs to specify the workload used for the performance measurement. My recollection is that it was one of the SPEC benchmarks. If it matters, you can find it, the truth is out there somewhere. Use the source, always use the source.

  27. Doctor Syntax Silver badge

    Nothing posted on the BSD sites. Do they keep their kernels in a separate address space anyway and take the hit by design? If so you'd at least expect them to be pointing it out.

    1. Dan 55 Silver badge
      1. Roo
        Windows

        @Dan 55

        "Seems Theo was looking at this a decade ago so I guess OpenBSD is already okay."

        AFAICT those OpenBSD fixes related to an unpublished change w.r.t bits of page table being cached when previously they were not. I think it would be dangerous to assume those fixes also cover Meltdown.

        The points Theo made about the errata preventing people from implementing secure software remain valid.

        As I've said before folks really should look at the errata before purchasing a CPU - it is shocking just how broken some of them really are. That won't always help though - case in point try tracking down all the errata that Theo talked about (eg: AI90) 10 years ago... You may well struggle - because Intel's policy is to unpublish errata after they've made a fix/spec change... If anyone does find those errata - let me know. ;)

        1. Roo

          Re: @Dan 55

          As it turns out (and in fairness to Intel) I did actually find the Core 2 Duo errata Theo referred to back in 2007 after a bit more fiddling around with search criteria...

          http://download.intel.com/design/processor/specupdt/313279.pdf

          The closest issues to Meltdown that I found (maybe someone smarter can find more) were AI56, AI91 and AI99:

          AI56 "Update of Read/Write (R/W) or User/Supervisor (U/S) or Present (P) Bits without TLB Shootdown May Cause Unexpected Processor Behavior"

          AI91 "Update of Attribute Bits on Page Directories without Immediate TLB Shootdown May Cause Unexpected Processor Behavior"

          AI99 "Updating Code Page Directory Attributes without TLB Invalidation May Result in Improper Handling of Code #PF"

    2. Doctor Syntax Silver badge

      "Nothing posted on the BSD sites."

      Since I posted that FreeBSD announced they're working on it but they didn't get the notification until December.

  28. Version 1.0 Silver badge

    Meanwhile, back in the USA

    I'm guessing that they will be banning Intel from government computers soon?

    I'm checking the back room, I think I still have a few sticks of Z80's in the cupboard - this might be the time to put them on e-bay as "secure processors"

    1. Anonymous Coward
      Anonymous Coward

      Re:I still have a few sticks of Z80's in the cupboard

      There are probably places where the first two generations of Alpha-architecture chips (e.g. EV4 aka 21064 and EV5 aka 21164, and so on) are still available. They didn't have speculative/OoO execution; Alpha only got speculative execution in the EV6/21264 chips.

  29. -tim
    Facepalm

    I will get worse...

    If you can play two cores off of each other, there will be a way to convince the inter-cpu cache controller to write the cache line back to ram after it has been modified depending on the architecture. I'll call that hack "psychopathic breakdown"

    1. M man

      Re: I will get worse...

      Explain?

      1. Anonymous Coward
        Anonymous Coward

        Re: I will get worse...

        At a complete guess...

        I'd assume if you set part of the computation to CPU core 1, and part to 2, with the requirement of 1 to compute before 2, but allow it to pre-fetch the data (as in Meltdown). But this time you adjust that code, then execute with core 2.

        If the CPU has to write to memory to pass from core 1 to core 2, it could allow you to arbitrarily set any code, by arbitrarily setting something into pre-fetch, knowing no checks will be done on the pre-fetched data!?

        1. Jaybus

          Re: I will get worse...

          Good question. Core 2 cannot see core 1's L2, so does the OoO write on core 1 cause the written data to propagate to L3 to maintain cache coherency? Otherwise, the OoO write never makes it past core 1's L2 and core 2 then loads it's L2 with the original copy from L3 and so never sees core 1's abandoned write.

  30. anthonyhegedus Silver badge

    The Faily Fail will no doubt have a sensationalist article along the lines of "your data is about to be stolen and everyone's ID will be stolen and everyone's bank accounts will be emptied computer armageddon horror" followed by some useful advice along the lines of "Don't use your computer or phone and keep a lookout for immigrants trying to steal your data".

    1. Anonymous Coward
      Anonymous Coward

      Daily Mail article in today's (Thursday's) hardcopy

      actually is roughly four column inches of inevitably-oversimplified description which seems to come largely from ex-Sophos bloggist Graham Clueless and ends by crediting TheRegister for discovering this particular fail.

      (I read the Daily Mail at my neighbour's, honest).

      1. Anonymous Coward
        Anonymous Coward

        Re: Daily Mail article in today's (Thursday's) hardcopy

        To be honest this article looks like it has come from the Daily Mail with it’s end of the world insanity tone.

        Little mention of The Reg breaking a comms moratorium whilst patching was being spun up.

  31. Mage Silver badge
    Alert

    Mitigation: #1 infection vector?

    Maybe scripts on webpages.

    Mozilla managed to make Firefox 57 incompatible with Noscript (they made it hard for devs to migrate by NOT documenting API and releasing versions to devs first). Now they updated Firefox 52ESR (52.5.3) to break every plug-in. Got all working again except noscript.

    So I have installed uMatrix on Firefox as a script blocker. It also uses a database of evil tracking and malware domains. So good.

    Iceweasel now simply installs Firefox 52.5.3, so no good. Palemoon seems too much like a beta.

    I have Classic Theme restorer. Mozilla, if I wanted something like Google Chrome, I'd install Chromium.

    So yet again, the scary zero days are NOT beaten by AV systems (that often slow or break Windows), but by no remote content in email (I use a client for POP3 & IMAP), not opening attachments you shouldn't and Script blocking (White listing, blacklisting and blocking entire 3rd party domains).

    1. Jim Mitchell

      Re: Mitigation: #1 infection vector?

      Noscript was updated to work with the new Firefox regime. Interface is not as nice as the previous verison, but it does work.

      1. John Gamble

        Re: Mitigation: #1 infection vector?

        "Interface is not as nice as the previous verison, but it does work."

        The interface is genuinely terrible -- it "guesses" what scripts to allow if you don't have a rule, and doesn't inform you about them in the icon (i.e., no partial "no" symbol over the "S" as in the old version of Noscript).

        On the other hand, the old version of Noscript does work on Firefox 52.5.3, contrary to what Mage has stated.

        (I'm using the 64-bit version, in case that's a factor.)

  32. Anonymous Coward
    Anonymous Coward

    football punditry?

    >>This is, essentially, a mega-gaffe by the semiconductor industry.

    This is a bit rich I feel.

    It has taken the world a *decade* to find this on what are the two most popular architectures (x86, ARM) which are open on the details of the involved HW (out of necessity for SW use).

    The number of technical people and engineers who have seen this is not insignificant over that decade.

    Yet it has taken so long to identify it.

    Hindsight might be 20/20, but to call this an obvious gaffe is contrary to a decade of evidence.

    1. Anonymous Coward
      Anonymous Coward

      Re: football punditry?

      He didn't call it an obvious gaffe. He called it a mega-gaffe.

      1. Anonymous Coward
        Anonymous Coward

        Re: football punditry?

        Well for it to be gaffe it should be an embarrassing mistake, a mistake made rarely/by a few.

        For it to be a "mega-gaffe", it would have to be a obvious oversight, made by no-one and blindingly obvious.

        So I see a mega-gaffe as a mistake made on the very obvious. And obvious this isn't.

        I mean what is "mega-gaffe" about it? "Mega-gaffes" don't take a decade to find which is my point.

  33. TechnoNOtice

    Dont for get supporting hardware..

    What about thing like Cisco ASA, they run intel processors..

    and don't forget your routers, raspberry's, and all that wonderful IoT stuff many are based on (Broadcom) ARM Architecture :)

    1. Doctor Syntax Silver badge

      Re: Dont for get supporting hardware..

      "don't forget your routers, raspberry's, and all that wonderful IoT stuff many are based on (Broadcom) ARM Architecture"

      ARM's site lists the affected processors. AFAICS Pis aren't amongst those affected. As per a previous comment about stuff you control - the embedded processors shouldn't be exposed to random stuff off the net.

      1. CrazyOldCatMan Silver badge

        Re: Dont for get supporting hardware..

        the embedded processors shouldn't be exposed to random stuff off the net

        I wouldn't be so sure - how many of the IoT gubbins are using a vulnerable processor?

    2. Anonymous Coward
      Anonymous Coward

      Re: Dont for get supporting hardware..

      What user mode code not written by Cisco are you running on your ASA firewalls?

      1. Claptrap314 Silver badge

        Re: Dont for get supporting hardware..

        Depends. Is Cisco know for unhackable gear?

  34. M. Poolman

    What I don't understand

    is how, given that this is the result of a flaw at the level of the chip design, how it can affect chips with different architectures. Even if all these chips have speculative execution, surely the in silico implementation must be quite different for the different chips?

    1. Nick L

      Re: What I don't understand

      I'm no expert at all, but the example exploit relies on using speculative execution to bring out of bounds data into the cache, then hit the cache to get that data... The basic flaw, which as I understand it is that boundary checking can be bypassed through speculative execution then picked out of the cache, seems to be architecture independent as everyone has taken the same approach!

      1. IanDs

        Re: What I don't understand

        Nope, AMD don't allow speculative execution at user level to access kernel level data, this is prevented by hardware. Intel do, as do some ARM CPUs.

      2. Claptrap314 Silver badge

        Re: What I don't understand

        Because security exploits occur when someone thinks about something that the creator did not. Once the idea has comes, the first one with it has a good chance of being able to use it on multiple creations.

    2. Anonymous Coward
      Anonymous Coward

      Re: What I don't understand

      Its down to the marketing headlines concentrating on speed/throughput - if doing it right means doing it slower than your competitor...

    3. Roo
      Windows

      Re: What I don't understand

      Your bafflement is entirely justified.

      Intel are very lucky that their unique to them and trivially exploitable Meltdown bugs are being conflated with Spectre, they should be getting an extra roasting for that one.

      In terms of Spectre that seems to be a very generic label for a bunch of quite different vulns when you dig into what info is leaked and how you would exploit them usefully.

  35. }{amis}{
    Happy

    On the flip side yay cheap upgrades

    As Ebay is about to be flooded with cheap second hand Xeons, ill be grabbing one of these as even with a worst case 30% slow down a 10 core chip with 20+MB of cash, will pretty much curb stomp any consumer grade CPU.

    especially as my old AMD FX-8150 chip is getting a bit long in the tooth.

  36. This post has been deleted by its author

  37. Anonymous Coward
    Anonymous Coward

    Non-cacheable data on x86-64 ?

    In digging around this morning, the info on ARM's website apparently suggests that the problems now revealed do not apply to data in DEVICE address space (or something like that).

    Would I be safe to speculate that stuff read from DEVICE addresses does not get cached on ARMs which do speculative execution, and therefore tjhat data is not vulnerable to unwanted disclosure in these circumstances?

    Does x86-64 really not understand the difference between cacheable and non-cacheable data? It's a fairly fundamental cioncept to any post x86-32 chip and system design (SMP, multicore, etc).

    Clarification very welcome.

    1. Claptrap314 Silver badge

      Re: Non-cacheable data on x86-64 ?

      Intel's particular vuln occurred because they effectively allowed kernel memory to be cached in user-translatable memory. This doesn't have anything to do with physical cacheability.

  38. David Roberts
    Trollface

    Compensation!

    I wonder how my two Core 2 Duos and my Core 2 Quad are going to net me?

    Should I be ordering champagne and a yacht?

    I could start filling the bath now............

  39. a_mu

    Windows 7 Patch ?

    How many companies are still using windows 7

    will that be patched ?

    1. CrazyOldCatMan Silver badge

      Re: Windows 7 Patch ?

      How many companies are still using windows 7

      Quite a lot

      will that be patched ?

      Yes.

  40. hamiltoneuk

    I have installed KB4056892 on 2 Windows 10 PCs, a Core i3 2nd Gen and a 4th Gen. Both show about a 20% slowdown running Octane 2.0. Is this a last ditch attempt by Intel to sell us all a new CPU :)

  41. digi

    Is Intel Pentium 4 affected?

    I still have one PC with Intel Pentium 4 , thus not affected, true?

    The other PC has Intel Core 2 Duo E8400, thus affected, true?

    1. Uncle Slacky Silver badge
      Stop

      Re: Is Intel Pentium 4 affected?

      Everything from Pentium Pro onwards is affected, with the exception of a few Atoms (pre-2013).

  42. Orwellian

    Why is everyone so negative?

    Does this not potentially give users back some control by letting them read the hidden (by cpu) crypto keys of their media and software (Blu-ray/Digital content/games...)

    1. Anonymous Coward
      Anonymous Coward

      Re: Why is everyone so negative?

      When the system is yours, you can run a kernel debugger if you like. The issues arise when someone else can run code accessing your kernel without your knowledge...

  43. Martin Howe

    How does knowing where imply knowing what?

    Please can anyone give me a simple explanation of how knowing where data is in memory and/or whether it is currently cached or not, allows an attacker to actually access its contents if they don't have the privilege level for the memory addresses in question? Does the underlying caching mechanism *not* check bounds, privilege, etc? Does speculative execution not also do so? Bit rusty with architecture so would appreciate a simplified explanation of the one on the website - thanks.

    1. Anonymous Coward
      Anonymous Coward

      Re: How does knowing where imply knowing what?

      "Does the underlying caching mechanism *not* check bounds, privilege, etc? Does speculative execution not also do so? "

      Exactly. Data are read and brought into cache before the checks are actually performed, probably to avoid a performance hit. If and when the instruction is executed "really", a fault would occur, but if the CPU speculated wrongly, those data should have been simply discarded. Someone at Intel should have thought it would have been a waste to check access rights for data that could be discarded later...

      Just, people devised ways to read those data from cache before they are actually removed from the cache, which may not happen quickly enough even when the execution path has been discarded (which is desirable to avoid to trigger a fault for trying to access more privileged addresses).

      1. stephanh

        Re: How does knowing where imply knowing what?

        Meltdown works like this:

        Instruction 1 accesses a byte on a protected page and attempts to load it into a register.

        Instruction 2 uses the value loaded into the register to access some memory on one out of 256 pages (depending on the value of the register filled by instruction 1).

        Now, instruction 1 does an illegal access, so it causes a segfault. However, by that time instruction 2 has already been speculatively executed. Now, all the "normal" processor state (register values, etc.) are rolled back to before instruction 2, but, crucially, on Intel CPUs, NOT the fact that a particular one of these 256 pages was brought into cache.

        The attacker can now determine which of these pages was brought into cache by carefully timing how long it takes to access each of them. The fast one is the one brought into cache. Presto, one byte read from kernel space.

        Note that the 256 pages are NOT in kernel memory, they are just plain accessible memory in the attacker's process.

        1. Anonymous Coward
          Anonymous Coward

          Re: How does knowing where imply knowing what?

          "[...]the 256 pages are NOT in kernel memory, they are just plain accessible memory in the attacker's process.[...]"

          Nice summary, assuming it's correct. Thank you.

          Assuming I've correctly understood the various pictures, your description seems to be consistent with ARM's statement today that DEVICE data (which is deliberately and architecturally non-cacheable) isn't vulnerable to this particular unintended disclosure.

          By the sound of things, Intel no longer have enough smart knowledgeable people in positions of authority to make this distinction (or its importance) properly understood.

          Lots of other business-class chip architects (e.g. DEC, IBM, Sun, etc) have understood the distinction in the past, and it seems the AMD64 people still do. But then x86 and its allegedly impossible follow-on (Intel's apparently defective copy of AMD64) has never really had an architecture as such, and x86 in the post-DOS era has only been sold widely into business-class because of its apparent cheapness.

          Well done PHBs and bean counters. Don't say you weren't warned.

          ps

          anybody care to speculate what if any impact this has on Intel's SGX (Intel's alleged competitor to ARM's TrustZone, see e.g.

          https://www.theregister.co.uk/2016/02/01/sgx_secure_until_you_look_at_the_detail/

          [edited for typos]

        2. Claptrap314 Silver badge

          Re: How does knowing where imply knowing what?

          Sadly, the attack is not limited to this case. Specifically, OSes typically terminate processes that attempt to access memory they should not. Remember, "Illegal memory access, process has been terminated" from Winblows 95?

          To avoid this fate, the attack code needs to ensure that the speculative fetch of protected memory never gets checked. They either need to branch around it, but in such a way that the branch prediction logic incorrectly predicts that the fetch will occur; or by deliberately triggering an exception. The former strikes me a REALLY tough to do reliably. Of course, you need to play some sort of game with the OS to get the return from the exception to be other than the code that will shut you down--I think that is doable.

        3. Martin Howe
          Thumb Up

          Re: How does knowing where imply knowing what?

          Thanks - that took me a couple of re-reads but it helps a lot.

          To save anyone else the re-reads, the key is the number 256, the number of values a byte can hold plus the memory accessed in the second step need not be protected memory.

          1) Access kernel memory to put value in register.

          2) Speculative execution subsystem tries to execute as if (1) was OK. It will then speculatively execute "memory access at address **in non privileged memory areas that we have legitimate access to** of which the register forms part of the resolved address (as an index/scale/whatever to a base address) that causes **one of 256** pages to be pulled into cache. It doesn't matter what data values are in these pages, nor which pages, as long as the pages are accessible to us and there are *exactly* 256 possible pages that could be accessed. It is the fact that the data values are now in cache that matters. They could be the number of fleas on your cat, number of bugs in the Pentium FPU, doesn't matter.

          3) (1) faults due to privilege level. (2) Is "thrown away" as fault prevents the CPU getting to it "in the real world", **but the cache lines involved are not flushed**".

          4) By using timing analysis to find out *which* page was cached, that's also the number in the register and that number was loaded from kernel memory and used in an index register of sorts **before (2) was thrown away**. Thus, you now know which number is in the address in kernel memory.

          At least, that's how I read it in simple terms. Ouch!!

  44. Anonymous Coward
    Anonymous Coward

    Don't run any JIT you don't know

    If interpreters (like JS's) did not generate JIT code to make the exploit possible, one would need untrusted assembly language code to exploit; and that is not floating around that often anymore.

    Shouldn't things like JS, Python, C# etc. (plus real compilers) always have an option *not* to wring the last iota of performance from the code they submit to the processors? Much of that optimization, I guess, is processor-dependent anyway. And that should be the default, throw that switch at your own risk.

    Which betrays that:

    (a) This flaw is not my field of expertise

    (b) Neither is the kind of alchemy JIT uses that makes it exploitable by JS.

    (c) I am enough of a lunatic to believe thatsanity can trump short-term thinking, ever.

    1. Anonymous Coward
      Anonymous Coward

      Re: Don't run any JIT you don't know

      I believe with some ROP techniques you can achieve the same. And of course if you can lure any user to run anything in user mode, you can still hide inside the code to read kernel data.

  45. MarkSitkowski

    No Problem

    Glad all our stuff runs on Sun SPARC...

    1. Anonymous Coward
      Mushroom

      Re: No Problem

      > Glad all our stuff runs on Sun SPARC...

      Yes, because it's already slow and vulnerable to Spectre.

  46. Rob D.

    CERT solutions updated

    CERT are no longer recommending dropping the vulnerable hardware to completely remove the vulnerability - bit too sensitive a proposal?

    https://web.archive.org/web/20180104032628/https://www.kb.cert.org/vuls/id/584653

    1. Dakaix

      Re: CERT solutions updated

      A cynic might wonder whether they were leant on by a certain semiconductor vendor...

  47. Agent Tick
    Go

    This is certainly a Homeland backdoor, no?

    1. CrazyOldCatMan Silver badge

      This is certainly a Homeland backdoor, no?

      Never impute to malice what can be explained by stupidity..

  48. Martleby

    Utter rubbish

    Turns out just installing the Windows patch isn't enough, you also need to update firmware/microcode - which you can get from... your supplier.

    So basically, unless you bought your PC from Dell or HP, you're relying on your motherboard maker to update the bios on what could be a 4-5 year old motherboard. Likely to happen? I don't think so. And even if it did happen, how many users out there are going to know how to do it?

    To be honest, I'm going to un-install the Windows patch. It ain't gonna solve the issue.

  49. aaaa
    Meh

    x86/x32 Linux / Windows affected?

    Can anyone explain if x86/x32 Windows and Linux is affected? Everything I've seen so far says it's x64 only (or rather x64 microcode). In fact El Reg refer to "The crucial Meltdown-exploiting x86-64 code can be as simple as...".

    From memory I'm thinking that at boot Windows/Linux x32 place the processor into a non-64 bit mode that disables virtualisation etc. If you try and execute any x64 assembler 'under' Windows x32 it just barfs (again, from memory). (bonus points: can anyone confirm if you can run x64 assembler from an x32 windows process on an x64 OS host?)

    I'm thinking therefore that if you want to browse the web (javascript!) then just do it from an x32 OS install. An x32 browser (Firefox etc.) is not really any help I think if the OS is x64 - but if the OS is x32 it should be safe?

    But I see that the Microsoft patch KB4056891 has been made available for W10x32. I guess they can still apply the same mitigation measures for x32 - but I wouldn't think it's needed.

    I'm confused - can anyone clear it up for me?

    1. Claptrap314 Silver badge

      Re: x86/x32 Linux / Windows affected?

      PPro is a 32-bit processor, and is affected by the bug.

      1. aaaa

        Re: x86/x32 Linux / Windows affected?

        But the Linux patch is specifically for x86-64, e.g.: this advisory from Debain:

        https://lists.debian.org/debian-security-announce/2018/msg00000.html

        This specific attack has been named Meltdown and is addressed in the Linux kernel for the Intel x86-64 architecture by a patch set named Kernel Page Table Isolation, enforcing a near complete separation of the kernel and userspace address maps and preventing the attack.

        If it affects i386 then why isn't the i386 kernel being updated?

        1. Anonymous Coward
          Anonymous Coward

          Re: x86/x32 Linux / Windows affected?

          Guess this could be one of the reasons:

          https://www.theregister.co.uk/2016/07/05/linux_letting_go_32bit_builds_on_the_way_out/

          IMHO they gave priority to the 64 bit versions because that's what mostly used on actual non-embedded systems. Then patches could be backported to 32 bit kernel later.

          Speculative execution was introduced well before 64 bit, so unless 32 bit kernel use a different architecture - I don't remember exactly in which CPU supervisor bit for pages was introduced - it shares the same issue.

          1. aaaa

            Re: x86/x32 Linux / Windows affected?

            @AC - yep GRSecurity are kinda saying the same thing: https://twitter.com/grsecurity/status/949794658720337920

  50. Prosthetic Conscience
    Joke

    Can we spare a moment for the NSA bods

    They must be so disappointed someone else found these out and will have to go back to looking for the next ones.

  51. MrReal

    I've still to read any mechanism whereby browsing a website can read kernel memory - any ideas?

    It's not going to be HTML, CSS or JS is it?

    So how can a website harvest your kernel memory exactly?

    Answers rather than downvotes please, it's a genuine question.

  52. Luiz Abdala
    Windows

    Does it have anything to do with Von Neumann / Harvard architectures basic design premise?

    One separates executable code from data code, and the other doesn't?

    Just wondering if stuff was designed with Harvard design, would the flaw exist.... (because separating user executable code from kernel executable code would follow...)

    PS... I'm completely ignorant and guessing here. Help.

    1. John Savard

      Meltdown, at least, wouldn't, since it requires the ability to read kernel code as data. Branching to it, instead, to probe it would be more difficult and unpredictable.

  53. Anonymous Coward
    Anonymous Coward

    Intel-ligence

    Now we know what 'Intel' really means: a CPU with a backdoor for you know who.

  54. Mookster
    Boffin

    TEE

    So, does this also shaft TEE?

  55. PaulFrederick

    The solution here is obvious

    We just catch, then flay alive all system crackers. Problem solved! Because the performance penalty we're all going to have to pay otherwise is simply unacceptable. So I say make the guilty pay. Of course if hardware manufacturers want to replace the defective hardware they've sold us all I'd be open to that as well. In a way that is making the guilty pay too.

    1. John Savard

      Re: The solution here is obvious

      Unfortunately, some system crackers are in uncooperative foreign countries.

      Otherwise, as this solution allocates costs fairly, it would have been adopted long ago.

  56. androidonaught
    Holmes

    I am reminded of 1977, when the Colossal Cave "Adventure" program was crowding out real work in the lab on the PDP10. The game had an overlay that randomized it to keep people from gaming the game by reading the core dump.

    Now, 40 years later, one must ask why data in caches is in the clear? Shouldn't all data have a wired key relative to its secure level (e.g. user vs kernel) that must be available for the data to be useful? Therefore even if data is "stolen" from the kernel by this nefarious hack, then the data is useless without the associated key. Really NOTHING should be in CLEAR TEXT. Ever. 'Nuff said.

    1. Anonymous Coward
      Anonymous Coward

      "One must ask why data in caches is in the clear"

      Read about "side channel attacks". Data in the cache is not read directly - some clever techniques - i.e. timing how long it takes to perform an operation after bringing into cache some specific addresses with specific bits set - are used to "read" it, maybe one bit per operation, but with enough time available, you can read a lot of data.

      And anyway, at some point *any* data must be in the clear to be operated upon. Here you're in the cache close and designed to let the CPU process data at full speed...

  57. John Savard

    Bad Advice

    I think it's quite sensible of CERT to change its advice. Even if Spectre can't be addressed properly without replacing your CPU... it takes time to design a new CPU. So what would one replace it with?

    It's either turn off your computer and wait a year or two... or hop into a TARDIS to buy its replacement.

  58. Ceiling Cat

    Sigh... thanks, Reg (oh, and Intel)!

    For the love of christ!

    All I want to do with my PC is play games and maybe some light web browsing! Some of us AREN'T using our systems for "mission critical" work, you know.

    I will NOT risk what little performance my ageing I7-2600 (not "K") offers me by applying any patch that will even potentially rob me of 20% of my system performance, whether or not an "expert" claims that I will be unaffected.

    I would rather move to using my main rig for gaming, and use my Raspberry Pi 3 for web browsing.

    Not happy with intel, but blowing the lid off this was a pretty dick move, El Reg. You've actually, for the first time since I started reading the site in 1998, managed to lose some cred with me - which is too bad because I generally recommend you to people (both tech savvy and not).

    1. Ceiling Cat
      Unhappy

      Re: Sigh... thanks, Reg (oh, and Intel)!

      To the person who thumb-downed me, I did expect a reaction like that. I also expect that the bulk of people who thumbs-down me won't actually post why, or identify themselves.

      Bear in mind that I'm not really happy with Intel at this point, nor am I trying to defend them. I had been planning to start building a new gaming rig soon, as my current one (based around an old Gateway FX-6860) can no longer take video cards capable of meeting the minimum spec for most of the current/future releases. As I am still seeing reports of AMD hardware (both CPUs and GPUs) not running games as well as similarly-spec'ed Intel-based rigs, moving to AMD seems a no-go for me.

      Seems that, as a gamer (rather than a datacenter admin or IT professional), I am truly fucked for choices at this point in time.

      Console Master Race For The Win!

      1. John Savard

        Re: Sigh... thanks, Reg (oh, and Intel)!

        Well, the Register blowing the lid off it didn't change the situation: the bug still had to be fixed, and the fixes will still cause up to a 30% performance hit.

        If exploits come before the bugs are fixed, and the Register's exposure helped that to happen, I can see your objection - but I don't think that the Register engaged in irresponsible disclosure; instead, as they claim, they simply made it harder for the companies involved to put their spin on it with managed disclosure.

  59. fretter

    Meltdown and Spectre - a Wake-up call for HPC

    Do you want High Performance, or maximum security? Make your mind up, because you can't have both!

    https://www.linkedin.com/pulse/meltdown-spectre-wake-up-call-hpc-paul-fretter/

    It is a simple fact of engineering design, that there is a trade-off between performance and dependability. To get better than standard performance, we need to sacrifice security features that would otherwise get in the way. For example, if we turned on SELinux and disk encryption on an HPC system, it would no longer be High Performance because of the overheads. Remember, High Performance Computing is a relative term, e.g. relative to the norm which could arguably be regarded as enterprise servers, or desktops/laptops.

    Speculative execution appears to be one of those shortcuts to get more performance, but potentially at the expense of security. The OS kernel patches required to mitigate against the Meltdown and Spectre vulnerabilities will force a lot more traffic through the kernel, introducing overheads that will probably (?) impact performance for many applications. So, just because a general-purpose processor is capable of doing many different things, does not mean that we should expect them to be all things at the same time.

    While the CPU vendors should have a responsibility for warning users of the trade-offs, and maybe this is where they have been incidentally negligent, we who design and build systems cannot absolve ourselves from the responsibility of making sure we understand what we create.

    It is time for a pause, to take in the lesson here and make some tough decisions about where we want performance vs where we need security, and those who are developing HPC-as-a-cloud service will need to look closely at how they will present their "High Performance" offerings on shared platforms.

    Paul Fretter

    1. Ceiling Cat

      Re: Meltdown and Spectre - a Wake-up call for HPC

      Your comment makes a lot of sense to me, even though I'm just the bloke who cleans the lavatory.

      My interests are gaming, not HPC. In either, there is a need for data to be passed as quickly as possible, with a minimum of interference/pipeling lag introduced by what I'll just simplify as "security-related functions".

      I only kind of understand the idea of "speculative execution" - I'm not a coder, but it feels like a cousin of a feature that Windows used to use to pre-load certain files based on the times they were most frequently used. Some kind of pre-caching whose specific name escapes me.

      Being uneducated in this aspect of computing, I can't help but think that such a function is not as necessary for code which runs from a compiled state, rather than code that is runs "just in time". Or am I wrong on this?

      I am only being so serious because my brain hurts from trying to figure this out : On one hand, there are explanations that are way too technical; on the other hand, there's a lot (and I mean a *lot*) of FUD, trolling, and general "Hurr Durr intel Fucked Up", and I can't really make heads or tails of this.

      All I know is, If I'm patched, my performance may take a nosedive. If I don't patch, I'm at risk of ... [variable unknown]. Do either or both vulnerabilities really affect non-productivity machines as badly as HPC/Server Class gear? And will there be improvements made to mitigate the performance hit?

      Can someone get me a Tylenol? As I said earlier, my brain hurts.

  60. Joepin

    Corporate Trust

    It's ironic that the Pentium 3 is unaffected.

    The first attempt to reveal the cpu's serial number back to the powers that be.

    I suppose the geniuses writing the code figured the only way to go was

    behind the backs of the user.

    A sad state of affairs.

  61. jeffdyer

    I don't really see the issue. Data is data, unless you know what that data is, knowing some random bytes is of practically no use to anyone.

    0104 bf05 aa87 bbef 4576 anyone?

  62. MarkSitkowski

    Unprofessional Irresponsible Self-Aggrandisement

    I hope the jerks who made this public are patting themselves on the back and smugly basking in their new-found fame.

    These vulnerabilities have lurked around for 20-30 years, without causing anyone any problems, since the average dopey hacker is clueless about silicon architecture, or how it handles branching in cache execution.

    Now, thanks to these self-serving idiots, the world is in turmoil, with Intel users wondering how long before the parasites put together a few hacks - based on the suggestions also published with the disclosure - and give them to a botnet to execute.

    It doesn't bother me, since all our stuff runs on Sun SPARC, but it occurs to me that there should be a law or, at least, a protocol, whereby people like Intel get the results of such reports in secret, and the dirt isn't made public until there's a fix in-place.

    1. Anonymous Coward
      Anonymous Coward

      Re: Unprofessional Irresponsible Self-Aggrandisement

      "there should be a law or, at least, a protocol, whereby people like Intel get the results of such reports in secret, and the dirt isn't made public until there's a fix in-place."

      The "security resesrchers" and their media mates would typically refer you to the protocols of "responsible disclosure" at this time. Whether responsible disclosure actually works to the benefit of the wider world is a whole separate question.

      The "modern IT world" is in turmoil today for various reasons, including in large part because of lack of in-depth understanding of issues and technologies and risks and benefits, and and because of dependence on monoculture and monopoly.

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

Other stories you might like