Newsletter Archives

  • Intel says STOP installing firmware updates

    In another stunning announcement, Intel now says that you should NOT install firmware updates. No specific word on Surface devices yet, but I bet the Jan. 10 updates are suspect, as well. Of course, if you have Automatic Update turned on, your Surface device is probably already updated.

    Computerworld Woody on Windows

    UPDATE: In response to an anonymous post here, I re-read the Intel announcement, and it isn’t clear (to me) if the halt has been called just for Broadwell and Haswell chips, or for all of Intel’s product line. Here’s what the official announcement says:

    Updated Jan. 22

    We have now identified the root cause of the reboot issue impacting Broadwell and Haswell platforms, and made good progress in developing a solution to address it. Based on this, we are updating our guidance for customers and partners:

    • We recommend that OEMs, Cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions on the below platforms, as they may introduce higher than expected reboots and other unpredictable system behavior.
    • We also ask that our industry partners focus efforts on testing early versions of the updated solution for Broadwell and Haswell we started rolling out this weekend, so we can accelerate its release. We expect to share more details on timing later this week.
    • For those concerned about system stability while we finalize the updated solutions, we are also working with our OEM partners on the option to utilize a previous version of microcode that does not display these issues, but removes the Variant 2 (Spectre) mitigations. This would be delivered via a BIOS update, and would not impact mitigations for Variant 1 (Spectre) and Variant 3 (Meltdown).

    We believe it is important for OEMs and our customers to follow this guidance for all of the specified platforms listed below, as they may demonstrate higher than expected  reboots and unpredictable system behavior.  The progress we have made in identifying a root cause for Haswell and Broadwell will help us address issues on other platforms. Please be assured we are working quickly to address these issues.

    Then there’s a link to this list of Intel products, which includes Coffee Lake, Kaby Lake, Skylake, Broadwell, Haswell, Ivy Bridge and Sandy Bridge processors.

    Clear as mud.

    The spontaneous rebooting problem extends beyond Haswell and Broadwell. As Intel said on Jan. 17:

    we have determined that similar behavior occurs on other products in some configurations, including Ivy Bridge-, Sandy Bridge-, Skylake-, and Kaby Lake-based platforms.

    So it isn’t clear if the “Belay that order” order applies just to Haswell and Broadwell, or to Haswell, Broadwell, Ivy Bridge, Sandy Bridge, Skylake and Kaby Lake as well.

  • Intel admits that its Meltdown/Spectre firmware patches trigger reboots on Haswell and Broadwell computers

    If you own a PC with a Haswell or Broadwell processor (roughly 2014 to 2016 vintage), I strongly recommend that you refrain from installing the Meltdown/Spectre firmware updates, when they arrive.

    Intel’s detected a teensy-tiny problem.

    Computerworld Woody on Windows.

  • Intel “Kernel Memory Vulnerability” is going to hit all of us

    I first read about the problem in an article in The Reg yesterday from John Leyden and Chris Williams:

    A fundamental design flaw in Intel’s processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug… Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December…

    [The security hole] would allow ring-3-level user code to read ring-0-level kernel data. And that is not good.

    That was news to me, but we had a topic here on AskWoody started by @BillC just a few hours later. (I just discovered that I can’t put those comments under this post, so I’ve sealed off the original Code Red thread, and urge you to comment on this topic by clicking Comment on the AskWoody Lounge above.)

    It’s all vaguely reminiscent of the Intel Management Engine bug from 2016-2017.

    Lots of reason to be concerned, but there’s no immediate problem — and no known exploit. Suffice it to say that everyone running an Intel 64-bit chip will likely get hit. Apparently the Linux fix goes after AMD chips, too, although I don’t see any information about whether that’s due to a problem with AMD, or an overly zealous implementation in various Linux distros.

    Intel has the story under embargo, but I would expect we’ll get official notices shortly.

    Worth noting: Intel’s CEO Brian Krzanich sold $39 million worth of INTC stock on November 29. Just a coincidence, I’m sure. (Catalin Cimpanu has since withdrawn his tweet, saying “It’s not that bad. It was a legal sale in the eyes of the SEC.”)

    UPDATE: Alex Ionescu – “Windows 17035 Kernel ASLR/VA Isolation In Practice (like Linux KAISER). First screenshot shows how NtCreateFile is not mapped in the kernel region of the user CR3. Second screenshot shows how a ‘shadow’ kernel trap handler, is (has to be).” (Win10 17035 is the Nov 8 IoT beta build.) Thx @teroalhonen

    UPDATE: Hal Berenson: “Putting 2+2 together, my guess is you can see the fix in action here” pointing to this Amazon Web Services page

    Immediately following the reboot my server running on this instance started to suffer from cpu stress.

    We’re entering uncharted territory….

    UPDATE: Kevin Beaumont:

    UPDATE: Worthwhile details emerging, especially about the AMD fallout, on Reddit.

    UPDATE: There’s a report of Proof of Concept code from @brainsmoke.

    UPDATE: Ryan Shrout

    UPDATE: Intel (with stock down about 4% today, as of this moment), says that the security hole extends to other processors. Jordan Novet at CNBC has more from Intel’s point of view.

  • Intel Firmware Security Bulletin issued

    Six months on from the initial vulnerability disclosure on Intel Management Engine, Intel have issued a follow-up disclosure today, on a firmware vulnerability.

    Intel has identified several security vulnerabilities that could potentially place impacted platforms at risk. Systems using ME Firmware versions 11.0/11.5/11.6/11.7/11.10/11.20, SPS Firmware version 4.0, and TXE version 3.0 are impacted

    The details have been posted in the Code Red forum, but as we are missing the right panel widgets, you might not find that by navigating! Here’s the link

  • Intel draws fire for not supporting Win10 drivers on “Sandy Bridge” processors

    Intel’s not going to distribute some drivers, even for top-of-the-line i3, i5 or i7 machines from a few years ago.

    InfoWorld Woody on Windows

    Thanks for the initial post, GK.

  • The chip times are a-changin’

    Intel’s going to manufacture a fancy ARM chip, but the situation’s not as simple as you might think.

    InfoWorld Tech Watch

  • Intel pulls a fast one in Sandy Bridge fiasco

    See my InfoWorld Tech Watch blog, and beware the i5 and i7 chips.

  • Hyper-Threading Security Hole

    On May 13, a guy named Colin Percival delivered a talk at an operating system conference in Ottawa that described a gaping security hole in Intel’s Hyper-Threading technology.

    Apparently Hyper-Threading, which intricately intermixes calculations among multiple running programs, also mixes up access to a computer’s memory. Because of the way Hyper-Threading works in, for example, Intel Pentium processors running Windows, it’s possible for a tricky program with very limited security clearance to spy on another program. The example Colin gives is one of a Spy program that reads information – perhaps a highly secure password – while it’s Hyper-Threaded with another program.

    You don’t need to be worried about it. The exposure, at this point, only raises its ugly head if you are in charge of a secure server site. But it is an exposure, and it appears to be a genetic defect in the way Hyper-Threading (and Windows running on Hyper-Threaded machines) work. It’s being called CAN-2005-0109.

    Okay, Microsoft. Here’s another chance for you to issue a Security Advisory – or at least post something on your Security Blog. The major BSD operating system software companies have all issued advisories, as has SCO. If Colin is to be believed, Intel’s known about the problem for a couple of months, and presumably Intel informed its closest allies. Why haven’t we heard from The World’s Largest (and Richest) Software Company?