1. 59

Feels like a really bad move on Intel’s part.


  2. 33

    I don’t really think that you should be allowed to ask the users the sign a new EULA for security patches. You fucked up. People are being damaged by your fuck up and you should not use that as leverage to make the users do what you want so they can stop your fuck up from damaging them further.

    Patches only count if they come with the same EULA as the original hardware/software/product.

    1. 9

      Sure - you’re welcome to refuse the EULA and take your processor back to the retailer, claiming it is faulty. When they refuse, file a claim in court.


      1. 6

        This suggestion reminds me of the historical floating point division bug. See https://en.m.wikipedia.org/wiki/Pentium_FDIV_bug

        There was a debate about the mishandling by Intel. Also, there was debate over “real-world impact,” estimates were all over the charts.

        Here, it seems that the impact is SO big, that almost any user of the chip can demonstrate significant performance loss. This might become even bigger than the FDIV bug.

        1. 4

          They are being sued by over 30 groups (find “Litigation related to Security Vulnerabilities”). It already is.

          As of February 15, 2018, 30 customer class action lawsuits and two securities class action lawsuits have been filed. The customer class action plaintiffs, who purport to represent various classes of end users of our products, generally claim to have been harmed by Intel’s actions and/or omissions in connection with the security vulnerabilities and assert a variety of common law and statutory claims seeking monetary damages and equitable relief. The securities class action plaintiffs, who purport to represent classes of acquirers of Intel stock between July 27, 2017 and January 4, 2018, generally allege that Intel and certain officers violated securities laws by making statements about Intel’s products and internal controls that were revealed to be false or misleading by the disclosure of the security vulnerabilities […]

          As for replacing defective processors, I’d be shocked. They can handwave enough away with their microcode updates because the source is not publicly auditable.

          1. 1

            The defense could try to get the people who are discovering these vulnerabilities in on the process to review the fixes. They’d probably have to do it under some kind of NDA which itself might be negotiable given a court is involved. Otherwise, someone who is not actively doing CPU breaks but did before can look at it. If it’s crap, they can say so citing independent evidence of why. If it’s not, they can say that, too. Best case is they even have an exploit for it to go with their claim.

      2. 4

        I don’t really think that you should be allowed to ask the users the sign a new EULA for security patches.

        A variation of this argument goes that security issues should be backported or patched without also including new features. It is not a new or resolved issue.

        Patches only count if they come with the same EULA as the original hardware/software/product.

        What is different here is that this microcode update also requires operating system patches and possibly firmware updates. Further not everyone considers the performance trade-off worth it: there are a class of users for whom this is not a security issue. Aggravating matters, there are OEMs that must be involved in order to patch or explicitly fail to patch this issue. Intel had to coordinate all of this, under embargo.

        1. 2

          This reminds me of HP issuing a “security” update for printers that actually caused the printer to reject any third-party ink. Disgusting.

          1. 2

            I had not considered the case where manufacturers and end-users have different and divergent security needs.

            1. 2

              It’s worth thinking on more broadly since it’s the second-largest driver of insecurity. Demand being the first.

              The easiest example is mobile phones. The revenue stream almost entirely comes from sales of new phones. So, they want to put their value proposition and efforts into the newest phones. They also want to keep costs as low as they can legally get away with. Securing older phones, even patching them, is an extra expense or just activity that doesn’t drive new phone sales. It might even slow them. So, they stop doing security updates on phones fairly quickly as extra incentive for people to buy new phones which helps CEO’s hit their goalposts in sales.

              The earliest form I know of was software companies intentionally making broken software when they could spend a little more to make it better. Although I thought CTO’s were being suckers, Roger Schell (co-founder of INFOSEC) found out otherwise when meeting a diverse array of them under Black Forrest Group. When he evangelized high-assurance systems, the CTO’s told him they believed they’d never be able to buy them from the private sector even though they were interested in them. They elaborated that they believed computer manufacturers and software suppliers were intentionally keeping quality low to force them to buy support and future product releases. Put/leave bugs in on purpose now, get paid again later to take them out, and force new features in for lock-in.

              They hit the nail on the head. Biggest examples being IBM, Microsoft, and Oracle. Companies are keeping defects in products in every unregulated sub-field of IT to this day. It should be default assumption with default mitigation being open API’s and data formats so one can switch vendors if encountering a malicious one.

              EDIT: Come to think of it, the hosting industry does the same stuff. The sites, VPS’s, and dedi’s cost money to operate in a highly-competitive space. Assuming they aren’t loss-leaders, I bet profitability on the $5-10 VM’s might get down to nickles or quarters rather than dollars. There’s been products on market touting strong security like LynxSecure with Linux VM’s. The last time I saw price of separation kernels w/ networking and filesystems it was maybe $50,000. Some supplier might take that a year per organization just to get more business. They all heavily promote the stuff. Yet, almost all hosts use KVM or Xen. Aside from features, I bet the fact that they’re free with commoditized support and training factors into that a lot. Every dollar in initial profit you make on your VM’s or servers can further feed into the business’s growth or workers’ pay. Most hosts won’t pay even a few grand for a VMM with open solutions available, much less $50,000. They’ll also trade features against security like management advantages and ecosystem of popular solutions. I’m not saying any of this is bad choices given how demand side works: just that the business model incentivizes against security-focused solutions that currently exist.

        2. 1

          I think you have to be presented with the EULA before purchase for it to be valid anyway

        3. 13

          Well, what if a researcher do all these things anyway?

          When they publish the results, their licence ends. So what?

          Also, no state could allow the installation of such microcode on its hardware exactly because of this clausole.

          1. 8

            This license, whether on purpose or accident (see my other comment in this thread for elaboration), is granted to and focuses on OEMs :

            1. PURPOSE. You seek to obtain, and Intel desires to provide You, under the terms of this Agreement, Software solely for Your efforts to develop and distribute products integrating Intel hardware and Intel software. […]

            If you are a systems integrator, there is more than this license agreement binding you and Intel together. If you are not a systems integrator, this license isn’t about you, making the bolded assertion in the article false by being too broad:

            Intel has now attempted to gag anyone who would collect information for reporting about those penalties, through a restriction in their license.

            Intel made either a mistake or policy change related to their systems integrators. We will all get our benchmarks.

          2. 11

            NB: debian developers have noted that they have troubles repackaging the code into the distribution due to the new EULA included https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906158#14

            1. 6

              From your link:

              Intel has been made aware of the issue and pestered by just about everyone, and should get it straightened up soon.

              This issue circulated through a Slack channel I’m on last week and we had the presence of mind to at least collectively ask Red Hat to bring the issue up with Intel for us. Nevertheless I consider “pestered by just about everyone” to be an accurate description.

            2. 9

              From the article:

              Another issue is whether the customer should install the fix at all. Many computer users don’t allow outside or unprivileged users to run on their CPUs the way a cloud or hosting company does.

              I guess the key there is “the way a cloud or hosting company does.” Users typically run browsers, which locally run remotely-fetched arbitrary code as a feature. I would argue that because of browsers, users should especially install the fixes.

              The only time when a fix may not be applicable is on single-tenant configurations and when remotely-fetched arbitrary code isn’t run locally.

              1. 1

                Users typically run browsers, which locally run remotely-fetched arbitrary code as a feature.

                I was going to point this out too but you came first.

                However this opens an entirely different vulnerability set, a Pandora box that no one dares to face.

                1. 2

                  Great read, thanks.

              2. 9

                UPDATE: Intel has resolved their microcode licensing issue which I complained about in this blog post. The new license text is here.

                1. 5

                  Here the ‘new’ license text: https://01.org/mcu-path-license-2018

                  Here the license text prior to the 2018-08 microcode drop: https://tracker.debian.org/media/packages/i/intel-microcode/copyright-3.20180703.2

                  They’re identical.

                2. 9

                  Intel is the new Oracle

                  1. 4

                    Do we need Right-to-{benchmark,test,review} laws or will the free market fix this?

                    1. 1

                      The people paying for those laws are definitely doing that. The people not paying for laws rarely get to do so. They also keep voting for people that sell laws. So, things don’t change.

                    2. 3

                      This is the license equivalent of a bug regression. If you need a microcode update, do you get it from Intel? Your OEM (BIOS and motherboard) manufacturer? Operating system vendor? Intel would prefer microcode updates be loaded from the BIOS. They support doing so from an operating system.

                      Earlier this year, one of the microcode updates for Spectre/Meltdown got packaged by Red Hat, who later reverted it and added the following message:

                      The latest microcode_ctl and linux-firmware packages from Red Hat do not include resolutions to the CVE-2017-5715 (variant 2) exploit. Red Hat is no longer providing microcode to address Spectre, variant 2, due to instabilities introduced that are causing customer systems to not boot.

                      The latest microcode_ctl and linux-firmware packages are reverting these unstable microprocessor firmware changes to versions that were known to be stable and well tested, released prior to the Spectre/Meltdown embargo lift date on Jan 3rd. Customers are advised to contact their silicon vendor to get the latest microcode for their particular processor.

                      The license Intel granted earlier this month is clearly more targeted toward OEMs embedding microcode updates in their BIOS. Red Hat noticed the license change and reached out to Intel on the matter. I suspect that other OS vendors did the same. You can see the exasperation and coordination problems present before this microcode update, however.

                      I think Intel is still learning how to coordinate and release microcode updates when those updates also require software patches and may need hardware-specific handling by a subset of their OEMs. All under embargo. Here they tried solving part of that problem with a license change and caught OS vendors (and open source projects) out.

                      1. 2

                        It occurs to me that if you do not have the right to benchmark then you do not have the right to test that the product works as advertised. This cannot be legal.

                        1. 2

                          This license forbids systems integrators from publishing benchmarks related to this microcode. Presumably because Intel reserves that right to themselves. If you are not a systems integrator it doesn’t apply to you. If you are a systems integrator not only can you benchmark, clause 4 makes it clear you are under no obligation to share those results, even with Intel.

                        2. 0

                          Intel doesn’t care about freedom

                          1. 0

                            Awesome PR failure. Waiting for Barbra Streisand effect.