Intel rips up microcode security fix license that banned benchmarking Intel has backtracked on the license for its latest microcode update that mitigates security vulnerabilities in its processors – after the previous wording outlawed public benchmarking of the chips. The software, released this month, counters the Foreshadow aka L1TF Spectre-related flaws in its CPUs. However, its terms of use …
It depends a bit. A while since I was able to benchmark the loads I run on AMD, but my understanding is clustered multithreading on AMD cpus means if you're doing heavy floating point you can be in a similar situation to Intel hyperthreading, where one FPU shared between two 'cores' (AMD) or 'virtual cores' (Intel HT). The result is for heavy FPU work you'll probably find find you can't take advantage of HT anyway, while for more traditional server loads you could, I'd speculate on AMD bulldozer you might find you effectively have half the nominal cores for numeric work. Of course this doesn't change any hit on speculative execution from the spectre etc. fixes.
"FPU shared between two 'cores' (AMD) or 'virtual cores'" Eypc fixed that
Interesting to know, I hadn't looked at post-Bulldozer. It seems Zen (EPYC's architecture) is more Intel like with SMT, that'd make it more directly comparable in terms of quoted #cores:#threads (and I'll therefore place my bets that I will have to ignore 'threads' numbers for them too).
Debian kicked up a fuss, and Intel fixed the license. That's good news for a change.
> "You can't expect every lawyer to understand CPUs,"
No, but I'd sure as hell expect one working for Intel to understand CPUs, no different than I'd expect a lawyer working for Oracle to understand databases. It's a pretty basic requirement to understand your particular business.
Edit: they don't have to be an expert, but "duur, whut's a see pee yew?" isn't acceptable at the hourly rate these guys probably pull.
It looks like Debian's reasoning in this case was correct (they didn't want to be held responsible for '3rd party' benchmarks, which you KNOW are going to happen!). Unfortunately the REAL reason didn't come out in the earlier announcement...
In any case, it looks like Intel tried to pull a fast one. NOT good.
(Debian actually reads the fine print)
"Thank you, Debian."
Thank you indeed.
There are really two stories here: that Intel tried to use the licence to gag people from saying what the effects of the update would be, but possibly more than even this, is that all of the other guys were happy to use the patch with that licence as it was.
"but possibly more than even this, is that all of the other guys were happy to use the patch with that licence as it was."
Or more likely, they were happy to use the patch and just didn't give a shit about the license. As the article notes, Red Hat had happily ignored the prohibition and already published benchmarks before Debian started complaining. I imagine most others were the same - either they ignored it or simply didn't notice it in the first place. That's the thing that keeps coming up with software licenses and EULAs - most of them are unenforceable even when they're not actively illegal, and it's not just your average home user that doesn't bother paying any attention to them.
Or more likely, they were happy to use the patch and just didn't give a shit about the license. As the article notes, Red Hat had happily ignored the prohibition and already published benchmarks before Debian started complaining.
Could be that those vendors (at least one or two) knew how indefensible the clause was, and may have been inviting Intel to just *try* to uphold it.
Maybe, or maybe Red Hat simply considered that general guidance did not count as Benchmarks which are quite specific.
Either way Intel's approach seems to be leaning towards, if you want to be secure don't use our CPU's which doesn't seem very logical. Any enterprise buying lots of kit will want some sort of comparative measures and Intel would rule themselves out of this, ahem, benchmarking process. Their own salesmen would have gone up in flames about the same time as the poor punters trying to keep up with the patching...
I'm somewhat reminded of overhearing a gaggle of managers wandering aimlessly around an office at DEC bragging about how they didn't need to know anything about the industry because their leet management skills were so awesome. This was in the mid '90s, IOW around the time DEC was really struggling because of... well, people like them.
All credit to Debian for actually reading the fine print but this isn't an open-source issue: the problem is that the clause was unenforceable:
"You will not, and will not allow any third party to … publish or provide any Software benchmark or comparison test results."
This actually means that anyone who distributes the updated microcode can only do so if they are in a position to enforce this condition upon their users, or indeed anyone else - the "third parties" - who download the update from their repositories. Clearly, neither Debian, nor any of the other distros that waived it through, have the ability or authority to enforce this condition and so can't comply with it.
the problem is that the clause was unenforceable
No. That would be for lawyers (ultimately a court) to determine, and will inevitably vary between jurisdictions.
This actually means that anyone who distributes the updated microcode can only do so if they are in a position to enforce
"Enforce" in this instance meaning that you alert your users, by distributing Intel's notice. Putting it in an abandoned cellar behind a "beware of the leopard" sign (or perhaps something like in /etc/legalese/notices/intel/CVE-whatever-2018) should be fine, so long as they have it.
I'd sure as hell expect one working for Intel to understand CPUs, no different than I'd expect a lawyer working for Oracle to understand databases
Not necessarily but I would expect them to pass their work to an expert in the field for checking before it's released. That's called "due diligence" and lawyers are supposed to do it.
when lawyers do 'due diligence' it can (and probably will) still end up as a one-sided boilerplate agreement.
"Let's see, gives our client 100% rights in perpetuity, check. Limits the rights to complain or sue us, check. Requires mediation by our overpriced law firm only, check. Non-disclosure and non-compete agreements binding until 10 years after death, check..."
(I guess only Debian and people like me read the fine print)
Silencing the tools for consumer reviews--as well as enterprise performance metrics used as diagnostics and in sizing--is not a way to please the market.
But, this is kind of thing has reared its ugly head in the past, and it should have been killed off long ago. They should know better by now, and it's one of these things about which we'll have to be ever vigilant.
Yes indeed. There should simply be a law stating that benchmarking is a perfectly normal thing to do and publishing said benchmarks is protected by Free Speech (aka these are the results I got in this situation).
From that point on, companies can put whatever they want in their licensing terms, a judge will throw out any gag attempt on the spot.
I know conspiracy theories are great, but this looks more like a mistake in releasing the code with the license that was used with customers who were doing pre-release, under NDA, testing, than a real attempt to prevent benchmarks.
I know Intel can be stupid, but the lesser stupidity (releasing code with the wrong license) seems more likely to me than the larger one ("no benchmarks allowed").
Maybe you can find the Intel release engineer and sign them up for your "On Call" series!
I'm going for cock-up.
I doubt the technical people would be concerned about releasing the updates under a more open licence given the targets (i.e. OS vendors) and would have understood the technical issues and potential harm if customers read the licence and objected.
While the likes of Apple and MS and other larger companies can be confident of reaching a sensible outcome ("if you expect to enforce these, we will remove all updates from our OSes and let you deal with hardware manufacturers to get your CPU patches deployed"), it took one of the lesser vendors to make a stand.
Between the security cock ups and the move to 10nm, Intel feels like a company that has matured to the point where they can no longer make the "right" move on anything for fear of jeopardising their revenue much like Big Blue 30 odd years ago...
I thought this kind of customer-hostile bullshit had been found to be unenforcable in the US?
There should be a law that whenever a company tries to pull some crap like that, a lawyer has to be publicly disheartened on a fake Aztec Pyramid in Vegas as Mel Gibson looks on.
" ... a lawyer has to be publicly disheartened ..."
Do you mean ..... told s/he might not be getting all the yearly bonus/share options this year ?????
:)
P.S.
If you were alluding to the Aztec habit of removing hearts etc ....
I thought Corporate Lawyers did not have a heart !!! :) ;)
IIRC there was an announcement here (poss Arstech) which described the new chipsets which Intel was introducing.
And mirabile dictu, there are upcoming chips *which have no HT*. Cannot remember if the i9 does or doesn't, but the i7 is the other way round. And this does not depend on the core count.
So now we know why THAT has happened. No HT -> no slowdown from contention for the FPU, probably minor slowdown relatively but obscured by a clock speed jump, of course.
"I always though shared FPUs was a daft idea, especially for things like ray-tracing, or sound synthessis, both of which massively use FP calculations."
I'm using an Intel box for video transcoding. Even pre-patch, it was a faster with HT turned off in the BIOS. I guess it's the FP contention you and others have mentioned.
HT does not add additional cores, it simply enables a core that is stalled on one task to get on with another while the stall clears. In that sense the entire core is contended. It isn't a clear win but it is to misunderstand the basic principal to complain in essence that a single core doesn't have two FPUs.
Ten years ago I used to routinely disable HT on servers because on CPU-intensive workloads it almost always resulted in worse performance. Note that in one case the "CPU-intensive workload" was just OpenVPN.
I'm not sure if this was an inherent CPU design problem or the kernel scheduler getting confused. But HT has always been far from a clear win.
Quite possibly the latter. With HT the two logical cores are not equal - you have the lead core and the second essentially picks up the slack when the first is stalled so runs for only a small miniority of the time. If the scheduler is not aware of the distinction a process can get sqeezed by consitently being scheduled on the "reserve" core. Parodoxically this is more likely to causes issues systems that are otherwise underutilised - on a system with a lot of load on it processed get put on and pulled off cores frequently enough that everything evens itself out over not too long at all.
That's not the way that the threads worked on the STI Cell microprocessor, and it seems doubtful that Intel would do it either. At the level of the register file, the thread is simply a single bit set to either 0 or 1. Any kind of prioritization between the threads would require some fairly complicated logic in the queues in front of the execution units. And, as you observe, quite a bit of work from the complier as well.
Write what you like in the terms US lawyers, some of us live in free countries where your contract isn't worth wiping an arse with anyway. The only thing that bothers me with EULA and similar is that I lose 0.2 seconds clicking "I agree" while laughing and having not read your unenforceable bullshit.
I so wish I could upvote this more!
Just like the annoying ‘Anti-Piracy’ FBI warnings you still see on some videos (like on Netflix). Makes me smile wryly at the total overreach of it all.
Even in the heavily-surveilled UK we have more “Freedom” than the Trumpian Distopia.
(Currently!)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
