Intel Publishes Microcode Patches, No Benchmarking or Comparison Allowed
perens.com
perens.com
I actually thought Intel must have had some tricks up their sleeves in terms of performance gains that we hadn't seen yet, simply because there was no market need to roll them out and they had so many years of coasting on marginal gains.
Seeing them taking this stance looks a lot like the microcode hit is that bad, and that the emperor has no clothes.
Clearly, they don't have an answer to AMD at all. If this is true, their shareholders should be asking serious questions about why they've nothing significant to show for all that time and money spent when they were raking it in without a serious competitor.
Big companies rarely innovate without competition around.
https://www.forbes.com/sites/forbestechcouncil/2018/04/19/in...
As you say, bigger companies have a harder time innovting.
Of course, if you are bigger, the more likely it is that there is no competition at certain times.
If you can survive without investing, a lot of companies choose not to.
Microsoft / IBM and now Intel defintely did.
I think it has more to do with the leadership of the company than the size of the company.
-ss
The Computerphile YouTube channel as some interviews with computer scientists that worked at Bell Labs during their heyday. It's incredibly interesting to hear about how they screwed around with early Linotype printers (which $100k+ in the 70s) and did things like reverse-engineer the font formats to create custom chess fonts.
They had direct-dial long-distance by 1951, using relays and tubes.
The transistor started making a difference in telephony with the release of the 1ESS switch in 1965. But transistors were a commodity by then.
If you're selling a subscription to a best-in-market service, there's not a lot of motive to innovate, agreed. Maybe you'd try a new product or a premium variant, but there's no reason to sink effort into advances that won't let you expand userbase or raise prices.
But for Intel? Before AMD got going, Intel's biggest competition was itself 9/18 months previously. Innovation wasn't just for new devices and new buyers, it was how they sold updated processors for machines that were already Intel Inside. They're not waiting on processors to die, they're actively pushing for them to be replaced for performance reasons.
That might create an incentive to release 'good enough' updates and dole out big improvements gradually, but in practice any of that which happened was already ending. Intel appears to be up against the wall regarding 10nm even with a competitor, and has been attempting major innovations to handle 7nm and below for years. With a revenue stream that relies on annual improvements to their product, they seem to have been learning hard into innovation and struggling, rather than waiting for a competitor.
The common complaint about subscription models is obviously good: if the company folds you have nothing, instead of an unsupported product. But it neglects the other issue, which is that companies intentionally cut off the possibility of "good enough" to guarantee revenue.
I don't think its an accident that products like Microsoft Office went to subscriptions around the time it becomes very hard to imagine a new feature actually worth buying for.
They still have a huge opportunity for CPU+FPGA, they bought Altera for the purpose.
http://conal.net/blog/posts/haskell-to-hardware-via-cccs http://conal.net/blog/posts/circuits-as-a-bicartesian-closed... https://github.com/conal/lambda-ccc/blob/master/doc/notes.md
If Intel can release a CPU with a built-in FPGA and everyone has one, software developers will take advantage of them. I can see stuff like video editing programs, compression algorithms, etc taking advantage of that.
Also, did they try to use enhanced locality introduced by processing several streams on GPU? E.g., if you keep states sorted as for tuple (state id, stream id) for all your streams, you may get more memory-controller friendly access pattern. I haven't seen mentions of that technique (which MUST be considered after Big Hero 6 [1] - they used that technique to never miss caches in whole movie rendering process). Big Hero 6 is 2014, the paper is 2017.
[1] https://en.wikipedia.org/wiki/Big_Hero_6_(film)
I really do not like papers like one linked by you. One system gets all of the treatment while other ones get... whatever is left.
I guess have they tried to use these techniques for GPUs, they would get performance gap that is much less than reported.
FPGA is great if you need to talk to some hardware very fast/on many pins. E.g. something like a network router where you are shuffling packets between many high speed interfaces. Or doing a lot of measurements/interfacing a bunch of high speed sensors.
But not for general purpose software - GPUs are both faster, easier to develop for (and with good tooling) and much cheaper for doing that today.
The obvious way forward is universal specialized coprocessors, reprogrammable for the task(s). Better if tightly integrated with the memory, buses and CPUs.
The weak side of FPGA historically is programmability and especially the tools. But since the interest for FPGA is growing exponentionally in open-source community in recent years, things may change.
And by the way, 10 years ago you would say that exactly 'niche' words about GPU.
Similarly, we’re finding more functions we can take away from the CPU and migrate to dedicated circuitry (FPGAs) that can handle those tasks more efficiently than the CPU can.
GPU's avoid the overhead of FPGAs while still retaining a lot of flexibility.
But, to clarify, I was speaking of consumer/mobile. The original iPhone was quite revolutionary for having a decent PowerVR graphics chip. High end symbian phones just had a CPU. See for example https://en.wikipedia.org/wiki/Nokia_6110_Navigator or https://en.wikipedia.org/wiki/Motorola_Razr2
Even though GPGPU was already big in 2008, people still thought of it as a difficult to use coprocessor for big compute jobs. Much as people consider FPGAs now.
And the first iPhone shipping with a powerful graphics chip is a counter to your argument that the future of mobile wasn't clear. The people with the ideas wanted a graphics processor.
There are uses for FPGAs where there's enough money at stake for the hardware development but the number of units is small - stuff like high frequency trading or many defense roles. Or in the development of new hardware. But it's pretty niche.
https://www.nextplatform.com/2018/08/22/arm-stands-on-should...
Not a thing for everyday desktops, but looks like compute competition is er... heating up. :)
> a 2004 study by Bain & Company found that 70 percent of mergers failed to increase shareholder value. More recently, a 2007 study by Hay Group and the Sorbonne found that more than 90 percent of mergers in Europe fail to reach financial goals.
http://edition.cnn.com/2009/BUSINESS/05/21/merger.marriage/
Especially when the merge should be deep and involve engineering teams with different cultures to join and work together on the product. So I'd consider the release of first Xeon+FPGA after 3 years past acquisition as a somewhat success.
I would have guessed additional lead time for Altera to move their designs from TSMC to Intel process, but it looks like Altera has been planning to fab on Intels 14nm since 2013[0].
https://www.tomshardware.co.uk/intel-cpu-10nm-earnings-amd,n...
There are other services like Packet that offer bare-metal hosting on small Atom and ARM processors. It'd be nice to see some alt x86 processors in this space.
I think you're more likely to see some ARM CPUs which have comparable performance to low-end and mid-range x86 before you see a new x86 competitor [1] - the overhead to making x86 perform well is just so high that I can't imagine anyone new bothering to get into the space. VIA has been in the market forever as the third seller of x86, and despite the theoretical benefits of entering into the datacenter CPU market, they've never made that leap (though I don't know enough about their history to know if they tried).
I'm hoping that ARM becoming competitive in the client CPU space ends up making the cross-compile overheads of enough drivers/kernel stuff that we can start to see some more diversity in the CPU market overall. I'm excited about RISC-V, especially now that they have shipping hardware you can play with today [2]. The Mill CPU sounds super cool in a bunch of ways, but the architecture has made so many decisions that I'm unsure will play out in practice I'm holding my excitement until I see real silicon somewhere [3]
[0] https://arstechnica.com/information-technology/2018/07/china...
[1] https://www.engadget.com/2018/08/16/arm-says-chips-will-outp...
They haven't, they instead entered the niche of low-cost kiosk hardware. Intel and AMD completely abandoned it due to lower profit margins, but plenty of raw sales numbers to help Via float by.
They might have also baked in slight tweaks or customized whatever back-doors could be included if such things exist...
It's better to think of it as a Chinese subsidiary in a franchise system.
It depends where about on the timeline. AMD's hired of Lisa Su and Jim Keller in 2012, we all thought it was too little too late. Look back at the Roadmap Intel were giving at the time, I used to joke about Tick Tock were like the sound of AMD's death clock. In 2012 we were looking at 10nm in 2016, 7nm in 2018, and 5nm in 2020. We just had Sandy Bridge, but that was the last big IPC improvement we have had.
Fast forward to 2018 / 2019, No 10nm, and I would have been happy if they were selling me 14nm++++++ Quad Core Sandy Bridge. Broadwell and Skylake brings nothing much substantial. Intel were suppose to break the ARM Mobile Market with tour de force, and that didn't happen.
We all assumed Intel had many other tricks up its sleeves, new uArch or 10nm waiting in the wings when things are needed. Turns out they have nothing. Why did they buy McAfee?( Which has been sold off already ) And Infineon? Nearly eight years after the acquisition they are just about to ship their first Mobile Baseband made by their own Fabs, Eight Years! What an achievement! Nearly three years after their acquisition of Altera, which itself has been previously working with Intel Custom Fab before that. What do they have to show?
During that time, the Smartphone revolution scale has helped Pure Play Fab like TSMC to made enough profits and fund their R&D rivalling Intel. And in a few more weeks time we will have an TSMC / Apple 7nm node shipping in millions of units per week. In terms of HVM and leading node, making TSMC over taking Intel for the first time in history. AMD has been executing well following their Roadmap, and Lisa Su did not disappoint. Nothing on those slides were marketing speaks or tricks that Intel used. No over hyped performance improvement, but promise of incremental progress. She reminds me of Pat Gelsinger from Intel, Down to Earth, and telling the truth.
Judging from the Results though, AMD aren't making enough of dent in OEM and enterprise. Well I guess if you are not buying those CPU with your own money, why would you not buy Intel? The consumer market and Small Web Hosting market though seems to be doing better, where the owners are paying. I hope Zen 2 will make enough improvement and change those people's mind, better IPC, better memory controller.
If you loathe Intel after all the lies they have been telling and marketing speaks, you should buy AMD.
If you love Intel still after all, you should still buy AMD, teach them a painful lesson to wake them up.
https://www.theregister.co.uk/2017/08/09/intel_puma_modem_wo...
Ironically, Broadwell's 128MB L4 cache did bring a substantial performance boost to a whole range of real-world applications, but it seems it's so expensive to manufacture that they've subsequently dropped the feature except for Apple's iMacs and expensive laptops.
> If you love Intel still after all, you should still buy AMD, teach them a painful lesson to wake them up.
But how do I choose which AMD CPU I need ? Back in my youth p4 and athlon were easy to compare (freq., IPS and a modifier because AMD) but now I can't even tell the differences between any i5/3/7 and when I look at AMD names it's as confusing but with a different lingo. I feel the same regarding GPU so maybe I am too old for that now.
Ryzen 1 - slow, medium, fast, elite
Ryzen 2 - slow, medium, fast, elite
pick the one you need based on pricing/discounts if any. It's not that hard really.
For gen 2, that'd be:
23xx, 25xx, 27xx, ThreadRipper.
I think they picked the names/numbers to show some kind of equivalence with i3/5/7, but that's not quite it.
ThreadRipper is interesting. It requires a different socket than the other desktop processors and is targeted more at workstation class machines.
In servers there are Epyc and Epyc 2.
Threadripper is their workstation CPU.
slow (3), medium (5), fast (7), elite (Threadripper)
If you don't want to spend more than USD$800 on the CPU alone, don't look at the elite/threadripper line.
What is your budget? That is the first question you need to answer instead of trying to understand the entire line of chips, look at how much you have to spend, and then find the fastest one within the budget.
It's useless to try to think about the entire line of CPU's when you will only buy 1 chip (unless you are representing Dell and need to buy thousands of chips)
They way I see it, I could look at AMD's Core count, Threads and Frequency, As they are clearly labelled, and that is it. On Intel's side you have features turned on and off for different i3/5/7/9, AVX speed difference etc I don't even want to bother looking it up.
Seriously, Intel has always been way too confusing with their processor lineup. AMD has always been straightforward: leave in the kitchen sink on nearly every CPU and performance scales with price. Not linearly of course, but it's much simpler to choose an AMD CPU.
Basically, if you don't want the headache you just buy one of the highest end/most expensive CPUs on offer and you're probably fine. With AMD the feature set is pretty consistent, so you have considerably more choice to find a good price point.
We're not talking minor performance differences in features, we're talking features randomly added and removed for no logical reason from the same generation & tier of CPU model.
"Gamers need these features, but gamers often also setup servers. Let's remove server features from gaming CPUs so they can't reuse them when they upgrade, and so they have to buy new server CPUs!"
In comparison, AMD's offerings are surprisingly easy. There's a handful of SKUs differentiated on core count and frequency. Generally they all have the same PCIe lanes, RAM access, SMT, instruction sets, and so on.
A project of mine is a hardware recommender, it also includes a meta-benchmark. I collect published benchmarks and build a globally sorted order of processors out of it. https://www.pc-kombo.com/benchmark/games/cpu for games, https://www.pc-kombo.com/benchmark/apps/cpu for application workloads (that one still misses a bit of work, the gaming benchmark is better). Legacy processors are greyed out, so this might be a good starting point for you. There is also a benchmark for gpus.
For most people this processor choice is also very easy, it is "Get a Ryzen 5 2600 or an Intel Core i5-8400."
Feel free to ask if you want some custom recommendations, email is in profile :)
Also, the existing bar graph is unclear to me. What does 10/10 mean?
Example, fictional values: The 8700K is the fastest, because it was most often seen as the benchmark leader. It gets a 10. The 8600K has almost the same FPS, but it was always a bit slower, it gets a 9.9. The i5-8500 comes next, but its average FPS scaled to the 0-10 scale is lower, it gets a 8.7. Then the i5-8400, always seen as slower than the 8500 in benchmarks, would at most be able to get a 8.6, no matter what the average FPS says (with enough benchmarks average FPS become an almost meaningless metric, it's the position in the benchmark that counts).
That's why it is not possible to calculate price/performance with this. I could only highlight good deals, processors that have a high position despite being cheaper than the processors below. Which is of course already baked into the logic of the recommender.
But they have lots to show for that money!
Brand change implementations such as "Gold" and "Platinum", which gouge the customers more than ever before.
I never met a person with a smart phone that uses an intel chip. They probably exist but i know none.
Apple aren't using them. Samsung aren't.. HTC nope.. Google pixel nope...
Intel basically sold off/scuttled their mobile division right before the iphone took off.
> It comes as Microsoft continues its work with Qualcomm to optimize Windows for devices powered by Qualcomm's Snapdragon chips, including the forthcoming Snapdragon 850, which Samsung used for its first Arm-based Windows 10 laptop. So it appears there is some momentum behind the concept.
https://www.zdnet.com/article/arm-on-windows-10-chromebooks-...
However, I used to own a Tegra K1-based Chromebook, and that thing was sl-o-o-o-o-o-o-w, and it only got worse with successive updates. I'm not really optimistic when it comes to performance, absent highly-optimized apps. The state of Firefox and Chrome doesn't really fill me with confidence.
I'd like for ARM laptops to become more popular though, as a Debian user nearly all the software I use is already there.
it seems that Intel couldn't jump into EUV manufacturing when they were in full domination because it was too expensive and new so they started improving multipatterning so improve resolution, which proved too hard to ship (hence the delays) meanwhile smaller players went their way until recently and now EUV is accessible so they can jump in swiftly while intel is still caught inside his intermediate strategy, lazy market behavior and unforeseen failures. They also have EUV planned but not until the next-generation. Note that even at larger pitch their process is near competitive with smaller ones today, but it sounds terrible.
traditionally yes, intel has absolutely dominated the laptop market however i have been seeing a lot more laptops lately with a Ryzen processor and Vega graphics
AMD making gains into a very lucrative market
I kick myself for not buying AMD at $2 (or buying a LOT more at $5).
Even if you buy this, (I don't), there's no point for them to stay in business with absolutely non-competitive products. The remarkable thing is that thanks to Zen that did not happen and Intel actually feels some heat for the first time in years.
I just looked this up, and it seems to boil down to the patent cross-licensing agreement between Intel, which developed the x86 architecture, and AMD, which developed the 64-bit instruction set. I don't think there's a unilateral "non-transferable license" per se — and they're free to enter into a new agreement if either party does get acquired.
This Reddit thread seems pretty good at explaining it in much more detail: https://www.reddit.com/r/hardware/comments/3b0ytk/discussion...
This might be the answer. No competition and a good cash flow is a comfortable position. You defend this model with ads, policy, etc. and technical innovation can languish. I am not saying this is necessarily the case, but it is possible that Intel just got comfortable, slow and fat. Having a scrappy, smart competitor can be a good thing.
ARM and RISC-V have become a serious thread and are on the way to get standardized ecosystems...
I am going to do that today. While we only have several thousand users they do CPU intensive work, buy a lot of new CPUs and rent a lot of servers. My small contribution will likely amount to low-mid 6 figures out of Intel pocket in coming 2-3 years.
Please consider such announcement if you could do some damage as well.
It would've carried that much more weight if it were _your_ low-mid 6 figures that were redirected away from Intel.
As they allow more cores per socket this can also often massively reduce per-socket licensing cost, if you have the misfortune of using software which requires that.
I think the idea for HPC though is that you want to offload these highly vectorizable operations to a GPU. Or maybe you're doing a lot of Monte Carlo that it is hard to vectorize.
I really do like avx-512 though. If you're writing a lot of your own code, and that code involves many small-scale operations and has control flow (like in many Monte Carlo simulations), it's a lot easier than mucking with a GPU. If you're using gcc though, be sure to add `-mprefer-vector-width=512`, otherwise it will default to 256 bit vectors (clang and Julia use 512 by default).
AMD's chips definitely speculatively execute instructions. It's a common performance trick.
AMD's chips also definitely throw an exception at retirement (of course) for instructions that attempt to load a privileged address, just like Intel's chips do.
The difference is that when AMD's chips see a load instruction, the load isn't executed until it knows that the address isn't privileged. Intel's chips do execute the load (but then throw away the result when it realises the address was privileged).
The speculative part is for instructions that depend on the result of the load.
Thank you for the detailed explanation, can't we conclude that AMD engineering is more defensive then Intel, this is what I concluded.
Both AMD and Intel hire really smart people, but this stuff is really, really hard.
It's clear that AMD weren't doing anything special w.r.t. side channel attacks. They were just further behind in the optimisation race and as a consequence, were less hit.
For this particular optimization, it looks better not to have it.
But in general, knowing how something is flawed lets you mitigate the flaws. We use floating point despite it being mathematically wrong, because it's fast and we can mitigate the wrongness. I could imagine a chip where speculation could be toggled between different modes, if there was enough demand.
I will say that "just further behind" is probably wrong. AMD has a lot of optimizations in their chips. They have safer ones, which might be luck or might be engineering talent, but it's not a mere artifact of being behind the curve.
AMD enforce privilege checks at access time rather than at retirement time. Whether or not this is due to "lack of optimization" or "good security engineering" nobody knows. But your claims that this was purely the result of "less optimised [sic]" cores is nonsense. You have zero evidence whatsoever that that was the case vs. AMD just having superior engineering on this particular aspect and not adding bugs to their architecture.
All we know are that Intel & ARM CPUs have an entire category of security bugs that AMD don't, and that upon close analysis AMD's CPUs are operating in a more secure foundation.
If AMD were making conscious efforts to avoid side channel attacks they'd already have had various features to show for it like IBRS. But AMD's chips say nothing about side channel attacks. Their manuals do not discuss Spectre attacks. And there is no evidence anywhere that they knew about Meltdown type attacks and chose to avoid them.
I get that suddenly hating on Intel is cool and popular, but the facts remain. There is no reason to believe AMD has any advantage here.
The facts are AMD does not have a significant per-core IPC defeceit vs. Intel (as supported by every ryzen review at this point) and AMD has, on multiple occasions now, had objectively superior security.
You're trying to twist this into a negative against AMD. It's nonsense FUD. Intel fucked up, AMD didn't. Why are you trying to run PR damage control for Intel?
I am really unsure where you're getting this from. Your reference to the spec makes me wonder if you really understand what Meltdown and Spectre are. They aren't bugs in the chips even though some such issues may be fixable with chip changes, because no CPU has ever claimed to be resistant to side channel attacks of any form. Meltdown doesn't work by exploiting spec violations or actual failures of any built in security logic, which is why - like Spectre - it surfaces in Apple chips too. Like Spectre it's a side channel attack.
I'm not trying to twist this into a negative for AMD: it's the other way around, you are trying to twist this into a positive for them, although no CPU company has done any work on mitigation of micro-architectural side channel attacks.
I'm simply trying to ensure readers of this discussion understand what's truly happening and do not draw erroneous conclusions about AMDs competence or understanding of side channel attacks. What you're attempting to do here is read far more into a lucky escape than is really warranted.
Memory was accessed that the spec says was not accessible. This has nothing to do with side-channels. The side channel part of the attack was how the spec violation was exploited.
For Meltdown specifically Intel fucked up, AMD didn't. This is not at all vague. Whether or not this was due to luck or not is irrelevant, it was clearly NOT due to incompetence as you were pushing. You pushed a narrative that AMD was too incompetent ("missing optimization") to have a severe security bug. That has nothing to do with reality whatsoever.
Side note, side channel attacks are not exactly obscure. Guaranteed AMD & Intel have security experts that are well aware of how side channel attacks work long before any of meltdown & spectre came to light. They have been around for ages. Practical exploits of L1/L2 cache via mechanisms like Prime+Probe date back at least as far as 2005: https://eprint.iacr.org/2005/271.pdf
Intel has two faults: one, they made a significant mistake in their chip design, and two, they responded to criticism poorly. AMD did not make the mistake and has responded well to criticism.
In the Desktop space, I can definitely recommend AMD. But Laptops are totally Intel right now.
There are AMD Laptops, but they are hard to recommend. Most are low-end offerings at best (laptop manufacturers don't put the high-end stuff with AMD). As long as high-end HP / Dell / Lenovo / Asus / Acer / Apple / Microsoft Surface are all Intel-based, you're basically forced to use an Intel Laptop.
Desktops... you can build your own. And even if you couldn't, there are a ton of custom computer builders out there making great AMD Desktop rigs.
-------------
With that being said, AMD laptops are competitive in the $500 to $750 space. Low-end to mid-tier laptops... the ones with poor mouse controls, driver issues, bad keyboards, low-end screens and such.
But hey, they're cheap.
Its not really AMD's fault. But in any case, its hard for me to find a good AMD laptop. So... that's just how it is.
Kind of waiting to see what the Lenovo ThinkPad A285 looks like, as well.
That's what I'm talking about: most laptop manufacturers offer a "premium" Intel laptop. But then they have a lower-quality AMD one on the side.
Nothing AMD has done wrong per se, just laptop manufacturers refuse to sell AMD on the high-end.
Going with AMD at this point is simpler, better for security, and if you care about this sort of thing -- rewards more honest and less consumer-predatory behavior. I've always gone with Intel my whole life, but given these many incidents with Intel, combined with their really poor public responses to it, I will now be switching to an AMD user for all future PC builds.
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 would guess it's #1.
Anyhow, specifics aside, you do make a good point.
Isn't that a blessing?
* cease and desist orders. They could probably argue improper use of trademark or something. And by "could" I don't mean "they have a legitimate legal case" but rather "a flimsy one but one that is still scary enough that few people might want to take the risk / expense testing the argument in court.
* many benchmarks are ran by reviewers who might have access components before they hit the shelves. It would be trivial for Intel to end that relationship. If it's suppliers further down the chain who are providing samples to journalists and reviewers then Intel might put pressure on those suppliers to end their relationships with said journalists. This might break a few anti-competition laws in the EU but it's not like that's ever stopped businesses in the past.
On a tangential rant: I think the real issue isn't so much whether it is enforceable but rather the simple fact that companies are even allowed to muddy the waters about what basic journalistic and/or consumer rights we have. I'm getting rather fed up of some multi-nationals behaving like they're above the law.
It actually makes it easier for Intel to argue that chips are such specialized bits of equipment that even though your average joe can _get_ one, they won't understand how it works and so only highly trainer professionals who have been certified by Intel would be able to reliably benchmarks their products. "As the average user would interpret the results incorrectly, their publication would hurt intel's bottom line". And suddenly you're 95% of the way to having won the case already.
(it disallows comparing the product against the competitors)
> Cloud Company: Your honor, the security flaws in the hardware and microcode provided by the defendant necessitated the installation of updates, also provided by defendant, which resulted in a 30% loss of overall performance. Since our business model is predicated on selling the processing power of computers that have CPUs manufactured by defendant installed, they are liable for this loss in productivity.
> Intel: Your honor, plaintiff could not possibly prove any loss in productivity. If you'll examine Exhibit A, the Intel microcode EULA, you will see that it expressly prohibits benchmarking. Whether plaintiff is claiming they did these benchmarks themselves or a third party did them is immaterial because our license expressly forbids doing so. Plaintiffs need to show a loss of productivity without relying on performance benchmarks and therefore need to show that the workloads prior to and after the microcode has been installed are equivalent and that the results are detrimental.
Now, I don't expect most judges would go for it since EULAs are notoriously weak, but it does give them ammunition to impugn the evidence. It's always possible a judge or jury would listen to that.
Looking at the license, the only thing it grants the end-user and which Intel could revoke is the license to use the software:
> Subject to the terms and conditions of this Agreement, Intel hereby grants to you a non-exclusive, non- transferable right to use the Software (for the purpose of this Agreement, to use the Software includes to download, install, and access the Software) listed in the Grant Letter solely for your own internal business operations. You are not granted rights to Updates and Upgrades unless you have purchased Support (or a service subscription granting rights to Updates and Upgrades).
So yeah, they could revoke your license to the update and leave you with a lot of insecure silicon...but that's what you had before the update (and, in all likelihood, what you still have after the update, just with a known flaw patched and the system lots slower). I don't even think they could sue you for copyright infringement, because you're not violating copyright, you're violating the EULA.
Weighed against the normal risks of someone actually reading the EULA, it seems like a minor thing that may help in some way.
UPDATE: Intel has resolved their microcode licensing issue which I complained about in this blog post. The new license text is here (https://01.org/mcu-path-license-2018).
Doesn't this show that it is time for someone to set up some kind of "ScienceLeaks" website, where scientists can upload research (results, papers, ...) anonymously which they are are not allowed to do legally because of various such "research-restricting" laws.
---
UPDATE: Before people ask the potential question how the researchers are supposed to get their proper credit - my consideration is the following: Each of the researchers signs the paper with their own "public" key of a public-private key pair. This signature is uploaded as part of the paper upload. The "public" key is nevertheless kept secret by the researchers.
When the legal risk is over and the researchers want to disclose their contribution, they simply make their "public" key really public. This way, anyboy can change that the signature that was uploaded from beginning on, indeed belong to this public key and thus to the respective researcher.
That being said, as soon as someone with a clue comes along + tries them out and finds it's bogus... that would lead into potentially weird territory too. eg the dodgy submitters likely attempting to discredit the er... whistleblower(?).
Seems like a re-run of an old story. :/
These kinds of clauses are likely effectively null, void or unenforcable in any country that has decent consumer protection laws or laws concerning anti-competetive practices.
You also can't just go and write whatever into a document that already has weak legal footing in many places - and especially not after I purchased your defective product. This shit won't hold for a minute in court.
I can imagine some scenarios:
- A company is bought by another one which has a different legal policy and voids some legal restrictions even retroactively
- By some other way, the "illegal" knowledge in the paper became "public knowledge", so that company lawyers will have a hard(er) time convincing a judge that the respective paper is of any danger and thus the author to be prosecuted. For example: After these microcode patches, people will of course privately do benchmark the performance differences. So some years later, the order of performance differences are kind of public knowledge.
- With time, companies have a much less legal interest to sue people for disclosre. As long as there is a high commercial interest, companies can be very "sue-happy". On the other hand, each of these lawsuits is a PR risk for the company. If the respective product becomes outdated, the ecomonical advantage of a lawsuite is much less than the probable PR loss.
- The researcher now (later on) lives in a different country that has a different legal system where there is much less legal risk. For example, in Germany, it is very restricted what can be included in the general business terms (in opposite to the USA).
In all of these cases, it can become much less legally dangerous to disclose the real identity of the author. On the other hand, there exists an incentive (academic credit) to do so.
I don't go there since 2008 but why not just wikileaks?
They are only interested in Anti-America leaks, not all leaks.
> They are only interested in Anti-America leaks, not all leaks.
Everybody should make their own judgement on the political bias of Wikileaks (which is, in my personal opinion, a very good reason why monopolies are typically bad; in other words: there is a demand on multiple independent Wikileaks-like websites), but the statement that Wikileaks is only interested in Anti-America leaks does not hold in my opinion. See for example the following leak about Russia's mass surveillance apparatus:
> https://techcrunch.com/2017/09/19/wikileaks-releases-documen...
Or let us quote
> https://www.reddit.com/r/WikiLeaks/comments/5mv07m/has_wikil...
"They released Syrian/Russian email exchanges, I don't know if it led to anything extremely controversial. In an interview, Assange said the main reason they don't receive leaks from Russian whistle-blowers is that the whistle-blowers prefer to hand over documents to Russian-speaking leaking organization.
And Wikileaks doesn't have Russian-speakers in their organization. You can tell your friend that if he or she wants Wikileaks to release damaging Russian documents, then he or she should hack the Russian government and give what they find to WL."
Or have a look at
> https://www.reddit.com/r/WikiLeaks/comments/5mv07m/has_wikil...
On
> https://www.reddit.com/r/IAmA/comments/5c8u9l/we_are_the_wik...
you can find a list of various counter-arguments to common criticisms of WikiLeaks.
It's a really sad thing you're being downvoted, as I made a similar comment about a year ago [1] in defense of WikiLeaks to over 30 upvotes. HN seems to be getting more and more active with their downvotes towards information that doesn't fit their current perspective.
> [1] = https://news.ycombinator.com/item?id=13816762
I don't see myself as a defender of WikiLeaks. It is, for example, hard not to admit that the Democratic National Committee email leak and the exchange between Donald Trump Jr. and WikiLeaks (at least to me) has some kind of "smell" [2].
My argument rather is:
a) the position of WikiLeaks (if there exists one) is far more confusing and sometimes self-contradictory than it looks on the surface (in this sense, I am both somewhat sceptical of the "WikiLeaks defenders" and the "WikiLekas prosecutors").
b) do not trust any side as "authoritative". Consider multiple different sources - in particular the ones that do not agree with your personal opinion - and conceive an opinion on the whole story.
[2] https://www.theatlantic.com/politics/archive/2017/11/the-sec...
I just threw you into that category for the purpose of my comment as I believed it was a perceived defense of Wikileaks that you were being downvoted for, rather than something else regarding the content of your comment.
>They are only interested in Anti-America leaks, not all leaks.
Any evidence to prove this? If you go to Wikileaks there are leaks from all around the world. I personally am very glad Wikileaks exists, doing the work they do, and still has never been proven incorrect or fraudulent.
By the way, Anti-American leaks are also Pro-American leaks, even if they may not be favorable to your own political beliefs.
If you go on Wikileaks right now and search "Russia" for 2012-2018, you get mostly news about how western plans are going to fail and how powerful Russia's military is. If you search for Russia in the "Syria Files" section, you get no results. How is that even possible?
> Doesn't this show that it is time for someone to set up some kind of "ScienceLeaks" website
Good idea, but I doubt it's necessary here. I'm fairly sure this sort of EULA clause is unenforceable in many jurisdictions. Run the benchmarks in a country where they are legal.I don't think this is necessary ...
I think "circumventing" this benchmarking restriction is as simple as having one person purchase an Intel CPU and just drop it on the ground somewhere ... and have another person pick it up off of the street (no purchase, no EULA, no agreement entered into) and decide to benchmark the found item against other items.
"I found a chip on the ground that had these markings and numbers on it and here is how it performed against an AMD model."
The media that has been performing such benchmarks for decades and have thus earned a large and faithful audience can organize and simultaneously publish the relevant benchmarks in the US, complete with an unapologetic disclosure right at the top as to the why this is happening. Put Intel into the position of suing every significant member of the US tech media and create a 1st amendment case, or perhaps try to single out some member and create a living martyr to which we can offer our generous gofundme legal defense contributions over the decade it takes to progress through the courts. Either way Intel creates a PR disaster for itself.
Sack up and call their bluff. There are MILLIONS of people that will stand behind that courage. At some point the share holders will feel it and this nasty crap will end.
It's contract law and tort law that's relevant. Intel's defective product, Intel's ToS, and maybe fair use. (As the tester could get the patch without an explicit license and try to claim fair use.)
> When the legal risk is over and the researchers want to disclose their contribution, they simply make their "public" key really public. This way, anyboy can change that the signature that was uploaded from beginning on, indeed belong to this public key and thus to the respective researcher.
Commonly-used public key signature systems (RSA, ECDSA) do not provide the security properties necessary for this. Someone else who wants to claim credit for the research could cook up their own key pair that successfully validates the message and signature. This is called a duplicate signature key selection attack (https://www.agwa.name/blog/post/duplicate_signature_key_sele...)
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906158#14
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...
As well as not redistributing it to mirrors, as they are unable to ask mirrors to accept a new license. [0]
E.g. "intel-microcode-legacy" and "intel-microcode" would be more diplomatic (disgustingly so IMO).
And one could argue that every package in non-free would deserve a "-legally-restricted" suffix.
The DFSG is a set of guidelines that define what can be considered true FLOSS.
The reason is to protect users from legal risks.
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 because intel are douches.
I didn’t like how they handled their vulnerabilities, or how they still released chips with the errors long after it was discovered because they had production planned, and now they are pulling stuff like this?
Heh.
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 Intel-killer was the Zilog Z80 notably used in various CP/M and MSX computers). Commodore eventually acquired the company, rebranding it Commodore Semiconductor Group. A CMOS version of the 6502 is still sold by the Western Design Center [1].
http://wdc65xx.com/boards/w65c02sxb-engineering-development-...
Pro: it looks like an AT motherboard from 1985
Con: it's $189 :s
I understand what you mean though. Architecture itself isn't _that_ critical; peripherals and batteries-included capabilities are.
In this case, when I read "for developing educational and industrial strength microcontrollers." in the product description I immediately concluded that the "educational" is quite possibly part of a product pitch to companies making 6502-based control equipment, along of course with educational institutions still using the 6502 as a teaching aid.
As for devkits I do want, the Forth GA144 is definitely up there near the top, and the KISS-68030 (https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:ki...) is floating around in there as a very unsure "maybe".
The UK's Sinclair ZX Spectrum and Amstrad CPC were famously Z80-based, as well as the MSX spec (as you've mentioned) which was huge in Japan. It was also used in a lot of arcade machines either as a main CPU or as a sound chip.
Not really ideal for word processing and somewhat limited with 1KB (yes as in one kilobyte) of RAM.
You could get a rather expensive 16KB memory extension. Alas ,this had the problem of disconecting every 30 minutes or so, due to thermal issues. So you had to be really sure to save your work to datasette (don't ask!) in very regular intervals.
Fun times!
Both have generally been good to me (the P4 was a bit crap), but I'm very likely to choose AMD again next time I do a full upgrade. Now that their GPUs are also working great in Linux on open source drivers, they're a much better choice than Nvidia for me, I just replaced my GTX 460 with an RX 560.
It's a shame Intel has the high-end laptop market locked up so tight. Good luck getting a modern Thinkpad with an AMD processor.
For Linux Mint 19 (based on Ubuntu 18.04 LTS), I had to add a PPA with the newest MESA drivers, other than that no issues at all.
Me too. I was running Intel+Nvidia rigs for about ten years, up until last year, when I got a Ryzen 1800X and (this year) a Radeon 7970. Nvidia hasn't been the most ethically behaved as of late (whether it's more or less than Intel, I haven't figured out). Intel will be releasing a discrete GPU in a year or two; who knows how fast it will be, or if they will allow people to benchmark it.
I always used to root for Intel because AMD made their entire business model off copying (later licensing) Intel's x86 designs (including the model numbers), but that's becoming a lot less relevant now.
I upgraded my desktop's Geforce 550Ti with a Radeon HD 7850, and though it's gotten off to a slightly rocky start (Windows logins are noticeably slower, seems to be a known issue), performance is great, benchmarks showing it on par with the 970m in my laptop. When the Haswell i7 needs to be upgraded, I may start looking at a Ryzen. Never thought I'd see the day.
Intel contracted AMD to second source their processors as a requirement for being in the IBM PC (requirement dictated by IBM).
AMD existed long before their version of the x86, producing the venerable http://www.cpu-world.com/CPUs/2901/ which was widely used in minicomputers of the time.
The amazing thing about the 2901 and family, was that the engineer could design a board level CPU and full freedom over register sizes, numbers, alus, etc.
Don't forget that the 64 bit x86 ISA was created by AMD and licensed to Intel.
I knew about 64-bit (Athlon 64, anyone?), but I've always heard x86-64 described as a kludge and an awful hack, not a well-designed architecture. The greater RAM accessibility and native execution of 32-bit code are advantages, but shortly thereafter Intel went multi-core, which seems to have done drastically more for system performance than x64 did.
I also find it fascinating in that in theory your BIOS update can include these changes.. does this anti benchmark license apply if you reflash a new BIOS or just buy a new motherboard with the new bios and then use the same type of CPU to compare?
Makes me want to look at some BIOS and motherboard EULAs now...
Might want to get your next chips from AMD.
Nothing stops Intel from not sending them anything anymore, and then they have to buy it from the stores like everybody else.
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.
This really makes me doubt if I should buy Intel products in the future (to the extent that I have a choice). If I can't get performance information because Intel has something to hide, I'll have to look elsewhere. Really, this is sufficiently distasteful behavior to make me avoid Intel even if the products work just fine.
I have seen this happen in so many cases all over the world. Supreme Court orders can be ignored by the government agencies and even private parties as long as no one drags them to court. Spending a 100 million dollars is nothing for the government or influential private parties as big as Intel. The small guy, however, will be bankrupted.
Be it the government or the big corporate, it is effectively the public money being used against the public. How absurd.
This shows that money is necessary for justice. This is dangerous.
Why can we not have systems that detect such frauds and automatically discipline such entities? It is not like such violations are happening behind closed doors of a small house in an inaccessible jungle. These violations are public.
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 the microcode and publishing numbers directly.
That might as well read as "you can't provide cloud computing" since you can't know what someone is going to execute on their server before they execute it!
Etc etc. This is a legal mess and a strong attack on freedom.
Comparing arbitrary code execution times on this platform versus another could easily be called 'benchmarking'.
It's just so strange to sell a general purpose processor but then prohibit certain types of code depending on the state of mind of the developer. The same block of code could be permitted or prohibited based on the intent. It's nuts and a legal morass that is hard to imagine any lawyer proposing as a good idea.
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.
Once I have the application (or in this case, the microcode) it would seem the data I produce with it is mine to do as I please with? Otherwise it would be like microsoft saying that I couldn't publish any .docx files online that I produced with their software?
https://access.redhat.com/security/vulnerabilities/L1TF-perf
An estimation of man hours spent on this issue outside Intel
https://www.servethehome.com/intel-publishes-l1tf-and-foresh...
Thought frequently mentioned, Phoronix did not run a benchmark comparing before and after application of the microcode update. Excerpt: To note, no microcode changes/updates were made to the systems under test for this article, just testing/comparing the kernel patches (https://www.phoronix.com/scan.php?page=article&item=l1tf-for...)
Is this net-positive for VMware since customers will be required to buy more licenses for the same workload?
Or is it net-negative because it makes public clouds more competitive?
Now that it is news they're pretty much begging for someone to do the benchmarks.
This reminds me of the oracle license that was so broad it prevented users from talking to other users about their experience with the product... any experience.
Any slowdown would have been pretty public, the microcode update is still a big deal and the expectation weren't clear, I'm pretty sure the results were worst than the average expectation. Now though, the expectation are much higher, people expect it to be pretty high and maybe the results are now actually lower than theses expectations.
So yeah maybe more publicity but maybe now people will say "not as bad as I thought", instead of saying "much worse than I thought".
lol, javascript
lol, javascript
So? Many does not mean most. There's a choice to be made, apply the security patch and accept the performance loss, or don't. Some people may not need to to remain close to as safe as they were previously based on their configuration for some of their systems, and I would guess the number of systems easily numbers in the millions. This is a benefit for those people, and worth mentioning, even if it's not nearly a large a number as the total number of CPUs or customers.
At least, that's all I can think you are trying to imply, because you didn't actually say anything, you just dropped a link. It's hard to have a useful conversation when that happens.
https://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pd...
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.
• Certain days come up that I, the paying user, do not want to patch on. Microsoft wins this disagreement and I lose. This occurs in a glib fashion with a message like "Hey, just a heads up, we are going to restart your computer" (whether I like it or not). It is my computer, there is no "we!"
It will absolutely close programs with unsaved work if I am not there.
• Maybe I don't want the performance hit on my gaming PC. This is another element of surprise: who knows how bad it'll be? Certainly not the users if Intel and Microsoft have their way.
• Yet another element of surprise: I've had hardware stop working after updates.
I cannot wait until it becomes viable to escape the toxicity of companies such as Intel and Microsoft.
This has been "viable" for a long time now. Ignore the FUD and just try it for yourself. You might be pleasantly surprised.
https://docs.google.com/spreadsheets/d/1DcZZQ4HL_Ol969UbXJmF...
i'm pumped to try monster hunter. that game was the only reason I was going to use windows, so hope it runs well
Buy an AMD machine, install Ubuntu, and you're done.
>Ubuntu
Hope he likes Mahjong and Tux Racer
Win10 is free* (so it does this) - Professionals who need to override these settings should get Win10 Pro.
They seem to be getting less aggressive, but I've had my machine reboot with less than half an hour of notice. No notice before leaving the machine, return 30 minute later to find it rebooted. So "just mark every 2nd Tuesday of a month as patch day and never leave your machine(s) unattended on that day and you won't have surprises!".
I've also had (in a recent month) them reboot overnight, aborting long running processes that I had to clean up and restart, after explicitly checking for updates before starting those processes (none being found), and making sure my "active hours" were set such that it shouldn't restart.
Earlier this year I had a patch mid-cycle (not close to the normal patch Tuesday) that caused a reboot too. IIRC it was a flash-for-edge/ie update. An update for a feature I don't use/want and can't remove caused a "random" reboot at an unpredictable time. Ta muchly...
I understand MS wanting to get away from their desktop OS's insecure reputation which is in part caused by people never installing updates meaning that worms and other malware were able to run rampant relatively unchecked, but they seem rather wrong headed about how pushy to be in fixing that.
When I review the update settings, they're as negative as I can make them.
I shouldn't complain too much, sometimes it kindly starts Visual Studio for me, saving me 20 seconds.
It could have asked, or even warned that I'd be wasting my time setting up the nightly job, only for it to be cancelled midway through for little reason.
Basically, it's just a consumer OS, and shouldn't be used for actual work.
Anyway we had a PC running an optimization on the arc length, probe distance etc to get the best instantaneous coupling, trying to save electricity by putting the energy into the steel (to melt it) instead of burning up the probe, creating heat etc.
One morning the plant called, had run overnight but sometime in the late night the thing stopped adjusting, ran 20 minutes before they noticed without moving the probe or adjusting the current. Just sat there burning up carbon and making heat.
You can see where this was going. Investigated, and the PC had gone into 'power save' mode, suspended the app, gone dark. Leaving the probe at whatever setting it was at.
I estimated at the time, that the power wasted during those 20 minutes was more than all the electricity ever saved worldwide by Windows 'power save' feature. Yes, it would have been better had Microsoft Never Invented Power Save, than to have had that incident.
You can say it was our fault, guy installing didn't remember to disable power save. But still, people do things like that. I prefer to blame the computer.
Although in this case, it's possible to disable power saving.
(or have they stopped that, too?)
Complexity is evil.
The benefits of adding complexity rarely outweigh the downsides, especially when the "embodied energy" of both creating and maintaining that complexity and the follow-on complexity it adds to other systems is considered. Making things a lot more complex to save energy is usually a wash (or worse) because of the energy you spend creating and maintaining complexity.
Complexity usually creeps into systems as a result of piecemeal solutions to problems, marketing driven feature-itis, or attempts by engineers to be overly clever and show off. The latter is incredibly common in IT and programming.
http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer....
Complexity is evil for efficiency, but it's even more evil for security. The number of states a system can enter is an exponential function of the number of variables and linkages in a system. More complex systems are just exponentially more likely to have vulnerabilities for unavoidable combinatorial reasons. The motive for complexity addition doesn't matter, meaning that complexity increases to mitigate security can easily backfire. Furthermore as systems become more complex they become too big to be analyzed, making it much more likely that major security issues are hiding in plain sight and waiting to be discovered. Black hats always have the advantage here because when you attack a system you get instant feedback about whether your attack worked, while security auditing offers no feedback as to whether or not you've closed all the holes.
Complexity tends to accumulate until systems collapse. Getting rid of it is very hard, since users/customers start depending on every feature and nothing can be removed without breaking something.
The x64 architecture seems to be teetering on the brink. AMD's architecture seems better but we'll see.
Maybe best to disconnect from the internet when not using- putting to sleep doesn't do it.
Hopefully he will edit this blog post with better advice to the "casual" computer user.
[Sure it's not going to fly given Intel's market position, but it's a tempting thought anyway...]
I checked at intel directly just to make sure this is true: https://downloadcenter.intel.com/download/28039/Linux-Proces... The file https://downloadmirror.intel.com/28039/eng/microcode-2018080... contains the license file with that laughable clause included.
Now hand me the popcorn...
I'd really love to see a big shift to a new architecture, RISC V, OpenPOWER etc. get me really excited because as a nerd new technology in general is always interesting, but the above simply is my prediction of the future based on history. I mean, how long ago have the first serious Intel ME vulnerabilities been disclosed? What happened apart from a short shitstorm on tech websites and some small companies offering laptops with crippled down IME that only complete neck beards care about?
Which, of course, makes the kind of systematic deception Intel is trying to pull off here much easier. It's a feature!
i.e. you cannot allow anyone else to use your CPU?
I get that the intent is probably about distribution, but the software runs on the CPU so is being used by whoever is using the CPU.
You shouldn't have to jump through absurd legal hurdles to use and talk about something you legally purchased. These aren't national security secrets for god's sake.
Does Intel's legal team even have a basic understanding of how computers work ? In essence, the word 'benchmark' ceases to exist after this microcode update. No more research in any domain. Back to hunting and gathering.
Maybe I'm missing something here, but I was under the impression that the Spectre/Meltdown mitigations have a big performance penalty, but the more recent L1TF mitigations should have little or no impact, and that the new license only showed up recently on the new L1TF mitigation patches.
Is the L1TF mitigation actually a lot worse than I thought, or does this license apply to the earlier Spectre/Meltdown patches, or is Bruce Perens just being sloppy and conflating the two?
Either way, I agree with him that draconian license terms shouldn't be attached to bug fixes.
He isn't being sloppy. According to the Debian package maintainer[1], the new license only applies to the new patches (ones after 2018-08-07) which were released long after the Spectre/Meltdown ones -- because the license was only changed in the 20180807 microcode update (and because Debian didn't block the previous Spectre/Meltdown releases over license concerns).
In theory, nobody can actually tell you how bad the L1TF mitigation is because of the new license terms (a comparison before-and-after L1TF mitigation would be providing you with comparison test results).
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906158#14
The performance loss isn't that bad in most cases.
I assume the microcode update could be either equal o slightly worse in terms of performance, as the CPU might need to flush more frequently.
Which is pretty sad, as the status of kernel+microcode updates is quite confusing already. Some mitigations can take advantage of new microcode updates, if the kernel is recent enough. How does the pure soft-workaround compare in terms of performance to the microcode-assisted one?
Note that, combining all workarounds for meltdown+spectre-v1/v2+l1tf can have a significant performance hit for some workloads which are not purely cpu-bound. On top of that HT is now looking like a bad idea to start with.
I'm pretty sure that for a server where there's a lot of I/O and virtualization going on, enabling all the patches and workarounds + disabling HT can take a massive cut in overall throughput.
Their security advisory says that
> Optimized L1 data cache flushing is available via intel-microcode updates. The updated kernels implement a software fallback cache flushing mechanism for processors that have not received microcode updates.
It looks like the kernel will say "VMX: conditional cache flushes" on the new microcode so according to the Phoronix screenshots, they were running the older version.
Maybe we'll see a new set of benchmarks.
Also there was significant reduced performance when hyperthreading was disabled as required to fully mitigate the threat of the vulnerabilities. If the microcode update changes the behavoir of hyperthreading in order to fully mitigate the vulnerabilities without having to completely disable it then there is a chance these changes effect the performance benefit of hyperthreading.
Given Intel's anti-benchmark license clause without evidence otherwise I assume it is not just a chance but a strong likelihood that the performance benefits are significantly impacted.
The best way to combat this sort of thing is for journalists, and anyone else discussing the issues of this vulnerability, to make a point of bringing it up, repeatedly. Whenever performance is an issue, point out that Intel is restricting the impact from being evaluated, which suggests that it is bad. Whenever security is an issue, point out that Intel is restricting the dissemination of the mitigation by imposing self-serving conditions on its use.
At least from my layman's perspective this certainly smells like an absolutely 100% textbook contract of adhesion. It's a "take it or leave it" offer, there is no room for bargaining, the term is far outside of reasonable expectations for the situation, it's simply an entirely one-sided item for the pure benefit of Intel leveraged coercively. In fact I think it may go far enough to hit the doctrine of unconscionability even. All this without even touching on any public interest issues.
I think they should be challenged on this, that benchmarks should be published and Intel told to pound sand. Companies can stick whatever they want in a contract but that doesn't make it enforceable. And while admittedly often that can be quite gray territory and people toss out "not enforceable!!!" on the Internet far, far more often then is justified this particular instance really does look egregious. Yes, normally you can contract away your speech rights, but it's in the process of a real contract, with reasonably equal bargaining positions, proper consideration, etc. I think this goes too far.
Perhaps Intel's real aim though is actually slimier, lots of major review sites depend pretty heavily on access that Intel (and other vendors) offer as well as free/cheap kit and the like which is optional and much easier to yank away at a whim. For those publications this may be a shot across the bow, of the sort "sure, you can challenge this if you want but it's a warning that if you do we can still punish you for it regardless of you winning the case."
This seems to exclude any benchmark that may be affected by the Software's performance... Which means any CPU benchmark.
There is some play in the wording... And I'm taking the least favourable interpretation. But yeah... Seems like Intel have said no benchmarking, full stop.
> Seems like Intel have said no benchmarking, full stop.
That doesn't mean it's enforceable. Companies say silly things all the time.If they tried to uphold that least-favourable interpretation, then I would be reaching for anti-competitive laws, and other consumer protections, and perhaps even contract law as they say downloading the software, so you can see the license, is binding.
It seems difficult to have a legal argument that it should be binding at all.
Will they sue me ?
Are you in US? If the answer is yes, I'm happy to publish the results for you on my blog where they won't reach me.
Might even come from a media organization if their lawyers deem this sufficiently unlikely to be enforcable in their country.
Doesn't even need to have a content.
The license for that software was that Intel owned all rights to everything produced with it - your art was not your own.
My Google-fu is weak today. Does anybody remember the name/have a reference?
I'm on the AMD train now, never buying Intel again.
You are free to change, modify, reverse-engineer every product you can view or get access to.
The potential security issues with out of order processing were noted publicly at least as far back as 2007. The problem is that, on the whole, the entire industry doesn't really give a shit about security until it's too late, which is exactly the wrong time to start.
I don't foresee this changing anytime soon. It will be interesting to see the downside of AI. Or maybe terrifying is a better word for it, since it could foreseeably include personal physical security. But before that time comes, people who think like me are still just pointy-headed paranoid security losers, I reckon.
Many types of neural networks are Turing-complete and are written in C by academics with no security experience. Fun times ahead.
Just benchmark and publish results anonymously. Intel can't take them down since the results are not illegal, only the "act" is prohibited by the EULA, which is not enforceable anyways.
Intel should be seriously punished for trying to play like this.
[1] https://en.wikipedia.org/wiki/Unfair_Terms_in_Consumer_Contr...
the answer is they probably both should have.
speculatively executing code that is time-sensitive to privileged data should have been caught. timing attacks on this level have been known for at least a decade. for that reason I don't quite believe that nobody at Intel (or AMD) was aware of the possibility of these attacks before anyone in the security industry published about it. they should have been more responsible instead of just waiting until it broke.
everything about this saga adds up to economics, business and production reasons why 1) not enough people were paid to look for these kind of problems, 2) the microcode developers that might have become aware of potential issues didn't have a good avenue to raise them, 3) there seems to have been NO proper roadmap whatsoever at both of these (rather large) companies for responsibly addressing, fixing and patching mistakes of this level. the whole response seems to be completely ad hoc, like it was some kind of one-in-a-million act-of-god thing that nobody could have foreseen.
it's not a super obscure bug. it's a side channel cache timing attack, the likes of which have been well-known for over a decade.
if Intel and AMD both thought, during the past decade, "well we know about side channel cache timing attacks now, and this is probably the worst they'll ever get", they don't know quite an important rule about security: exploits only get worse, never better. that inaction definitely doesn't fall under "could not have foreseen".
https://twitter.com/imadsousou/status/1032680311753072640
Disclaimer: I work at Intel
What you are supposed to just ignore how much gas you put in the tank? No different when your servers slow down and runs up your electric bills.
In general, these terms doesn't seem to be very carefully phrased. Point (i), and independently point (iii), apparently prevent you from running the software altogether.
We have simplified the Intel license to make it easier to distribute CPU microcode updates and posted the new version here: http://bit.ly/2w9RjtM . As an active member of the open source community, we continue to welcome all feedback and thank the community
I would be certainly interested in the level of degraded performance.
https://www.intel.com/content/www/us/en/architecture-and-tec...
It doesn't even seem like a particularly well written clause as it could be interpreted to mean benchmarking the microcode update process not the hardware.
I read this as everyone that distributes this has to change THEIR ToS to explicitly disallow THEIR users to provide benchmarks. Surprised any distro distributes this at all.
Regardless, what would be a compelling reason for which I should buy from Intel again? What kind of credibility do they build for themselves?
We live in a time where thepiratebay still thrives, Snowden did his think and wikileaks is a thing, and Intel thinks they'll stop someone publishing benchmarks.... of a cpu.... ?
Is not a compare only performance graph between two users computer remember USER1 is patched
Given four benchmarks (7,null,8,6) where do you place the null?
If this isn't a smoking gun about performance loss due to vulns, I don't know what is. Intel is in hot water.
Question: Are these license restrictions on right to disclose benchmarks enforceable?
Question: If they are enforceable, do licensors ever try to enforce them? If not, why?
A little background here: https://danluu.com/anon-benchmark/
For example, this has been posted to HN at least twice recently:
https://clemenswinter.com/2018/07/09/how-to-analyze-billions...
Question: Was the author subject to any restrictions on publication? If yes, did the author seek "permission" from the licensor to publish these findings?
Excerpts from some of the licenses:
2.2. 32 Bit Kdb+ Software Use Restrictions
(c) 32 Bit Kdb+ Software Evaluations. User shall not distribute or otherwise make available to any third party any report regarding the performance of the 32 Bit Kdb+ Software, 32 Bit Kdb+ Software benchmarks or any information from such a report unless User receives the express prior written consent of Kx to disseminate such report or information.
kdb+ on demand - Personal Edition [64-bit]
1.3 Kdb+ On Demand Software Performance. End User shall not distribute or otherwise make available to any third party any report regarding the performance of the Kdb+ On Demand Software, Kdb+ On Demand Software benchmarks or any information from such a report unless End User receives the express, prior written consent of Kx to disseminate such report or information.
This Kdb+ Software Academic Use License Agreement ("Agreement") is made between Kx Systems, Inc. ("Kx") and you, the University, or employee of the University ("End User") with respect to Kx's 64 bit Kdb+ Software and any related documentation that is made available to you in (jointly, the "Kdb+ Software"). You agree to use the Kdb+ Software under the terms and conditions set forth below. This Agreement is effective upon you clicking the "I agree" button below.
1. LISCENSE GRANTS [sic]
1.4 Kdb+ Software Evaluations. End User shall not distribute or otherwise make available to any third party any report regarding the performance of the Kdb+ Software, Kdb+ Software benchmarks or any information from such a report unless End User receives the express, prior written consent of Kx to disseminate such report or information.
Kdb+ software end-user agreement:
By accessing the Kdb+ Software via the Google platform, you are agreeing to be bound by these terms and conditions (which may be updated from time to time) and to the extent you are acting on behalf of a permitted organization that you have authority to act on their behalf and bind them to these terms and conditions.
You may not access the Kdb+ Software if you are a direct competitor of Kx.
4. Benchmark Test Results. User agrees not to disclose benchmark, test or performance information regarding the Kdb+ Software to any third party except as explicitly authorized by Kx in writing.
Microsoft has provided no real alternatives for those of us who need to be able to keep a Windows machine running overnight.
Whats to be upset? Don't update if you are upset. Choose between perf/security. What are the options, anyway? You can be upset that the things are the way they are, however you can't blame Intel/AMD/ARM, etc. You should have been upset if these vulerabilities were known and not fixed thou.
Not allowing benchmarks - yeah, agree to that, that is a reason to be dissapointed or upset.
But people throw words around: lawsuits, upset, etc.
It's also (somewhat) fair to assume that this patch would also affect performance until proven otherwise, and Intel changing their license to disallow sharing comparative performance tests doesn't give me much faith that I'm wrong in that assumption.