back to article Meltdown/Spectre week three: World still knee-deep in something nasty

It is now almost three weeks since The Register revealed the chip design flaws that Google later confirmed and the world still awaits certainty about what it will take to get over the silicon slip-ups. The short version: on balance, some steps forward have been taken but last week didn't offer many useful advances. In the " …

Page:

  1. Anonymous Coward
    Anonymous Coward

    Had to disable Spectre mitigation

    Since patching my Office HP ProDesk PC with MS and BIOS updates, it was constantly logging this event:

    Event 19 Source WHEA-Logger

    A corrected hardware error has occurred.

    Reported by component: Processor Core

    Error Source: Corrected Machine Check

    Error Type: Internal parity error

    It has also had 6 BSODs with 4 different STOP codes since applying the updates. It doesn't even have the decency to fall over with the same error.

    Disabling the Spectre mitigation has stopped the WHEA events (hopefully the STOPs as well, time will tell), by setting the following DWORD to 1:

    HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

    REG_DWORD FeatureSettingsOverride = 1

    So it seems we have to choose between stability and security, although this at least leaves the Meltdown mitigation in place. Hopefully Intel can push out a less crap microcode update at some point in the near future.

    1. J J Carter Silver badge

      Re: Had to disable Spectre mitigation

      Also need to set FeatureSettingsOverrideMask, both DWORDS should be 3 if my reading of documentation is correct

      1. Anonymous Coward
        Anonymous Coward

        Re: Had to disable Spectre mitigation

        The mask has to be 3 as it specifies which bits in the DWORD are relevant.

        If you set FeatureSettingsOverride to 3 it disables both Meltdown and Spectre mitigations. If you set it to 1 it only disables Spectre mitigation.

    2. Jonathan 27

      Re: Had to disable Spectre mitigation

      I've updated two systems with the full set of microcode and Windows patches, a Dell XPS 9550 and a desktop with a Gigabyte Z170-Gaming 7 and niether has experienced any blue screens. It's a pretty small sample however, and both systems have derivatives of the same CPU design i7-6700k and i7-6700HQ (sky lake 4 core). Those are my personal machines, we're leaving the business ones a while to see.

    3. Anonymous Coward
      Facepalm

      Re: Had to disable Spectre mitigation

      Typing

      $ grep . /sys/devices/system/cpu/vulnerabilities/*

      into a Linux terminal window now reveals whether you've ever used anything Unix-y before, or whether you just copy shit from stackoverflow and hope no-one notices. But we noticed. What's wrong with cat?

      1. Michael Wojcik Silver badge

        Re: Had to disable Spectre mitigation

        What's wrong with cat?

        That grep command line isn't quite the same as cat - it will only display non-empty lines, because "." requires at least one character on the line (and grep doesn't consider the terminating LF a character).

        So if the input contains a lot of blank lines, grep is probably more useful than cat.

        But yeah. Oldtimers may remember the Useless Use of Cat (UUOC) award that was frequently handed out on comp.os.unix; this is probably a case of No, This Time You Should Have Used Cat.

  2. streaky Silver badge

    Google and Intel;

    Mishandled all this right from the start. Google will get away with it because they don't make CPUs.. Intel, not so much.

    Some things should stay buried, at least until there are proper hardware fixes and Intel (or anybody else) shouldn't be selling CPUs still at this point that are still vulnerable, not least because there's nothing to sue for a replacement for, which I'm sure Intel knows. Long term it's going to hurt them though.

    1. Michael Habel Silver badge

      Re: Google and Intel;

      Perhaps we'll finally see ARM on the Desktop running some Linux variant? Otherwise I think Intel having a damned near monopoly in the CPU market will be enough to see them through.

      Yeah there is AMD... Perhaps if they can beat Intel to the punch they could get good again. But I fear the days of 3DNow are over for them.

      1. big_D Silver badge

        Re: Google and Intel;

        ARM is also affected, to a lesser degree, like AMD. Nobody comes out of this smelling like roses.

    2. DougS Silver badge

      Intel "shouldn't be selling CPUs?"

      Even if it can be fixed via software? Or would a fix that reduced performance by even 0.01% be unacceptable to you?

      Do you understand how long the design cycle is for making the type of architectural changes that would be required to fix this in hardware? Intel would have stopped selling CPUs in June (without explanation) and not start selling them again until the end of this year at the very earliest.

      What's the world supposed to do for CPUs in the meantime? Even if AMD's CPUs were 100% bug free, for many workloads they are slower than Intel CPUs with the fixes applied. So that's not exactly a good solution. But the bigger problem is that they can't possibly make enough to supply the market, and PC sellers can't just slot in an AMD CPU to their existing models. It would take 6-9 months for them to redesign them to accommodate AMD CPUs on an AMD motherboard with AMD drivers - though realistically we all know Intel would be telling them "we will have new CPUs for you before you can get those AMD machines out, so don't even bother trying" and by the time the PC OEMs figured out Intel was lying they'd have the new CPUs almost ready.

      Your suggestion would quite likely cause enough of a hit to the world economy to be noticeable in the GDPs of the US, EU, and China. Meltdown / Spectre are bad, but far from end of the world bad.

      1. big_D Silver badge

        Re: Intel "shouldn't be selling CPUs?"

        And it isn't just Intel.

        AMD, ARM, Apple, IBM, Oracle are all affected by Spectre, so there wouldn't be any chips for pretty much all mainstream hardware.

      2. ST Silver badge
        FAIL

        Re: Intel "shouldn't be selling CPUs?"

        > Even if it can be fixed via software?

        Spectre can't be mitigated in software, Genius.

        It could conceivably be mitigated in the compiler, but that would lead to an unacceptable performance penalty. I.e. flush the L1 I-cache on each and every single branch target. Or re-write each and every single branch target to emit an instruction that can't be executed speculatively.

        And I'm not even 100% certain that either of these would mitigate for the case of an unconditional branch such as call foo@plt.

        Either way, the performance penalty is very high, and it requires a full recompilation of all the software, because the cure is in the compiler's codegen. Not something that can be cured with a software patch.

        1. big_D Silver badge

          Re: Intel "shouldn't be selling CPUs?"

          I though Retproline (Return Trampoline) was the compiler mitigation and is built in as a flag on the current gcc version and causes a negligible performance hit.

          1. ST Silver badge
            Terminator

            Re: Intel "shouldn't be selling CPUs?"

            > causes a negligible performance hit.

            s/negligible//g

            Try it on your own and see how "negligible" it is. As in not negligible at all.

          2. Anonymous Coward
            Anonymous Coward

            Re: Intel "shouldn't be selling CPUs?"

            "I though Retproline (Return Trampoline) was the compiler mitigation and is built in as a flag on the current gcc version and causes a negligible performance hit."

            Retpoline only helps with Spectre Variant 2, not Variant 1.

        2. FIA

          Re: Intel "shouldn't be selling CPUs?"

          Spectre can't be mitigated in software, Genius.

          [Snip software mitigation]

          And I'm not even 100% certain that either of these would mitigate for the case of an unconditional branch such as call foo@plt.

          And you'd be speculating what on an unconditional branch exactly?

          1. ST Silver badge
            FAIL

            Re: Intel "shouldn't be selling CPUs?"

            > And you'd be speculating what on an unconditional branch exactly?

            Do you even understand speculative execution, or are you just doing clueless blabbing on the Internet because you have a keyboard?

            I'm betting on clueless blabbing. Go back to writing Excel macros.

            1. Anonymous Coward
              Anonymous Coward

              Re: Intel "shouldn't be selling CPUs?"

              Do you even understand speculative execution,

              Better that you do, or perhaps you just have a problem with English? If a branch is unconditional (as you wrote) there is no speculation involved, since there's only one option the branch can take.

              I'm betting on clueless blabbing. Go back to writing Excel macros.

              Maybe you should get some sleep, or go back to a forum where your arrogant know-all attitide is likely to be better tolerated.

              1. ST Silver badge
                FAIL

                Re: Intel "shouldn't be selling CPUs?"

                > If a branch is unconditional (as you wrote) there is no speculation involved

                Wrong. There is. See ret.

                > [ ... ] go back to a forum where your arrogant know-all attitide is likely to be better tolerated.

                Spare me the pontificating.

                1. Anonymous Coward
                  Anonymous Coward

                  Re: Intel "shouldn't be selling CPUs?"

                  Wrong. There is. See ret.

                  Not an unconditional branch, since the destination isn't 100% known.

                  1. ST Silver badge
                    FAIL

                    Re: Intel "shouldn't be selling CPUs?"

                    > Not an unconditional branch, since the destination isn't 100% known.

                    Wrong again. The return register is always known. And if you're dealing with a large struct, where one or more struct elements would be returned outside the return register, these registers are also always known.

                    1. Phil O'Sophical Silver badge

                      Re: Intel "shouldn't be selling CPUs?"

                      The return register is always known

                      So how can a branch using it be speculative? Surely you only speculate when you don't know something for certain?

                      1. ST Silver badge

                        Re: Intel "shouldn't be selling CPUs?"

                        > Surely you only speculate when you don't know something for certain?

                        That's not how it works.

                        Speculative execution means that the CPU will decide to take a given branch because the branch predictor has guessed that this branch will be taken. This speculative branch is taken while other instructions are in-flight.

                        It then turns out that the branch predictor guessed wrong, and that guessed branch was not taken, maybe due to the completion of the then in-flight instructions, which made the branch predictor's guess wrong.

                        In this case, the speculative and out-of-order executed instructions must be rolled back - kind of like a relational database rollback transaction, but not quite. Unlike a relational database, where everything gets rolled back, certain side-effects of the speculative execution are not rolled back. One of these things is the L1 I-cache. The I-cache is not flushed because (a) replenishing it would be very expensive and (b) some of the instructions in the cache can still be re-used.

                        So, there you have it.

                        For example: a function can have several return statements, all of them predicated by conditionals:

                        if (some_condition_is_true()) {

                        do_mumble_foo();

                        return show_me_an_elephant();

                        } else if (some_other_condition_is_true()) {

                        do_mumble_bar();

                        return show_me_a_giraffe();

                        }

                        do_mumble_baz();

                        return show_me_a_dolphin();

                        You have 2 different conditional branches here. There are 8 branches in total, but I'm simplifying - I'm not counting the call and ret instructions that happen here.

                        The branches terminate with same exact return address and register - which is the function's return address and register.

                        Let's say that the branch predictor guesses that some_other_condition_is_true() returns ~0. But at run-time, some_condition_is_true() returns ~0 instead. Or neither of the condition() functions return ~0, and the code path falls through to do_mumble_baz(). In either case, the branch predictor guessed wrong. The speculative execution that happened based on the branch predictor's guess has taken the wrong branch, and now that out-of-order execution must be discarded (rolled back).

                        1. Phil O'Sophical Silver badge

                          Re: Intel "shouldn't be selling CPUs?"

                          Speculative execution means that the CPU will decide to take a given branch because the branch predictor has guessed that this branch will be taken. This speculative branch is taken while other instructions are in-flight.

                          Yes, that I understand.

                          My confusion was that I was assuming that "conditional branch" meant something like a single "branch if xxx" instruction, whereas "unconditional branch" would be "branch always". I wasn't allowing for them to be separated, where a preceding test would later be followed by a branch always, the combination being the "conditional branch" which could be speculatively executed. Thanks.

          2. Michael Wojcik Silver badge

            Re: Intel "shouldn't be selling CPUs?"

            And you'd be speculating what on an unconditional branch exactly?

            Conditional branches are not the only point of speculation. Pipelined CPUs that provide precise interrupts will are in effect speculatively executing most of the time, since they may roll back interrupted instructions under most conditions.

            You could probably get an indirect load to speculatively execute in a manner that leaks information through cache timing, if you can find a gadget with a suitable structure.

            1. Anonymous Coward
              Anonymous Coward

              Re: Intel "shouldn't be selling CPUs?"

              You could probably get an indirect load to speculatively execute in a manner that leaks information through cache timing, if you can find a gadget with a suitable structure.

              a.k.a. Meltdown.

        3. JeffyPoooh Silver badge
          Pint

          Re: Intel "shouldn't be selling CPUs?"

          ST suggested, "It could conceivably be mitigated in the compiler..."

          What if the bad guy uses the old (unmitigated) compiler, or even (gasp!) In-line Assembler ?

          I'm not sure that the basic concept of securing the world's CPUs in "the" (?) complier makes much sense.

          1. ST Silver badge

            Re: Intel "shouldn't be selling CPUs?"

            > What if the bad guy uses the old (unmitigated) compiler, or even (gasp!) In-line Assembler?

            That's exactly what makes Spectre so toxic. It doesn't even require any kind of special (i.e. root) privileges to work.

            Imagine some innocent-looking program that runs as a "regular" user, and exploits Spectre. It won't leave any trace at all.

          2. Anonymous Coward
            Anonymous Coward

            Re: Intel "shouldn't be selling CPUs?"

            ST suggested, "It could conceivably be mitigated in the compiler..."

            What if the bad guy uses the old (unmitigated) compiler, or even (gasp!) In-line Assembler ?

            It's not the bad guy's code you worry about. He wrote it, so he has no need for tricks to see what it is doing. It's the code under attack that needs protection.

            The problem with one of the Spectre variants is that the bad guy can write code which trains the branch predictor in certain circumstances (for certain addresses), then when the code under attack reaches a relevant branch he can use that trained prediction to leak information he shouldn't be able to get at.

            The compiler changes are to modify the attacked code, not the attacker's code, so that it can't be influenced by the attacker. Blocking all prediction would work, but have an extreme performance hit, so the combination of new microcode & compiler changes is supposed to allow critical code to be protected while minimizing the hit. Far from simple, and a PITA if every kernel & VM needs to be recompiled with the new compiler.

            The fix doesn't need to be perfect, though. Just as crypto doesn't need to be unbreakable, just too hard to break in a reasonable time, the Spectre mitigation just needs to make the attack too slow to be useful. If the attack on mitigated code creates a side channel that can only leak, say, 1 bit every 5 minutes, it will likely take too long to get anything useful before the next restart, reboot or other significant change.

      3. jmch Silver badge

        Re: Intel "shouldn't be selling CPUs?"

        "Even if it can be fixed via software? Or would a fix that reduced performance by even 0.01% be unacceptable to you?"

        It CAN'T be fixed by software. It can be (partly or mostly) mitigated. If it could be fixed with a 0.01% performance loss no-one would be kicking up the stink that they are, but reality is that it can be mitigated with a perforance hit of anywhere between 5-20% judging by reports I've seen.

        Can you imagine if you paid north of 30 grand for a car with 200 bhp, and the manufacturer says hey, the brakes might fail at any given moment, very unlikely to happen guv, but here's a fix and by the way, your car now has 160bhp not 200.

      4. jmch Silver badge

        Re: Intel "shouldn't be selling CPUs?"

        "What's the world supposed to do for CPUs in the meantime?"

        At least customers can have some informed consent on the chips they have been buying in last 6 months that Intel KNEW were borked (and possibly they knew of the flaw even before 6 months ago). I'd expect at least a discount / partial refund on any chips bought in the last 6 months. And given that Intel had 6 months to work on a software mitigation patch, isn't the least to be expected that it was properly tested? Maybe the Register jumped the gun by a couple of days, but the disclosure was due anyway, Intel should have thrown as much resources as it took to fix this on time.

        "Even if AMD's CPUs were 100% bug free, for many workloads they are slower than Intel CPUs with the fixes applied"

        I'm not an expert on chip performance is this confirmed anywhere? Anyone?

        1. Brewster's Angle Grinder Silver badge
          Joke

          Re: Intel "shouldn't be selling CPUs?"

          >>Even if AMD's CPUs were 100% bug free, for many workloads they are slower than Intel CPUs with the fixes applied

          >I'm not an expert on chip performance is this confirmed anywhere? Anyone?

          Yup, it's been confirmed. By Intel's marketing department.

          1. Bronek Kozicki Silver badge

            Re: Intel "shouldn't be selling CPUs?"

            AMD is known to be not affected by Meltdown bug, which was also the most expensive (in terms of performance penalty) one to fix. This means that, suddenly, all the performance benchmarks comparing Intel (with crappy buggy speculative execution which allows user code crossing kernel boundary) against AMD ones (which would not allow such violation in its own, slightly less buggy, implementation of speculative execution) are no longer valid.

            1. ST Silver badge
              Terminator

              Re: Intel "shouldn't be selling CPUs?"

              Intel (with crappy buggy speculative execution which allows user code crossing kernel boundary)

              No. You got this 100% wrong. This is not what Spectre does. You are confusing Spectre with Meltdown.

              And it's not just Intel that has crappy buggy speculative execution.

              Every single chip that has speculative execution - which means all general-purpose chips designed and fabricated in the past 20+ years, with the exception of Itanium - is affected by Spectre.

              And no, it's not a matter of buggy or crappy. It was a design oversight, or short-sightedness if you will, at the time, combined with the notion that nobody is smart enough to figure this out, and with pressure from benchmarketing types.

              The Spectre vulnerability was being whispered around in interested circles much earlier than June 2017.

              1. Bronek Kozicki Silver badge

                Re: Intel "shouldn't be selling CPUs?"

                @ST you are right and I am right - I was referring to Meltdown (not to Specre) so we agree on this. The speculative execution on its own can also cause Spectre "class" of bugs which are cheaper (performance wise) to work around, as compared to Meltdown one. The numbers I keep seeing on lwn.net for Specre are consistently under 5% (usually around 1%), but numbers for Meltdown easily exceed 10% if your system is doing little more IO or other kernel-related activities. This is why I believe that AMD (not being affected by Meltdown) have now huge performance win against Intel, which is not reflected by old benchmarks, at all. On related note - I wonder if GPU intensive application (i.e. games) need context switch to communicate with the GPU. If so, then gaming benchmarks are going to be affected a lot, too.

                You are also right on explaining that speculative execution issue is not just "implementation", it is more of a design issue. Just let me have that simplification, ok?

                1. ST Silver badge

                  Re: Intel "shouldn't be selling CPUs?"

                  Just let me have that simplification, ok?

                  I think we're both saying the same exact thing, just using different words.

              2. JohnFen Silver badge

                Re: Intel "shouldn't be selling CPUs?"

                "And no, it's not a matter of buggy or crappy. It was a design oversight"

                It was indeed a design oversight, and a subtle enough one that it's hard to blame the engineers for it. However, it's still a bug -- and therefore the implementation is buggy.

              3. martinusher Silver badge

                Re: Intel "shouldn't be selling CPUs?"

                >And no, it's not a matter of buggy or crappy. It was a design oversight, or short-sightedness if you will, at the time, combined with the notion that nobody is smart enough to figure this out, and with pressure from benchmarketing types.

                Its also a matter of playing the odds. Despite what the typical (noisy) consumer might think there really is no such thing as 100% anything. Designers play the odds because you're always trading off conflicting parameters, you just don't talk about it much because its difficult to explain to people that think entirely in terms of 100% or 0%. So, yes, there's a problem but how much of a problem and how the problem or a fix might affect particular users is a judgment call, especially as the problem manifests itself as an ability to slowly read information about a memory area that shouldn't contain any particularly meaningful information in the first place.

            2. FIA

              Re: Intel "shouldn't be selling CPUs?"

              [...] benchmarks comparing Intel (with crappy buggy speculative execution which allows user code crossing kernel boundary) against AMD ones (which would not allow such violation in its own, slightly less buggy, implementation of speculative execution)

              Lets be fair here, neither chip has buggy speculative execution. This isn't a bug, the chips work as expected; it's a side channel attack, the processor leaks information that after A LOT of trial an error can be used to figure out what's in certain memory locations. It's just that trial and error on a CPU can be quite quick... and the internet allows it to be done remotely, often without the users knowledge.

              I know it's only a small point, but a lot of the press, especially the less technical press are making it out like this is a huge bug that should've been noticed, rather than a perfect storm of unintended side effects that's taken 20 years to figure out.

              It's like how posting your holiday photos whilst on holiday make your house more attractive to thieves. It's not your intention, or a 'bug' in Facebook, it's just an unintended consequence.

              The reality is, the more complex systems become the more things like this will appear.

              1. JohnFen Silver badge

                Re: Intel "shouldn't be selling CPUs?"

                "This isn't a bug, the chips work as expected"

                I suppose that depends on how you define "bug". By my definition, this is definitely a bug (unless being vulnerable to a side-channel attack was intended) -- a bug in design rather than execution, but a bug nonetheless.

                "a lot of the press, especially the less technical press are making it out like this is a huge bug that should've been noticed"

                I agree that this is a mischaracterization by the press. This was a very subtle thing, and it's hard to fault engineers for not noticing it.

        2. analyzer

          Re: Intel "shouldn't be selling CPUs?"

          Well that's a little more complex than the simple faster then.

          It kind of goes like this, Intel CPUs are 'on average' 30% faster than AMD Zen CPUs <--- the point where idiots stop reading <--- for single threaded workloads but there are workloads where AMD is faster. For multi threaded loads, AMD Zen CPUs are on average 13% faster than Intel but there are workloads where Intel are faster. So CPU choice is pretty much irrelevant except for outliers where one will seriously trounce the other.

          The curious thing regarding servers that I never see mentioned is the actual data throughput of the system containing the CPU. As the Intel Xeon sports 44 PCIe lanes vs the 128 lanes that the AMD Epyc provides and, typically, 6 PCIe lanes are dedicated to board specific functions, that leaves Intel with only 38 to play with vs AMDs 122. This would imply that the actual throughput of an Epyc based system could be far higher than a Xeon one.

          1. big_D Silver badge

            Re: Intel "shouldn't be selling CPUs?"

            As analyzer says, it depends on what you are doing and whether you are an outlier usecase. In my case, I wasn't interested in single threaded performance, but performance for multiple virtual machines for testing on a desktop... Ryzen 7 was a no-brainer, 8 cores and 16 threads for around the price of a quad core Intel processor.

            This is the first rig I've had that doesn't slow down when running multiple VMs.

            1. ST Silver badge
              Terminator

              Re: Intel "shouldn't be selling CPUs?"

              > I wasn't interested in single threaded performance, but performance for multiple virtual machines for testing on a desktop

              Spectre has nothing to do with single-threaded vs. multi-threaded or running multiple VM's or anything like that.

              The Spectre vulnerability is very simple: in the context of a branch mispredict speculative execution, the instructions aren't retired.

              Mispredicted branches happen all the time, regardless of the number of threads, or whether you're running a VM or a relational database. What the software does is 100% irrelevant.

              If you disable speculative execution competely, the performance hit is staggering: it's in the 30% ballpark.

              Branches - conditional or unconditional - exist in every single type of software.

              Without branches you can't have if/else statements, for/while loops, return from a function or a function calling another function.

              OK, that's an over-simpification. You can have conditionals without branches, but that's a very complicated and inefficient way of doing conditional branches. You still end up in the same sore spot: huge performance hit.

              1. big_D Silver badge

                @ST Re: Intel "shouldn't be selling CPUs?"

                I think you are missing the context here.

                The discussion between analyzer and myself was whether Ryzen made AMD competitive again against Intel (before Meltdown and Spectre). That, before M/S Ryzen one on some edge cases, compared to Intel and vice versa.

                What you say is correct, but it has no bearing on the sub-conversation you refer to.

              2. Anonymous Coward
                Anonymous Coward

                @ST Re: Intel "shouldn't be selling CPUs?"

                Spectre has nothing to do with single-threaded vs. multi-threaded or running multiple VM's or anything like that.

                (S)he didn't suggest that it did, the comment was in response to allegations that AMD was always slower than intel, and the poster pointed out that for the use case in question, running multiple VMs, AMD gave better performance.

                Slow down & read the comment fully before jumping in with a response.

                Mispredicted branches happen all the time,

                They do indeed, the big question for Spectre is whether you can train the branch predictor such that you can be fairly sure which way it will jump. If you can, you have a Spectre exploit. The compiler & code mitigations involve making it too difficult to usefully train the predictor, not in suppressing the predictions. That's why the performance hit may be tolerable.

                1. ST Silver badge

                  Re: @ST Intel "shouldn't be selling CPUs?"

                  > The compiler & code mitigations involve making it too difficult to usefully train the predictor, not in suppressing the predictions.

                  One of the proposed compiler-based mitigations for Spectre involves inserting an otherwise useless loop containing pause instructions (on Intel) for each and every single branch target. This will suppress speculative execution, because pause cannot be executed speculatively.

                  Not all ISA's have pause, so what applies to Intel won't apply to other ISA's.

                  So, my question is: what is the difference - in practical terms - between making it too difficult to usefully train the predictor and suppressing the predictions?

        3. Tom Paine Silver badge
          FAIL

          Re: Intel "shouldn't be selling CPUs?"

          To be fair, this is pretty much the worst possible case for computer security; a fundamental defect in an architectural design pattern adopted by multiple part manufacturers for decades. I can only dimly imagine how bad a day that must have been at the Intel security team when the first mail arrived.

        4. elip

          Re: Intel "shouldn't be selling CPUs?"

          I'm more than a little bit distressed by the fact that Intel, ARM, AMD, Google etc. knew about this flaw for half of a year, but kept Oracle and IBM (and other smaller RISC vendors) completely in the dark. I understand, and completely disagree, with software-only security embargoes, as it effectively penalizes the smaller developers and open source projects, which ultimately hurts users' security. However, in this case, the owners of 80-90% of the world's running machines, in my opinion, *colluded* to keep these older RISC vendors out of the loop, while they developed mitigations and designs to improve their future products. They did this knowingly, and willfully. I have a feeling and hope, some very large, very reckless companies are going to be facing legal battles.

      5. Teiwaz Silver badge

        Re: Intel "shouldn't be selling CPUs?"

        What's the world supposed to do for CPUs in the meantime?

        Cue : Penny Farthing Logo.

        Maybe it's a good opportunity to slow down and take stock of where the world is headed rather than continue the knees bent, running about advancing behaviour blindly, up up the ziggurat lickity split...

        No takers? thought not.

        1. Random Handle

          Re: Intel "shouldn't be selling CPUs?"

          >Maybe it's a good opportunity to slow down and take stock

          First thing the CEO did.

Page:

POST COMMENT House rules

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

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019