Intel forbids benchmark and comparison after microcode update (L1TF)

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

Stephan

Well-Known Member
Apr 21, 2017
920
697
93
Germany
Up until early 2018 I used to say "buy Intel, because less bugs, less problems". Yeah well, fsck that. The problem for the end user now is that they have to install and activate all those performance impacting fixes (i.e. get Windows 10, update like crazy, also keep a more or less recent machine that Windows 10 latest builds support), else some douche via JavaScript will try to escape your browser sandbox to leech credentials or anything else worthwile from your machine.

Also poor OS developers, I guess everyone but Windows (big on desktop) and Linux (big on servers and Android) and maybe iOS if affected (Apple has the inhouse developers and the money) is fscked if they use x86. Because either you just disable features like OpenBSD that disables SMT now, or you will run an attackable platform. For the big part everyone else simply imho doesn't have the man power or money to track and fix all those security issues on Intel x86.

I'd appreciate it if the European Commission would start an investigation and in the end fine Intel for delivering unfixable, insecure processors.
 
  • Like
Reactions: Tha_14 and Monoman

Patrick

Administrator
Staff member
Dec 21, 2010
12,511
5,792
113
This is much ado about nothing.

And @Stephan every CPU company even ARM and it's licensees have side channels, not just Intel. Being fair, Intel has been the most forthcoming about their vulnerabilities and fixing them. The same assumption of using branch prediction is what the entire industry used for decades. A bad precedent is punishing a company for fixing security issues.
 

Cmdrd

New Member
Jun 23, 2016
21
2
3
32
This is much ado about nothing.

And @Stephan every CPU company even ARM and it's licensees have side channels, not just Intel. Being fair, Intel has been the most forthcoming about their vulnerabilities and fixing them. The same assumption of using branch prediction is what the entire industry used for decades. A bad precedent is punishing a company for fixing security issues.
How is this much ado about nothing, unless you're just referring to Stephan's remarks? Not being able to publish benchmarks after a patch is a pretty serious stipulation to include in the license. I agree, good on them for fixing their security issues, but I think that's a pretty ridiculous thing to include the license.
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
This is much ado about nothing.
[Disclaimer: coming at this from the POV of the Debian furore regarding the EULA]:
#906158 - intel-microcode: Update intel-microcode to 20180807 - Debian Bug report logs

I have to respectfully disagree quite strongly here. This is effectively a security patch to a shipping product and the fine print is now saying that a) you're not allowed to redistribute the microcode (hence why Debian are up in arms about it as they can't legally distribute it any more as part of their security patches) and b) publishing of benchmarks of any code running on CPUs with this microcode are prohibited which means... well, as it stands on paper at the moment, no more benchmarking allowed without mutual consent from Intel - that goes for you and your site too Patrick.

Still, it'd certainly make AMD look infinitely faster than Intel on the graphs ;) Law of unintended consequences and all that.

Now of course you could argue that there's no way the EULA would stand up in court (indeed in most if not all EU jurisdictions it'd almost certainly be deemed an unreasonable term and thus null and void, and EULAs in general aren't considered legally binding) but the US is a different matter and, regardless, people shouldn't have to have to consult with a lawyer to apply a bloody security patch.

I'd have hoped given the year they've had Intel would be looking for all the good PR they could get. The marketing department needs to get take the spade away from the legal department. And then the engineering department needs to take away the spade from the marketing department, and then bury both the legal and marketing department in the holes along with some of the unearthed Atari ET cartridges.

E2A: Now I'm hoping what's happened here is that Intel have mistakenly attached the legalese for their Super-Secret Testing Microcode instead of using their normal legalese for the Totally Normal Redistributable Microcode; restricting distribution and testing on non-production microcode makes some degree of sense. But it makes no sense at all for applying to half the world's CPUs.
 
Last edited:

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113

PigLover

Moderator
Jan 26, 2011
3,184
1,545
113
I certainly think the Linux distributors will take it seriously, at least the "though shalt not redistribute the microcode" part. No way the public companies will risk it (RedHat, Canonical, Suse, etc.). And its unlikely that the open source communities like Debian will either.
 

dynamis31

New Member
Jun 21, 2017
21
13
3
57
This change in the EULA licence agreement aims probably the big cloud providers (AWS, Google, Microsoft Azure, etc) who generally post performance numbers for each BIOS/microcode/driver update to alert their customers and some scenarii may not match the performance impacts given by Intel PR (cf https://www.servethehome.com/intel-publishes-l1tf-and-foreshadow-performance-impacts/).
Anyway, it adds mess to the mess. Some people at the competitor side may appreciate.
 

Patrick

Administrator
Staff member
Dec 21, 2010
12,511
5,792
113
Intel already said they are updating the license for this.
 

William

Well-Known Member
May 7, 2015
789
252
63
66
I don't think Patrick gets his CPU's from Intel ?
Therefor he has no agreement with them, he can benchmark away.
 

Cmdrd

New Member
Jun 23, 2016
21
2
3
32
It will never be enforced.
I mean, that's like putting a gun to someone's head and saying you won't pull the trigger. If it wouldn't be enforced why put it in there?

Intel already said they are updating the license for this.
Glad to hear that.

I don't think Patrick gets his CPU's from Intel ?
Therefor he has no agreement with them, he can benchmark away.
The license pertains to installing the microcode, not an agreement when you purchase the CPUs, so it's entirely irrelevant where STH buys their CPUs.
 

Stephan

Well-Known Member
Apr 21, 2017
920
697
93
Germany
Care to stake your livelihood on that...?
This. The big multiplier publishing outlets will comply and so will the tech sites. Bad numbers quenched from most of the public eye, mission accomplished. Oh yeah, the little guys sitting in litigious countries will also comply, because of above comment. What remains will be benchmarks run by somebody from unheard of Russian forums that no one cares about or hasn't heard of.

I keep thinking this new clause is introduced for FUTURE changes in firmware, that impact performance even more than the latest L1TF changes, because there should be several more still unknown flaws waiting for a fix.

I do hope the European Commission will look into it, and also US courts in a class action suit, to punish Intel for botching the entire Core CPU line.
 

mstone

Active Member
Mar 11, 2015
505
118
43
46
That's not a new intel license, they've used it on other products before. I suspect putting on the microcode was an accident by a junior level packaging guy or somesuch (like, they just grabbed the wrong one). We'll see, based on whether it changes back relatively quickly.

For example: License Agreement to Download | Intel® Software is that license, but for the "memory latency checker" not microcode.
 

T_Minus

Build. Break. Fix. Repeat
Feb 15, 2015
7,625
2,043
113
Intel cannot do anything to me or you if we benchmark their physical product we purchased.

They cannot control what you and I do with the hardware after we buy it.

They cannot release a security patch and tell us if we apply it to make our system safe we are now bound by NEW rules, regulations, etc, this would be a huge lawsuit for them holding companies hostage from being secure unless they agreed to these new secrecy terms.

They can add stipulations like if you benchmark this ____ITEM___ then you void all warranty and release all liability to us, etc.
They can stipulate they won't give you free/review/etc items again if you go against their terms.


Like Patrick said this is nothing that's really a concern to anyone since it's not enforceable.

Not legal advise all my opinion.
 
Last edited:
  • Like
Reactions: Tha_14 and William

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
"Cannot control what you do with it" is true; "...but can try taking you to court if you do" is quite another thing entirely. As the text of the EULA stands currently, there's nothing to stop them initiating legal action against you if they so wish, and in jurisdictions that respect EULAs and other shrinkwrap licenses this could potentially mean a costly court battle.

If Patrick's post above about them changing the text is true, then great, but regardless of that, this is precisely the sort of heavy-handed legal strong-arming that needs to be called out for the idiocy that it is, even if it's an honest mistake, because otherwise someone'll think it's acceptable and try it again in future.
 

Patrick

Administrator
Staff member
Dec 21, 2010
12,511
5,792
113
The better question versus the EC tax on all CPU vendors (everyone else has side channel issues) is how can the EU incubate a company to build a competitive CPU architecture that is not vulnerable. China has successfully built its own chips. The EU has, or soon had ARM which also is vulnerable to side channel but what will replace?
 

Cmdrd

New Member
Jun 23, 2016
21
2
3
32
The better question versus the EC tax on all CPU vendors (everyone else has side channel issues) is how can the EU incubate a company to build a competitive CPU architecture that is not vulnerable. China has successfully built its own chips. The EU has, or soon had ARM which also is vulnerable to side channel but what will replace?
Maybe a POWER based CPU? Not sure if that architecture is vulnerable to side channel though.
 

mstone

Active Member
Mar 11, 2015
505
118
43
46
Maybe a POWER based CPU? Not sure if that architecture is vulnerable to side channel though.
Yes. Every modern CPU is. AMD has been luckier than Intel, somewhat because they made some better decision, somewhat because they were behind on optimizations. But they've still had issues, and if an issue is found that requires page table isolation to be activated on AMD chips, it will hurt much more than it does on current intel CPUs (no PCID). Remember, PTI wasn't invented for meltdown, it was just a handy mitigation.

What you need to avoid side channel attacks is a completely new paradigm for consumer chips, and a market that's willing to pay for that.