Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
HP Bug Software IT

Dell and HP Advise All Their Customers To Not Install Spectre BIOS Updates (bleepingcomputer.com) 88

An anonymous reader writes: The Spectre and Meltdown mess continues with Dell now recommending their customers to not install the BIOS updates that are supposed to resolve the Spectre (Variant 2) vulnerabilities. These updates have been causing numerous problems for users including performance issues, boot issues, reboot issues, and general system stability. Due to this, Dell EMC has updated its knowledgebase article with a statement advising customers to not install the BIOS update and to potentially rollback to the previous BIOS if their computers are exhibiting "unpredictable system behavior". ZDNet reports that HP too has issued a similar advisory. The computer manufacturer pulled its softpaqs BIOS updates with Intel's patches from its website, and said it would be releasing a BIOS update with a previous version of Intel's microcode on Thursday.
This discussion has been archived. No new comments can be posted.

Dell and HP Advise All Their Customers To Not Install Spectre BIOS Updates

Comments Filter:
  • by blind biker ( 1066130 ) on Wednesday January 24, 2018 @10:03AM (#55992443) Journal

    People still haven't gotten the point - this is testament to Intel's PR efforts to obfuscate the facts. It seems the majority of people believe that Spectre (affects Intel, AMD and ARM) is just as dangerous as Meltdown (affects only Intel CPUs). Un-fucking-believable. We truly live in the epoch of idiocracy.

    • When the patch feels like an exploit...
      • Change log:
        2018/01/01 - Added 14 Useful Links. Disable Intel ME 11 via undocumented NSA "High Assurance Platform" mode with me_cleaner, Blackhat Dec 2017 Intel ME presentation, Intel ME CVEs (CVSS Scored 7.2-10.0)

        Intel CPU Backdoor Report
        The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.

        What we know about Intel CPU backdoors so far:

        TL;DR version

        Your Intel CPU and Chipset is running a backdoor as we speak.

        The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.

        30C3 Intel ME live hack:
        [Video] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware [youtube.com]
        @21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.

        [Quotes] Vortrag [events.ccc.de]:
        "the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker".

        "We can permanently monitor the keyboard buffer on both operating system targets."

        Decoding Intel backdoors:
        The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.

        If you are skilled in these areas, download Intel ME firmwares from this collection [win-raid.com] and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).

        Backdoor removal:
        The backdoor firmware can be removed by following this guide [github.io] using the me_cleaner [github.com] script.
        Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.

        2017 Dec Update:
        Intel ME on recent CPUs may be disabled by enabling the undocumented NSA HAP mode [ptsecurity.com], use me_cleaner [github.com] with -S option to set the HAP bit, see me_cleaner: HAP AltMeDisable bit [github.com].

        Useful links (Added 2018 Jan 1):
        Disabling Intel ME 11 via undocumented HAP mode (NSA High Assurance Platform mode) [ptsecurity.com]
        me_cleaner: Set HAP AltMeDisable bit with -S option [github.com]
        Blackhat 2017: How To Hack A Turned Off Computer Or Running Unsigned Code In Intel Management Engine [blackhat.com]
        EFF: Intel's Management Engine is a security hazard, and users need a way to disable it [eff.org]
        Sakaki's EFI Install Guide/Disabling the Intel Management Engine [gentoo.org]
        Intel ME bug storm: Hardware vendors race to identify and provide updates for dangerous Intel flaws. [zdnet.com]
        CVE-2017-5689 [cvedetails.com]: An unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs
        CVE-2017-5705 [cvedetails.com]: Multiple buffer overflows in kernel in Intel Manageability Engine Firmware
        CVE-2017-5706 [cvedetails.com]: Multiple buffer overflows in kernel in Intel Server Platform Services Firmware
        CVE-2017-5707 [cvedetails.com]: Multiple buffer overflows in kernel in Intel Trusted Execution Engine Firmware
        CVE-2017-5708 [cvedetails.com]: Multiple privilege escalations in kernel in Intel Manageability Engine Firmware
        CVE-2017-5709 [cvedetails.com]: Multiple privilege escalations in kernel in Intel Server Platform Services Firmware
        CVE-2017-5710 [cvedetails.com]: Multiple privilege escalations in kernel in Intel Trusted Execution Engine Firmware
        CVE-2017-5711 [cvedetails.com]: Multiple buffer overflows in Active Management Technology (AMT)
        CVE-2017-5712 [cvedetails.com]: Buffer overflow in Active Management Technology (AMT)

        Useful links (Added 2017):
        The Intel ME subsystem can take over your machine, can't be audited [ycombinator.com]
        REcon 2014 - Intel Management Engine Secrets [youtube.com]
        Untrusting the CPU (33c3) [youtube.com]
        Towards (reasonably) trustworthy x86 laptops [youtube.com]
        30C3 To Protect And Infect - The militarization of the Internet [youtube.com]
        30c3: To Protect And Infect Part 2 - Mass Surveillance Tools & Software [youtube.com]

        1. Introduction, what is Intel ME

        Short version, from Intel staff:

        Re: What Intel CPUs lack Intel ME secondary processor? [intel.com]
        Amy_Intel Feb 8, 2016 9:27 AM

        The Management Engine (ME) is an isolated and protected coprocessor, embedded as a non-optional part in all current Intel chipsets, I even checked with the engineering department and they confirmed it.

        Long version:

        ME: Management Engine [libreboot.org]

        The Intel Management Engine (ME) is a separate computing environment physically located in the MCH chip or PCH chip replacing ICH.

        The ME consists of an individual processor core, code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system's memory as well as to reserve a region of protected external memory to supplement the ME's limited internal RAM. The ME also has network access with its own MAC address through the Intel Gigabit Ethernet Controller integrated in the southbridge (ICH or PCH).

        The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can report to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can't be ignored.

        ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include "ME Ignition" firmware that performs some hardware initialization and power management. If the ME's boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.

        Quotes on Intel backdoors:

        A message from RMS [fsf.org]
        by Richard Stallman on Dec 29, 2016 09:45 AM

        The current generation of Intel and AMD processor chips are designed with vicious back doors that users cannot shut off. (In Intel processors, it's the "management engine".)

        No users should trust those processors.

        2. The backdoor is next to impossible to de

    • by Anonymous Coward

      Now that the news is out, it's just a matter of time until active exploits of Spectre 2 are in found in the wild.

    • Re: (Score:3, Informative)

      by Anonymous Coward

      Really?
      While Meltdown is more awful, its mitigation is pretty much done with KAISER type patches to kernels. This is not a fix but is good enough for now. The same was done in Linux kernels for ARM.

      Spectre is more tricky when it comes to making sure either of its variants cannot be used. And more vulnerabilities of the same type are likely to be found. Work on making things less vulnerable to it is still underway.

      I get it that it's popular to bash Intel at this point and while they have done a lot to deserv

      • Communicating. (Score:5, Interesting)

        by DrYak ( 748999 ) on Wednesday January 24, 2018 @11:03AM (#55992721) Homepage

        ARM is probably the only one of the chipmakers doing the right thing here. Information is quick, public, to the point and fixes are deployed as soon as they are done. There are performance issues with ARM patches but they are taken as necessary.

        They just got lucky to be right most of the time.
        (Helps that they use a much simpler RISC architecture : Their engineer have probably less to review until they can give a definite answer about what is exploitable.
        They can mass-exclude any ARM core that doesn't do speculative execution at all (e.g.: RaspberryPi) ).

        AMD is just ignoring it altogether until they no longer can. Regarding Spectre: near zero chance > microcode and software updates are coming, this you can read in statement on their page.

        Mordern CPUs *are* complex, it's not impossible for not everybody in a company to know every single details.

        Spectre variant 2 is the perfect exemple :
        Variant 2 Spectre works by relying on extremely precise gory detail of the implementation of speculative execution around indirect jumps whose destination isn't even known at execution time
        (e.g.: a jumptable whose index depends on a result that isn't computed yet.
        e.g: That's one possible form to compile a C/C++ ."switch" block into machine code.
        That's also what happens when you need to call the virtual overloaded member function of a C++ object member of an array and you haven't computed the index into the array yet)

        The Google demo code relies on the format of the internal data that the branch predictor uses to makes it best guess to where this as of yet unkown destination isn't know.
        (Basically, the CPU keeps notes of where it jumped-to most of the times during the past when encountering this point of code.
        But the way the CPU write down "this point of code" in it notes is actually imprecise and can lead to confusion.
        More or less, it's a hash and Google has found a way to cause a hash collision.
        The attacker causes their own attack-program to jump to position A, whenever execution arrives at instruction B.
        Then the exploited program reaches a different instruction C, but the CPU is confused and thinks it's again at instruction B, and jumps to position A "out of habit" based on its notes, even if in the exploited program, there's no way this could happen ever (e.g.: there's no "position A" listed in the jump table). )

        Should Intel admit that they are vulnerable ? Yes, Google caught them with their pants down on this one.

        But, the Intel Xeon exploited by Google demo code certainly works completely differently than any AMD CPU.
        So for sure they can guarantee that the exact exploit code won't work for on AMD CPUs
        (It would be reasonnable guess, even without speaking to any engineer)

        Now: is it definitely impossible to somewhat exploit the jump prediction in a globally similar way ?
        Well difficult to exclude.
        AMD would need to discuss it at lengths with their engineers experts in branch prediction on their CPU.

        So first "nearly-zreo" (Shouldn't not work, but who knows ?)

        And then, once AMD manages to get hold eventually of the guy who knows: Oh, shit, it turns out there could be a completely different method that could perhaps be applied to exploit indirect jumps on some recent architectures.
        So update the page to tell people to do the updates (while continuing to review with the engineer to try to give an actual answer whether there is actually a viable exploit).

        AMD are trying their best, but CPUs are complex stuff, and it's not easy to give a definitive answer fast.

        • Re: (Score:3, Insightful)

          by Anonymous Coward

          ...it's not impossible for not everybody in a company to know every single details.

          This broke my brain. Can you re-word it as a car analogy?

      • While Meltdown is more awful, its mitigation is pretty much done with KAISER type patches to kernels. This is not a fix but is good enough for now. The same was done in Linux kernels for ARM.

        It's good enough if you don't mind a 5-50% performance impact, depending on workload.

        Spectre is more tricky when it comes to making sure either of its variants cannot be used. And more vulnerabilities of the same type are likely to be found. Work on making things less vulnerable to it is still underway.

        AMD is already less vulnerable to it than Intel, because Intel did things they knew were unsafe to gain a speed advantage over AMD.

        I get it that it's popular to bash Intel at this point and while they have done a lot to deserve this, this issue is really not why. Meltdown also affects Power and ARM core (or a few).

        It's telling that it affects only POWER (probably 5-9, definitely 7-9), Intel, and one ARM core. It tells us that Intel and IBM are willing to play fast and loose with the security of your data in order to gain a competitive advantage.

        Now, these broken Intel updates are meant for Spectre (variant 2) mitigation. Along with the Linux kernel patches Linus lambasted (reading further into the thread, there do seem to be reasons why patches were written the way they were).

        Yes. Intel incompetence. They are in a panic and scrambling t

    • More likely nobody cares to with the ability. "Hackers" have been governments and megacorps alone for the last ~decade and a half. They already have a plethora of backdoors at their disposal while Meltdown and Spectre are trickier to exploit. The script kiddies only get what leaks out and usually end up implementing them wrong anyway. The governments and megacorps tend to try to remain covert (e.g. when they're in your system they have reason to make you not believe they are) while the script kiddies ar

      • by Anonymous Coward

        Agreed. I'm sure that there are there exploits out there that are a much greater risk to me which are as yet unknown to the general public (and hence unknown to me). I don't do any banking or engage in an political activities on PC's, and I consider the greatest risk to be someone hacking Amazon and other parties that I engage in retail activities with.

    • by mwvdlee ( 775178 ) on Wednesday January 24, 2018 @10:36AM (#55992585) Homepage

      To me this sounds not so much like a PR efforts as much as Yet Another Intel Fuck-Up that would require additional PR efforts to spin.
      You'll note that the Dell advisory explicitely mentions that the advisory applies to the Intel patches. It doesn't mention problems with patches for other CPU's.
      As I read this story, Intel provided BIOS updates for their own CPU's, and those BIOS updates are causing problems.
      It just happens to be that this particular fuck-up involves the lesser of the two previous bugs, but doesn't really seem caused by that bug itself.
      So I guess this means that for Intel CPU's, both bugs are dangerous.

      AMD and ARM are still left with only a single reasonably harmless bug.

      • by gweihir ( 88907 )

        While it is not clear how dangerous Spectre is on AMD and ARM, it seems to be a lot harder to exploit there and it already is hard on Intel.

        What really surprises me though, is that Intel is putting out patches this badly done. It is like they are now mocking the customers that bought their fast, but inferior in every other aspect products. It is also like they are actually technologically incompetent now and do not even understand their own products.

    • People still haven't gotten the point - this is testament to Intel's PR efforts to obfuscate the facts. It seems the majority of people believe that Spectre (affects Intel, AMD and ARM) is just as dangerous as Meltdown (affects only Intel CPUs). Un-fucking-believable. We truly live in the epoch of idiocracy.

      Well parts of it can be exploited. But mostly it was mainly fixed by fixing browsers. The parts that attack hypervisors and kernels is the speculative stuff.

    • The neat thing about computers is a not-practical exploit can be programmed, so the hacker isn't wasting there efforts in all the rigamarole. It really isn't up to the general public to be able to successfully classify how bad a flaw is. Sure Intel would also like to point blame at AMD and ARM too. But Intel is in a loose loose situation here. They had big problem which they had patched, then there is an other one, which they need to show that they are responsive, however it is a complex problem that ne

    • In spite of it being perhaps more difficult to exploit, I have the impression that large data centres operating virtual private servers (commercial and corporate alike) have good reasons to be seriously concerned about Spectre.

      Citing Forbes [forbes.com], Wikipedia’s article on Spectre [wikipedia.org] says: “Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on t

      • by Mashiki ( 184564 )

        Those wikipedia articles are terrible. Give it a few more days and there will be full blown citeogenisis going on with references to some article written by a hipster on mashable or vox.

      • In spite of it being perhaps more difficult to exploit, I have the impression that large data centres operating virtual private servers (commercial and corporate alike) have good reasons to be seriously concerned about Spectre.

        Yes. Basically Spectre "Variant 2" / "Branch Target Injection" would allow to rent a VM on Amazon's cloud and spy on any other VM that runs on the same physical CPU.

        “Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on the same cloud server, {...} Wikipedia’s article on Meltdown [wikipedia.org] says: “Meltdown attack cannot be used to break out of a virtual machine.” (Of course, Meltdown is nonetheless a critical problem, for other reasons.)

        Meltdown / "Rogue Data Cache Load" specifically can access kernel (protected) memory.
        It is something specific to Intel CPUs.

        In order to make a few micro-improvement for speed, Intel CPU only check for protection at the last moment before committing the results to memory/register.
        That means that speculative execution might get pas memory protecti

    • Can I bill intel?
      Often sales fine print tries to limit the liability of the part make to the cost of the part. This isn't unreasonable especially if there's no really malice or incompetence involved. While my opinion of intel is in the dump now, I can't honestly say it was truly incompetent. One reason Boeing makes such good airplanes is that WWII taught them every way to make a mistake. Until you make one, you often don't see your own blind spots. One could have hoped for better or more dilligence but

      • While my opinion of intel is in the dump now, I can't honestly say it was truly incompetent.

        It wasn't incompetent, it was unscrupulous. They did it wrong, and told everyone they were doing it right. They knew what they were doing, and furthermore, they knew it compromised security. It's not that Intel can't do it right. It's that Intel will lie to you and play games with the security of your data.

        One reason Boeing makes such good airplanes is that WWII taught them every way to make a mistake.

        In computer terms, WWII was way back around the 486 or the Pentium. Now we're into the global terrist threat phase of computer security, and Intel is still acting like it's WWII and cutting some corners t

    • It seems the majority of people believe that Spectre (affects Intel, AMD and ARM) is just as dangerous as Meltdown

      It is just as dangerous, but it's also harder to exploit. But then we apply security fixes for all manner of unlikely attack vectors all the time. It's just not good practice to leave a known publicised attack vector which has been patched unpatched on your systems.

      Very few people have the resources to independently risk assess all patches that they apply.

    • by phorm ( 591458 )

      It's interesting how Intel managed to downplay the AMT issues, which IMHO are more in-line with Spectre in most cases (a bit worse in effect, easier to patch apparently), but is now playing up Spectre to have it overshadow Meltdown...

    • by Agripa ( 139780 )

      Intel has the best public relations officers that money can buy. This is less expensive than designing secure products and has a larger payoff.

  • Lawsuits (Score:3, Interesting)

    by ThisIsNotAName ( 2880693 ) on Wednesday January 24, 2018 @10:18AM (#55992507)

    Considering how poorly Intel has handled this, I'm looking forward to seeing the legal consequences.

    Intel's performance so far seems best described as "clown show." Especially for major, industry-wide patches that they should be sure will fix the problem without introducing crippling problems that are just as bad (or worse) than the original problem.

    • by Anonymous Coward
      I would not want to be an Intel shareholder right now. The lawsuits that arise from this clusterfuck are going to have some absolutely mind-boggling dollar figures attached to them. It wouldn't surprise me if at some point people die because of exploits that are done using these vulnerabilities. There is no way they can possibly patch all the processors that are susceptible to this. We'll be dealing with this for decades.
    • The issue are the bugs are architectural in nature and they can't patch them, it's not physically possible without redesigning the chip architecture from the ground up and doing a full recall of all existing chips. They would basically go bankrupt if they took the proper route to fixing it. Even on a best case scenario where it gets fixed and they don't require a recall it's going to take years of dedicated effort just to have a prototype of a chip without the bug and if they pursue that they will then be
      • by mark-t ( 151149 )

        Even on a best case scenario where it gets fixed and they don't require a recall it's going to take years of dedicated effort just to have a prototype of a chip without the bug and if they pursue that they will then be behind in the Intel-AMD arms race and go under.

        All certainly true.... except I think for the going under part.... they'd suffer, of course... but I don't think it would be bad enough to kill them off entirely. Intel has survived being behind AMD once before, back in the olden days when almo

        • Going under was in the context of also having done a recall. Keep in mind a recall+replacement would effectively be returning the last ~decade of sales revenue in full AND tripling-down on the R&D+production budgets to get everything replaced within a few years, AND not charging for it. They would definitely go under if they fixed the issue as they should simply following a fair deal "e.g. customer paid x for y, they should get y for x" - they have no practical mechanism by which to compensate people

    • I'm looking forward to seeing the legal consequences.

      There will be none. I'll bet you a dollar.

      • I agree. Nothing of note is likely to happen. I should have written that as "I'm hoping to see legal consequences." I hope it will happen, but I doubt that anyone is eager to take on Intel in the courts. They have enough money to thoroughly abuse the system in their favor.

      • There will be none. I'll bet you a dollar.

        I'll take that bet, if you like. I'll bet a further dollar that there will be none in the USA or Israel, but that there will be some in the EU. The EU loves to fine American companies.

        Odds are good that there will be no substantial penalty, at least on Intel's scale, but I'm not willing to bet along those lines. It depends on what happens in the EU, and I'm not sufficiently up on their politics.

    • by Agripa ( 139780 )

      Considering how poorly Intel has handled this, I'm looking forward to seeing the legal consequences.

      Do you mean like the legal consequences the telecommunications companies faced when it was discovered that they were handing everything over to law enforcement without a court order?

  • I have a Gigabyte motherboard and a Skylake Core i5 and installed the new BIOS update (which says "Update CPU Microcode") and so far it seems to be going good. No random reboots or crashes and no noticeable slowdowns.

  • by 110010001000 ( 697113 ) on Wednesday January 24, 2018 @10:46AM (#55992643) Homepage Journal
    Meltdown is an Intel only problem. Don't be fooled by people who say "but ARM is affected too". Baloney. None of those ARM processors are even on the market. And those ARM processors were co-designed by Intel.
    • Re: (Score:2, Informative)

      by Anonymous Coward

      Thanks for the scoop! I don't think Meltdown being an Intel only problem has ever been mentioned before.

    • ARM isn't affected by Meltdown. IBM is. It's not just an Intel problem, but it is an Intel problem for popular chips on the market. ... Lucky for Apple.

    • by DrYak ( 748999 ) on Wednesday January 24, 2018 @12:53PM (#55993453) Homepage

      Spectre Variant 2 is also heavily CPU specific.
      The exploit needs to know how the predictor used for indirect branches works (i.e. jumps where the destination isn't know yet, like jump tables (ways to do a C/C++ switch) or calling overloaded virtual C++ members in an array of object) in order too fool it and force it to guess wrong and jump to a completely wrong destination.

      It's been demonstrated on Intel CPU.

      ARM reports that the few Cortex cores that do speculative execution are affected.
      (But, no ARM-specific exploit code is mentioned).

      AMD knows that the Intel-specific code won't work (duh... obviously), but they cannot exclude that there won't be any way to exploit their indirect branch speculation ("near zero", not "zero" chance). Currently they recommend to apply patche, while they try to work out if there are possible viable exploitable to be made against their indirect branch prediction.

      PowerPC G3 and G4 are not exploitable, I've read. They *do* speculative execution. But they either don't speculate around indirect jumps, or don't speculate far enough to be actually exploitable in practice.

      • PowerPC G3 and G4 are not exploitable, I've read. They *do* speculative execution. But they either don't speculate around indirect jumps, or don't speculate far enough to be actually exploitable in practice.

        So we know that POWER7 through POWER9 are affected (patches are already out) and we also know that the latest POWER processor is not. All that leaves are POWER5 and POWER6, and since IBM has stated that more information will be forthcoming on those processors, it's probably safest to assume at this time that they are also vulnerable.

    • The Cortex-A75 [arm.com] is vulnerable according to ARM's own documentation.

  • by Anonymous Coward

    I just made the fatal mistake of clicking on a ZDnet article just to get to the source material - the HP link - and I happen to not be running ad block on this machine - well that will never happen again - ad block will be installed here too. I was starting to feel guilty about not supporting sites until I saw the vile state of internet advertising for the first time in a few years...

    Note to /. editors - please link to source materials as you did with Dell in the future and not lame ad filled articles th

  • They've gone out of their way to say that 90% of systems with recent Intel processors have been patched. With this announcement from Dell and HP they'll have to lower that percentage. Considering how much Intel likes to spin I suspect they'll say it's now 89% of systems patched.
    • Nope, they said no such thing. They said that 90% of their systems have patches available. Given it was always left to the vendors to issue these patches that 90% figure is not going to happen, at all, and definitely not on the day the microcode was released.

      • A patch that causes systems to reboot or otherwise be unstable is not a viable patch, so my comment stands.
        • It was never viable to begin with since most vendors would never push it out. Shit the last BIOS update I got was in 2014 and it is marked as Beta.

          Also if you want to get realllllllllly technical they never promised a lack of system reboots. Maybe the new patch comes with features that ensure you're always running the latest kernel. You know getting all those Linux sysadmins who insist they don't need to reboot after applying security updates. ;-)

  • Anyone know what Intel stock is doing these days?
    • Intel stock went up before the exploit was revealed, and hasn't moved much since then. It goes down a bit on bad news days, but then bounces right back. There's an earnings report tomorrow, and that should give us more visibility.
  • It is so fun to see still lingering Compaq branding and terminology popping up in HPs plantation.

    Shine on Compaq!

  • The problem is in the microcode of the CPU. This is a problem with how the chips are designed to handle instruction look ahead processing, and as such is Intel's responsibility as they designed and licensed buggy microcode. To fix an issue of this type properly you must fix the microcode AND replace the micro processor. Intel is trying to distance themselves from any responsibility as they would stand to lose a truckload of money replacing CPU chips. But as the continuing problems with the patch issues
    • no, not the microcode, the very hardware of the chip has flaws. Impossible to fix by microcode changes alone, the purpose of any microcode changes released are to allow patched operating systems the choice to avoid using certain features of the hardware, but the flaws will be there and it is entirely possible for the OS to mistakenly or in ignorance still use those flawed features. And it turns out so far all OS I know of that have attempted to conform to Intel's intentions have failures on certain hardwa

      • by HiThere ( 15173 )

        I think they could probably use microcode to turn off speculative execution. I'm no expert, so I could be wrong, but I think they could. If so, it's not impossible, it would just slow things down a lot.

        • I think they could probably use microcode to turn off speculative execution. I'm no expert, so I could be wrong, but I think they could. If so, it's not impossible, it would just slow things down a lot.

          They almost certainly could, but replacing an insecure processor with a slow processor is not a fix. All of this flailing around and releasing of garbage patches shows us that Intel is in panic mode, and they are not executing well. They are running in circles like decapitated poultry. As long as the FUD machine operates correctly though, and incompetents continue to tell lies about which processors are vulnerable to MELTDOWN (let alone SPECTRE) the stock price will stay more or less steady. If the EU annou

      • This very well may be the case specifically with the processors in question, but as a general concept it is not.
        Depending on the microarchitecture, things like permissions checks on TLB lookups, page table walks, can all be *implemented* in the actual microcode (DEC Alpha), making such a flaw a flaw in the microcode, not the silicon.
  • by thegarbz ( 1787294 ) on Wednesday January 24, 2018 @12:47PM (#55993385)

    I couldn't help but notice that the package "intel-microcode" was updated today. Given that I already had the 20180801 microcode installed I looked up the version of the package: "intel-microcode 3.20180108.0+really20170707ubuntu16.04.1"

    That's an interesting package management technique.

    • by ewhac ( 5844 )

      Yeah, I noticed this one the other day. The changelog is fun, too (Debian Sid):

      intel-microcode (3.20180108.1+really20171117.1) unstable; urgency=critical

      * Revert to release 20171117, as per Intel instructions issued to
      the public in 2018-01-22 (closes: #886998)
      * This effectively removes IBRS/IBPB/STIPB microcode support for
      Spectre variant 2 mitigation.

      -- Henrique de Moraes Holschuh <hmh@debian.org> Mon, 22 Jan 2018 23:01:59 -0200

      Even more amusing, this update showed up a day or two after Li

  • especially when the 'doctor' in this case is known to be a pathological liar.

  • "These updates have been causing numerous problems for users including performance issues, boot issues, reboot issues, and general system stability."

    So, these BIOS updates cause system stability? Why wouldn't I want to install them?

egrep -n '^[a-z].*\(' $ | sort -t':' +2.0

Working...