Spectre/Meltdown Pits Transparency Against Liability
bunniestudios.com
bunniestudios.com
The question is not whether Intel would accept a settlement of documentation instead of money, or whether Spectre/Meltdown are bugs or not.
The question is whether /you/ would offer an exchange of documentation for release of liability. Whether or not the maker accepts the offer is orthogonal to whether you are willing to take the first step in breaking the vicious cycles that keeps hardware closed.
If you're not willing to give any allowance for the fact that sharing documentation exposes makers to more liability, then stop demanding transparency. Nobody should be obligated to put themselves in harm's way solely for your benefit or as intellectual entertainment. Likewise, learn to live with proprietary drivers, undocumented bugs, backdoors, and potential exploits hidden in your hardware, because without a transparency compromise, none of these problems will have a sustainable solution.
As an individual I would be more than happy to make the exchange. The pitchfork-carrying crowd that rants online? - most would be happy to make the exchange as well i believe.
The important question in my opinion is, are their business partners willing to absolve them of any liability in exchange for transparency? I don't think it makes sense for them - I don't think it makes sense in any business.
Except both Spectre and Meltdown, AFAIK (IANAHWE) are design flaws as the silicon is working as intended. The hardware is fine -- the real problem is that the Intel's reputation is partially built on speed, and, now that the cladding has fallen off, we've discovered the platform was built with really flimsy supports.
I read that as the other way around. He says:
> We should all be more surprised that it took so long for a major hardware bug to be found, than the fact that one was ever found.
Which I would read as, "it's surprising we don't discover bugs in hardware more often".
I would also say, that in the world of embedded devices, HW bugs in silicon are the norm, and your chips come with some form of errata.
For instance brushing off rings 1 and 2 from the dust bin of history could give user and kernel code ways to describe multiple levels of memory protection in a way that the chip can understand. That way, the same way that AMD was protected from Meltdown ("I can tell from the TLB that address is outside of what this code is supposed to touch, so I'm not going to speculate past that") could be expanded to a more general form.
Which brings me to another something I don't understand about this. If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad?
It's all either ring 3 (user) or ring 0 (kernel) for the purposes of this discussion. The biggest architectural impediment is the single bit for ring selection in page table entries. And since long mode requires paging, there's currently not a way to select rings 1 and 2.
Although you might be able to play with some of the hypervisor extensions to give you guest ring 0 context inside a regular user process... See Akaros for a good example of what that looks like.
> Which brings me to another something I don't understand about this. If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad?
Because the cache is a fixed size, and that just kicks the can down the road. You'll just test for the eviction in your exploit instead.
"Clearing the cached data" is just as detectable as caching the data in the first place. You'd have to treat the line fill as a transaction that could be rolled back. Unfortunately, transactional memory and CPU caches lie at polar-opposite ends of the performance spectrum.
IMHO the only safe way to do a fetch from prohibited memory is to not do it at all.
You can also observe changes to the TLB state, though - so you'd have to do the same buffering-and-commit dance there as well.
Maybe you can also leak data through the BTB or RTB (double-Spectre!), or by tieing up particular execution units conditionally which is observable by a sibling hyperthread?
But (given the idea that we're talking about future chips) it could help describe protection boundaries in a finer grain way to protect against Spectre in the same way that AMD is protected against Meltdown.
The main issue with spectre (in a long term sense) is that the CPU really has no way of understanding that you're running lower privileged code in a higher context, whether that be BPF in the kernel, or JS in the browser. IMO, we're going to be fighting the same battle over and over again as the all of the mitigations so far are heavily microarchitecure specific.
But in the context of trends, we're moving towards User^Kernel memory mapping with features SMAP. That idea combined with kernel changes to holistically enforce separation boundaries more effectively along with cache partitioning AFAICT leads to potential end game win on this front.
Edit: And to be totally up front my major side project is adding a BPF/seccomp esque virtual machine into a formally verified kernel, so my head is in that space.
But define "flimsy supports"
Modern CPUs rely upon "speculative execution" for speed, i.e. running code that they guess will be run. This usually works, but relies upon the CPU getting rid of the results of its incorrect guesses. Intel CPUs failed to do this in a very obvious way, which was recently exploited. As a result, they broke software security checks.
EDIT: Let's say your code is
if (security_check()) {
secure_stuff();
} else {
error();
}
Shame on you.
Hmm.
I worked at intel in the 90s... Ran the game lab - when they came out with the Celeron, they created SIMD instructions - and they paid (bribed) game companies to optimize their games against the instruction set - fofr $1MM in marketing bonuses.... (i.e. "play gameX on intels celeron based PCs and achieve X% performance gain")
And all of this was to prove that they could produce a <$1,000 machine that a consumer would want (the basis of the celeron proc)
Except the Spectre vulnerability isn't specific to Intel's chips.
The general comments were that Meltdown is a huge and easy to exploit vulnerability. Under Linux, any process can effectively read all of kernel RAM. There are straightforward software and hardware mitigations available. The next generation of CPUs should have that fixed.
Spectre is much harder to exploit and much tougher to fix. It's not an inevitable problem with speculative execution. IBM Z-series mainframes apparently don't have this problem. But it's going to be tough.
The real problem is all that hardware and software out there in the field vulnerable to Meltdown. There will be unpatched systems for years to come. That's what worries the RedHat guy. They have customers wanting patches to old kernels they no longer support.
The recording will eventually be up at https://www.youtube.com/playlist?list=PLoROMvodv4rMWw6rRoeSp..., but I can't recommend it. Unfortunately, Mr. Masters spent most of the ~75 minutes on introductory material (a fairly common mistake at EE380). The best discussion happened in the additional hour after the official end of the talk (and of the recording).
In fact, Pro Tip to people presenting at EE380 (and, for that matter, most "Company X wants to show us Y" meetings that I've attended): Take your slide deck, and delete the first 40% of it.
[1] https://developer.amd.com/wp-content/resources/Managing-Spec...
What uses cases involve running new untrusted code on legacy unsupported systems?
Well yes, you shouldn't be doing that (particularly the 'unsupported' bit). The thinking here, I suppose, is that Meltdown makes privilege escalation straightforward once a malicious party has access to the system via another vector.
In my company, we run self-hosted physical servers (i.e. we're the only user on the systems) and debated whether to disable the page table isolation fix since we were seeing about a 30% performance hit.
The decision we took was that we would accept the performance hit since Meltdown means that any unauthorized entry into the system has a privilege escalation path since kernel memory is essentially readable by any process. (Quite an easy and quick decision, really.)
On an unpatched system, that's not likely to be hard in the first place.
Its very possible, perhaps even likely, that Intel may profit more from the replacement of impacted chips, then it will lose settling various class action cases it faces. Its questionable if Intel's competition can or will grow manufacturing capacity such that Intel faces a real competitive threat.
It isn't that Intel is too big to be allowed to fail. Its that Intel is actually too big to fail; and that does not provide them the right incentives where product safety and quality is concerned in my opinion.
If by making CPUs more secure, self-driving moves 30 years into the future, how many lives will this affect?
There is an old joke, about Bill Gates saying that if the automotive industry could move as fast as the computer industry, we would had $100 cars that do 1000 miles to the gallon and the GM chief answering that whilst these cars would exist, they would crash twice a day.
If you are willing to delay the onset of self-driving cars by 30 years, that's a lot of blood. I agree there is a balance point that's not 1.25x30 million - some will still die after self-driving cars are introduced. There may even be some vulnerabilities exploited (but I strongly doubt that hacks will amount to anything approaching 1.25 million people per year - the media will hype up crashes where the self driving car or its security system was at fault as if it did, while ignoring the everyday fatal accidents with nothing except maybe an advisory to avoid that road on your morning commute). And as critical safety issues like maximum speed enforcement, drunk driving enforcement, helmets on motorcycles, seat belts, and child restraints trickle down into developing countries and older used cars, the number per year will - I hope - drop.
But one or two more have died somewhere since you started reading this comment. Still want to delay it?
People die from heart disease, cancer, respiratory failure, Alzheimer's, strokes etc. in old age. Reducing one of those factors would give few additional high-quality person-years of life. Auto accidents bring death to younger people who, in the absence of that catastrophe, would be expected to live many more years.
Sometimes though, you can work in parallel. A consumer-grade CPU may for example be used in a airtight setup when increased security is needed.
What kind of safety are we talking about? Nuclear power plants? Airplanes? Self-driving cars? If so, why would you be running untrusted, remote code on the CPUs of the critical components?
Sure, there occasionally are CPU bugs where the CPUs just randomly lock up, but we can defend against that with redundancy. The meltdown bug on the other hand requires malicious activity on the same chip, i.e. you need to offer an attacker a sandbox to run code on and then hope the sandbox holds and is properly resource-limited to not DoS your safety-critical system. It's a risk you shouldn't be taking in the first place.
And if we're just talking about credit card data well, we can easily compensate by moving to dedicated instances once such a problem becomes known, it's no worse than hypervisor escapes which become known every now and then.
I imagine that the higher liability CPU would likely be slow, old, and very very expensive. But that is the compromise required on behalf of the consumer.
And then they buy two or three per system for redundancy.
If we exclude all potential issues except those related to meltdown and spectre, Intel chips are perfectly safe, the results are correct and there is no crash. It means that if they were safe to use in critical systems like engine control units, they still are.
Meltdown and spectre are security bugs, they are usually treated differently from safety problems like with cars and drugs.
This is such an important question -- and why we cant rely on gov sections like the FCC (ajit pai) to resolve these issues -- These are questions that will be critical to the evolution to the digital humanity which we shall be forever-more.
So we need to evolve to a next level meta thought to humanities destiny.... we are too focused only now by petty thinking.
Need to solve this problem.
It would certainly make modern high-performance computing less likely.
In that case, the outcome was significantly better for consumers in the US compared to elsewhere.
Are there any legal processes against Intel from customers?
That leaves plenty of uses for pitchforks...
Even if we as developers put down our pitchforks, a class action firm will jump on any perceived liability.
The complexity of modern processors is very similar to that of software, and this should be taken into account, but if Intel is summarily absolved, it is more likely to join Microsoft and Apple in the 'closed, limited liability' corner, rather than keeping company with Linux and GNU.
With respect to Bunnie – Why? I understand that a complex piece of hardware can never be completely bug-free. But if a bug renders the product unfit for purpose, does the manufacturer not have a legal obligation to either fix the bug or provide monetary compensation? And I'm not sure I buy the argument that this obligation makes manufacturers more likely to try to hide bugs. If they sell products with defects that are known but not disclosed to the customer, are they not committing fraud?
A more sensible position seems like "lets get the bugs out fast rather than having one per architecture for the next 100 years" and making it open. But I can see that being unwise depending on how long they think it will take and how much of a hit to their reputation.
The author argues that transparency and liability are at odds, and cites Open Source Software as the main example to justify this.
But, there is a third aspect: Money. If you sell something to me, then I want both transparency and assurances of fitness for purpose. Even if it's not directly part of the contract, it's implied by consumer protection laws. (Maybe not everywhere, but .de seems to have pretty good consumer protection).
Open Source Software doesn't come without liability because of it's openness, but also because it's free as in beer.
But that's the point. The hardware is not open. If anything, tightening warranty for closed hardware and loosening it for open hardware would likely have the opposite effect - it would make Intel open their code (if we follow the logic of the article).
Now on graphics cards support for Machine Learning applications AMD falls short of Nvidia, but that's a different processor.
I'm hoping the "No data center usage" clause Nvidia recently sprung in its license will encourage more people to develop for, or expend more effort on porting ML libraries and tools to AMD GPUs.
Open source software is usually provided free of charge and at the cost of 'time' by the developer. It's also often produced by the developer as part of every-day problem solving for something else, in which that something else is often a paid gig (i.e. releasing a generalized library that was used to solve a problem for an application that has paying users or for a customer's bespoke development effort), so even in that scenario it can be seen as being produced at no charge. Once 'produced', the product can create unlimited numbers of itself at zero cost.
Open source hardware comes in a few pieces: (1) The specification, which can be completely open and released without promise of warranty against defects and which comes with that transparency, (2) the actual hardware product, which is paid for by the customer, often at a profit but not required to be and (3) the software behind the hardware (bootloaders and such) which should also be free. There are costs involved in hardware production and purchase that do not exist in the software world[0]
Of these things, most consumers would expect the second to come with a warranty of some kind against defects and it would be an intelligent thing for a company -- even one operating as a non-profit -- to mark up the product enough to offer a suitable and clear warranty. In the case of Intel, a very for-profit entity who keeps its specification, documentation, and flaws under lock and key for the protection of its business and, quite rightly so, aims to sell its product in a manner that maximises profits for its shareholders, all consumers expect a product that is going to be warranty protected.
Where this gets tricky is explaining Spectre/Meltdown to the average non-technical person[1]. It's reasonable that Intel couldn't have noticed this flaw even if they were believed to be employing every possible method to ensure the protection and safety of their customers[2]. The complexities around this issue are very high and the company can reasonably be forgiven for missing the problem. But most consumers won't understand this -- what they will understand is that shortly after receiving the mitigation against the flaw, their shiny new processor got a whole lot slower, or their PC stopped booting. They'll blame Microsoft who will in-turn point the finger at Intel, and they'll join whatever class-action lawsuit fits most appropriately for them.
Personally, I don't see how they avoid a large recall effort similar to the one that happened with early Pentium models in the 90s where they had a flaw that led to calculations being incorrect -- a flaw that could be corrected in software, as well, but that was clearly a hardware flaw.
Will the same thing happen to an open-source chip with a hardware flaw? Probably, yes. Will it be targetted at the company that produces the chip or the group that produces the specification? If the two are not one-in-the-same, it'll probably be the responsibility of the chip producer to handle the warranty claims and might result in a hardware recall of sorts unless the issue is one of software running on the chip that can be patched. The difference is that open hardware might spot the problem before production, and even -- if not -- the problem will have many more eyes on it for providing solutions.
[0] See paragraph 1. I'm not saying software production is free of costs; but unlike hardware production, it's possible for software production to be completely free of costs.
[1] Hell, it's difficult explaining it to industry insiders.
[2] Something which, given the debacle around the Intel ME, is very debatable.
People say "you need to have malware running on your system" as if it's not normal to run other people's code on a desktop system but it's actually very very common and why priviledge separation and user sandboxing is being done in modern operating systems. JavaScript has been successfully shown it can be used to exploit at least one of these bugs.
As soon as I hear of such an exploit in the wild, I'll panic. The demonstrations so far have consisted of arcane research papers and canned videos.
Send me a link to a PoC page that returns stored passwords, harvests cryptocurrency wallets, drops payloads, or otherwise screws with my unpatched system. Until then, I think people are grossly exaggerating how big a deal the Spectre/Meltdown exploits are.