Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

perens.com

Post reply on HN
Print view View original

81–90 of 499 posts

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#81

Post by laumars »

TheRealPomax wrote: post #61
amluto wrote: post #13

I can think of two theories: 1. It's a mistake. Someone in legal got carried away. 2. The performance of the L1TF mitigation is so awful that someone at Intel thought it would be a good idea to try to keep the performance secret. (Which leads to option 2b. The performance of the L1TF mitigation is so awful that somemone at Intel is afraid that Intel could be sued as a result, and they want to mitigate that risk.) I w…

It works for Oracle (it is famously illegal to publish benchmarks of DB2 vs other engines), I'm sure intel can make it work for them thanks to Oracle's court case(s).

DB2 is IBM. The court case you were on about was Oracle's RDBMS called Oracle RDBMS. However I believe DB2 might have been used as one of the comparisons against Oracle.

Anyhow, specifics aside, you do make a good point.

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#82

Post by hvidgaard »

wtallis wrote: post #78
hvidgaard wrote: post #71

Earlier quoted context omitted.

Online media often relies on hardware directly from the manufacture when they get to test it before official release. Nothing stops Intel from not sending them anything anymore, and then they have to buy it from the stores like everybody else.

I'm well aware of the theoretical possibility of Intel blacklisting publications. In practice, it only works against smaller publications and would backfire spectacularly if they tried it against the larger publications. Intel has more to lose than any one tech publication.

> Intel has more to lose than any one tech publication.

I agree completely, but I wouldn't be surprised if waive threats of lawsuits around. And even though the media should be protected, it might still be relatively expensive for them.

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#83

Post by cyphar »

ddtaylor wrote: post #72
beefhash wrote: post #14

As a side note: Some of the license changes also block Debian from updating their intel-microcode package[1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906158#14

This seems like it would be a big deal considering this whole thing is related to servers and I have to imagine some server operators are running Debian? Maybe at the bare metal level their all running RHEL, which I presume doesn't care about the license restrictions.

From the article linked in TFA[1], Debian appears to be the only distribution that is refusing to release it. Gentoo has made it so that you have to agree to the new license when upgrading your intel-ucode package, while other distribution vendors (Arch, Red Hat, and SUSE) all appear to be shipping it without issue.

The argument from Intel is that the new changes don't actually affect distributions, as distributions are given the right to redistribute the microcode in the license (and this is separate to allowing third parties to publish benchmarks). Either that, or the lawyers at Red Hat and SUSE missed this somehow (though this is unlikely -- at SUSE all package updates go through a semi-automated legal review internally, similar to how openSUSE review works).

I do understand Debian's ethical issue with this though, and I applaud them for standing up for their users (though unfortunately it does leave their users vulnerable -- I imagine it was a difficult decision to make.)

[I work at SUSE, though I don't have any hands-on knowledge about how this update was being handled internally. I mostly work on container runtimes.]

[1]: https://www.theregister.co.uk/2018/08/21/intel_cpu_patch_lic...

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#84

Post by [deleted] »

eksemplar wrote: post #11

Aside from my vic20 and c64 I’ve only ever owned intel CPUs, and those two may have been intel as well, I wouldn’t know. I’ve never made a decision to chose Intel based on benchmark, I’ve bought them because they’ve always been great for me. So it’ll be ironic when I buy an AMD processor when I upgrade for cyberpunk 2077, because of benchmarks. Not because AMD is faster, they may be but I wouldn’t know, no, it’ll be…

[deleted]

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#85

Post by exikyut »

0xcde4c3db wrote: post #37
eksemplar wrote: post #11

Aside from my vic20 and c64 I’ve only ever owned intel CPUs, and those two may have been intel as well, I wouldn’t know. I’ve never made a decision to chose Intel based on benchmark, I’ve bought them because they’ve always been great for me. So it’ll be ironic when I buy an AMD processor when I upgrade for cyberpunk 2077, because of benchmarks. Not because AMD is faster, they may be but I wouldn’t know, no, it’ll be…

> Aside from my vic20 and c64 I’ve only ever owned intel CPUs, and those two may have been intel as well, I wouldn’t know. At that time, few home computers were based on Intel processors because they were too expensive. Commodore's early computers, like Atari's, were based on the MOS Technology 6502 (made by ex-Motorola engineers as a cheaper and easier-to-integrate alternative to the Motorola 6800; the corresponding…

One click-chain of curiosity later, and I learned that they sell a little educational SBC based on the 6502.

http://wdc65xx.com/boards/w65c02sxb-engineering-development-...

Pro: it looks like an AT motherboard from 1985

Con: it's $189 :s

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#86

Post by josemanuel »

squarefoot wrote: post #42

Sorry if I stress this even one more time, but we badly need 100% open iron, I mean something beefier than SiFive. If there is any effort in this direction, then, say for a year, most donations should be diverted over there. Closed hardware is becoming the unavoidable medium used to push closed firmware into everyone's system, that's a lot more important than benchmarks.

RiscV cores are not "open" iron. The only thing open is the instruction set. A pdf you download from the web. You have to pay $ to be in the governing body that adds new instructions. Not really an open source kind of thing..

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#87

Post by shawn-butler »

infinity0 wrote: post #45

> 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. For them, these side-channel and timing attacks are mostly irrelevant, and the slowdown incurred by installing the fix is unnecessary. lol, javascript

My opinion of Bruce Perens just decreased markedly.

Hopefully he will edit this blog post with better advice to the "casual" computer user.

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#88

Post by hanselot »

theprotocol wrote: post #68
infinity0 wrote: post #45

> 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. For them, these side-channel and timing attacks are mostly irrelevant, and the slowdown incurred by installing the fix is unnecessary. lol, javascript

>Another issue is whether the customer should install the fix at all Microsoft will surely decide for me on my Windows 10 gaming PC. Better save my work (which I sometimes do even on a gaming machine) frequently lest the masters deem it fit to restart while I'm away having lunch if they decide I can live with the performance hit.

It sounds a lot like you are blaming someone else for not having control of your computer.

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#89

Post by josefx »

blauditore wrote: post #63
infinity0 wrote: post #45

> 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. For them, these side-channel and timing attacks are mostly irrelevant, and the slowdown incurred by installing the fix is unnecessary. lol, javascript

Have timing attacks been done successfully in JS? I imagine it's much harder since you have much less low-level control and the engine might impose too much noise. However, wasm is a different story.

I think browsers currently have to limit the precision of their built-in timer APIs and they had to kill shared mutable state support for their thread APIs so attackers couldn't implement their own.

Re: Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed

#90

Post by terminalcommand »

lathiat wrote: post #8
johnklos wrote: post #2

I'm really curious how Intel could even imagine this is enforceable. For instance, if I have a server with shell access for many users, am I supposed to forbid my users from publishing benchmarks? If they do, am I liable since I "agreed" to the license? Or are they, even though they never "agreed" to the license? It just doesn't make sense.

Well the license specifically says you will not permit a third party to either. I don't really speak legalese, but does permit include having to then make all of your own users agree not to to avoid a penalty? As mentioned in the other comment thread though, I imagine the reality of this clause is to prevent media outlets (such as Phoronix who would traditionally do exactly this kind of benchmarking) from downloading…

> I don't really speak legalese, but does permit include having to then make all of your own users agree not to to avoid a penalty?

As a service provider, you will need to inform your existing users about this restriction and put the restriction in your user agreement for new users. After that you can relax, if any of your users publish benchmarks, you'll have to warn the user and then take the benchmarks out. You don't have to actively search for violations, but if you notice one on your own, or you get notified (for example via email), you'll need to take it down.

If we're not allowed to share the results of benchmarks and comparisons, the only action that comes to my mind is:

1) Never buy Intel again, if presented with a viable choice!

2) Prepare and share ready-made benchmarking live USBs/utilities, so people can see the horrors Intel has caused them without violating the license.

3) Dump benchmarking results online from countries, where the Delaware courts mentioned in the article has no jurisdiction upon.

4) Get every copy of this microcode license prepared for different countries, sue the license in each of them, and have Intel struggle with it.

Post reply on HN