At this point if you are in for buying a new PC/server, your best option is AMD and will remain so until Ice Lake is relased.
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 …
COMMENTS
-
-
Thursday 23rd August 2018 19:49 GMT ibmalone
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.
-
-
Friday 24th August 2018 00:47 GMT ibmalone
"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).
-
-
-
Thursday 23rd August 2018 18:52 GMT Gene Cash
Open source works
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.
-
-
Friday 24th August 2018 02:05 GMT bombastic bob
Re: Open source works
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)
-
Friday 24th August 2018 06:11 GMT heyrick
Re: Open source works
"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.
-
Friday 24th August 2018 14:07 GMT Cuddles
Re: Open source works
"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.
-
Friday 24th August 2018 14:33 GMT jelabarre59
Re: Open source works
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.
-
Friday 24th August 2018 14:47 GMT Giovani Tapini
Re: Open source works
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...
-
-
-
-
-
Thursday 23rd August 2018 23:30 GMT Vometia Munro
Re: Open source works
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.
-
Friday 24th August 2018 10:36 GMT Anonymous Coward
Re: Open source works
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.
-
Saturday 25th August 2018 11:17 GMT Nick Kew
@LeeE
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.
-
-
Friday 24th August 2018 10:48 GMT DJO
Re: Open source works
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.
-
Friday 24th August 2018 14:05 GMT bombastic bob
Re: Open source works
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)
-
-
-
-
Thursday 23rd August 2018 19:44 GMT GnuTzu
No Benchmarks
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.
-
Friday 24th August 2018 09:34 GMT Pascal Monett
Re: No Benchmarks
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.
-
-
Thursday 23rd August 2018 20:09 GMT Anonymous Coward
Cock-up or conspiracy?
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!
-
-
Friday 24th August 2018 11:23 GMT Anonymous Coward
Re: Cock-up or conspiracy?
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...
-
-
Thursday 23rd August 2018 20:10 GMT Destroy All Monsters
You can't expect a lawyer this. You can't expect a lawyer that.
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.
-
Thursday 23rd August 2018 23:21 GMT Anonymous Coward
Re: You can't expect a lawyer this. You can't expect a lawyer that.
" ... 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 !!! :) ;)
-
-
Thursday 23rd August 2018 20:15 GMT Dyspeptic Curmudgeon
Now we can understand
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.
-
-
Friday 24th August 2018 01:19 GMT John Brown (no body)
Re: Now we can understand
"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.
-
Friday 24th August 2018 10:04 GMT the spectacularly refined chap
Re: Now we can understand
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.
-
-
Monday 27th August 2018 23:24 GMT Orv
Re: Now we can understand
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.
-
Wednesday 29th August 2018 11:26 GMT the spectacularly refined chap
Re: Now we can understand
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.
-
Wednesday 29th August 2018 22:27 GMT Claptrap314
Re: Now we can understand
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.
-
-
-
-
Thursday 23rd August 2018 21:42 GMT Lusty
Unfair contract terms
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.
-
Saturday 25th August 2018 19:25 GMT BugabooSue
Re: Unfair contract terms
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!)
-
-
Friday 24th August 2018 02:05 GMT wownwow
How many more INTENDED cheats are still inside?
Even worse, by peeling the onions people don't know how many more INTENDED cheats of not following the specs are still inside!
How can Intel and system companies be allowed to keep selling the known faulty products with the known flaws, amazing?
-
Friday 24th August 2018 04:33 GMT rmullen0
When will it be safe to by a new system?
My question is when will it be safe to by a new system and not have it have a huge performance hit due to these vulnerabilities? Do the latest CPUs have the vulnerabilities? I want to get a new computer, but, I want to wait until this has been resolved. I have a feeling that may not happen anytime soon.
-
Friday 24th August 2018 06:04 GMT Anonymous Coward
Re: When will it be safe to by a new system?
There's already several alternatives and in the case of AMD, actually quite a good choice especially on the price/performance ratio. Then the price and capabilities of the alternatives ramp up significantly on price but when you toss in native CPU capabilities rather than adding Tesla, Fermi, Volta or other GPGPU boards into the mix, aren't that far off. Too bad my budget these days is extremely limited. There's some really wicked things I'd be trying now, like nothing seen yet. To dream, ....
-
Friday 24th August 2018 14:35 GMT doublelayer
Re: When will it be safe to by a new system?
Functionally, there is only one viable alternative, that being AMD. There are a lot of other processor types available, but none that are convenient for consumer computers. ARM processors aren't sold in prebuilt machines, and even if there are ARM motherboards out there, you're probably heading for a compatibility nightmare. While there are some machines running ARM out there that are inexpensive for standard consumer use, would you really want to have a raspberry pi as your main computer for standard tasks? The latest one would be fine enough for browsing, coding, or word processing, but it has a lot of downsides if it is being set up as a desktop.
-
Saturday 25th August 2018 17:24 GMT heyrick
Re: When will it be safe to by a new system?
"would you really want to have a raspberry pi as your main computer for standard tasks?"
It pretty much is. And running RISC OS.
Anything I need to do that the Pi/RISC OS combination can't do, I can do on my phone these days (Firefox, email, streaming video...). I don't turn the PC on very much any more, and even with leaving the Pi on all the time, I've noticed a pleasing drop in my electricity bill.
-
Saturday 25th August 2018 19:41 GMT doublelayer
Re: When will it be safe to by a new system?
I'm glad that works for you. However, there are many tasks that people ask of their computers that a raspberry pi would not do to their satisfaction. Among these are modern games, high-speed browsing (think downloading a multi-gigabyte zip file and extracting it, which on the pi with its USB2 bus and SD card is going to be a lot slower), editing high-bandwidth data (images, audio, or video), even browsing pages with a lot of data to pull down and render and/or having a bunch of tabs open (I wouldn't want to deal with my family's complaints if they tried to do their standard browsing with only a pi core doing that for them). There are a lot of good use cases for one, even when running a full desktop, but there is a reason that a great many raspberry pi users are using them headlessly or as media devices rather than transitioning to having one as their main machine. However, my point was more about viable options for processors in consumer computers. In the sense of performance that is expected of a computer sold these days, intel and AMD are the only providers who 1. have such a processor available and 2. have that processor in a consumer-available machine. ARM has many such processors, but you can't get a computer with one in; the raspberry pi uses a much slower processor. Therefore, the only available alternative should you be concerned about the vulnerabilities or unwilling to hand over more money to intel but still want a standard desktop or laptop is AMd, at least for now.
-
-
-
-
Friday 24th August 2018 16:38 GMT Claptrap314
Re: When will it be safe to by a new system?
Based on my time at AMD & IBM for a decade just over ten years ago, I'm estimating 3 years from the initial report. That is, two years from now. There are rumblings that AMD will have something in a year. That feels aggressive. And a long ways out to trust.
The performance/watt of the new chips will be much, much lower than what we have been used to.
-
Friday 24th August 2018 07:25 GMT regadpellagru
"OpenBSD supremo Theo de Raadt today reiterated his plea to people to disable Intel's hyper-threading for security reasons. "DISABLE HYPERTHREADING ON ALL YOUR INTEL MACHINES IN THE BIOS," he carefully suggested in a mailing post post to OpenBSD developers and users."
I'm glad my latest build is based on an i5-4690K vs. an I7-4790K !
The only difference between both (apart from price) is ... HT :)
-
Friday 24th August 2018 07:55 GMT Anonymous Coward
Intel shooting itself in the foot
Forbidding benchmarking was stupid from the start.
First, it's not enforceable, because other than Intel there's no one care to enforcing their license.
Second, everyone in the tech community already know what these patches are for. It's for security with the drawback of lower performance. In another word, we already know there will be a performance hit.
Third, allowing benchmarking gives the customers the choice to decide whether or not they patch their system, in a security vs performance comparison. Banning it means they won't know why but the performance drop, causing more customers to move away from Intel product.
Intel, such license, many stupid, much backtracking, wow.
-
Friday 24th August 2018 08:28 GMT mark l 2
So lets say as an end user I have a regular task that I run everyday that usually takes 10 minutes to complete and then i applied the patch and then it takes 11 minutes. Intel were trying to tell me before they pulled this EULA that I couldn't have published this information. Ah haha good look with that one Intel.
-
Friday 24th August 2018 09:48 GMT Paul Smith
Silly season...
Does nobody else think this whole security risk business is getting a little out of hand? If you want a genuinely secure box, then you don't need to worry about whether or not it has any of the go-faster features that convinced us to buy it in the first place, you simply need to ensure that it is not connected to anything. For ultimate security, don't turn it on. If you must turn it on, then you must assume it is not ultimately secure and treat it with the appropriate caution. What is so difficult about that?
-
Friday 24th August 2018 10:43 GMT Mike Pellatt
Re: Silly season...
Nope, I don't.
No-one, anywhere, here is talking about "zero-risk". Of course there's no such thing in The Real World.
But, if 30+ years of vulns have taught us anything, it's that far too much stuff that looks low-risk on first, second, or even the hundredth examination, turns out to be easier to exploit that was realised in the earlier stages.
This is especially the case with these side-channel vulns, without too much in the way of thought experimentation, if you care to look at what they're actually all about.
-
Friday 24th August 2018 13:02 GMT DCFusor
Re: Silly season...
Well, while you can make a box secure...if you wanted to actually, you know, USE the thing - as in maybe take funds transfers from customers with it...you'd sorta need it connected to the customers. Kinda the only business model that actually exists that's really a business model anymore - other than defense contracting where they will mail you a fat check.
And this IS the age-old status of computers, and well, a lot of other things.
Make it super secure - it's unusable.
Make it usable, it's not super secure.
And all the king's horses and men want it different, and try to make it so, and at most make things a little better at the margins, while the lock pickers also improve their skills. It's the same old arms-race forever, with super job security for all the actors!
-
Friday 24th August 2018 14:41 GMT doublelayer
Re: Silly season...
If you're suggesting that we just ignore the problems, that's not likely. Sure, many of these vvulnerabilities aren't important (now) for our personal machines, but a lot of us, myself included, have virtual machines on a system that probably has some more ones. If there exists something that lets another VM user read or write data from mine, that's not a good thing for me. No matter that my VMs aren't doing something extremely secure, I don't really want others trying to break in.
Note here that I have made some trade-offs in doing this; my VM provider could do a lot of nefarious things if they were so inclined. I have taken that risk and chosen to trust them as a result of my paying them for the service. I am willing to trust that they will not alter my system or extract information, but I don't extend that trust to other users I do not know. The same would be true of each security vulnerability. We don't expect complete security, but we did expect a reasonable level of it. We are justified in being irritated with intel for repeatedly failing to make their processors secure.
-
-
-
Saturday 25th August 2018 00:34 GMT Ian Joyner
New generation of architectures
When many CPUs were designed in the past, the emphasis was for speed for scientific applications that basically ran on one machine. There was not the need for security.
We now need architectures and programming techniques that build in security (and correctness). We should not be worried that processor cycles are spent on security checking. Security has become fundamental in the modern world of computing. We should stop ignoring it for the sake of performance an optimisation.
But to bring around this change needs a change in attitude in almost the entire industry. The concepts of security and software correctness and verification have been around for over 50 years, but largely ignored in favour of dubious concepts like 'programmer freedom'.
-
Sunday 26th August 2018 13:54 GMT Anonymous Coward
The need for speed (OT)
In 1983 I was using an Osborne 01:
- Wordstar for word processing
- dBASE-II for some databases
- BDS C for some system programming
- SuperCalc for occasional spreadsheet stuff
- MediaMaster for moving stuff to and from an IBM PC
*
In purely functional terms, I'm doing many of the same things today. Of course today file sizes are bigger, there's a GUI hogging the CPU and there's the Internet (although even then there was Prestel!).
*
All this thirty year old activity was being supported by a Zilog Z80, 4MHz clock, 64K memory and two 192K floppies.
*
Am I dreaming? Even if all the Meltdown/Spectre-type patches are HALVING the speed of a modern processor (which they surely are not), then users are still sitting in front of a computer with many thousand times the power of the Osborne. Why the complaints about "speed impairement"?