15 ms·
Spectre/Meltdown Pits Transparency Against Liability
- jedharris 9y agoBunnie's logic seems impeccable. Let's put down the pitchforks -- for vendors that disclose. That leaves plenty of uses for pitchforks...
- monocasa 9y agoWell, unfortunately that doesn't help in the current US legal climate with how class action lawsuits work. Even if we as developers put down our pitchforks, a class action firm will jump on any perceived liability.
- tomc1985 9y agoHalfway through he notes how processors have millions of transistors, each being slightly different, and notes how we are just soooo lucky to have found a hardware bug now. 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.
- samstave 9y agoCan you please unpack "really flimsy supports" in ELI5 language? I dont get that part of your comment - though I was surprised IN understood your "I am not a hardware engineer" fluidly... But define "flimsy supports"
- steiger 9y agoIntel valued speed optimizations that are inherently insecure.
- deleted 9y ago[deleted]
- samstave 9y agoah. 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)
- username223 9y ago> Can you please unpack "really flimsy supports" in ELI5 language? 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(); } The Intel CPU may guess that security_check() will return true, and run secure_stuff(). When security_check() actually returns false, it doesn't clean up all of the results of running secure_stuff(), so error() can spy on what it would have done if security_check() returned true.
- rayiner 9y ago“Results” is a loaded term. In computation, “results” means the return value of a computation. Intel does keep you from observing the result of secure_stuff. What it doesn’t do is clean up all the side effects.
- pdpi 9y agoSpeculative execution modifies observable state. What you call it is imaterial.
- rayiner 9y agoWords have meaning. The “result” of a computation is different from side effects. The distinction is important. Speculative execution will always modify “observable state.” E.g. power usage.
- dfox 9y agoThe point there is that what spectre/meltdown exploits are sideffects that are not part of the architectural state as it is specified by any manufacturer. The whole issue points to the fact that security-wise the typical approach used for descriptions of CPU's architectural behavior is insufficient as there can be implementation-specific observable sideeffects that have security ramifications.
- tomc1985 9y agoI am referring to their flawed implementation of speculative execution, with respect to how much of today's CPU performance is due to it.
- monocasa 9y agoIDK, I think there's a way to have your cake and eat it too WRT chip level optimizations. 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.
- tomc1985 9y agoI didn't even know rings 1 and 2 were even relegated to the dustbin.... so everything is ring 0 now?? 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?
- monocasa 9y ago> I didn't even know rings 1 and 2 were even relegated to the dustbin.... so everything is ring 0 now?? 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.
- deleted 9y ago[deleted]
- CamperBob2 9y agoIf mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad? "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.
- avianlyric 9y ago> Halfway through he notes how processors have millions of transistors, each being slightly different, and notes how we are just soooo lucky to have found a hardware bug now. 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.
- monocasa 9y agoAnd it's not just embedded devices. AMD and Intel put out tons of errata too.
- MaxBarraclough 9y ago> Intel's reputation is partially built on speed Except the Spectre vulnerability isn't specific to Intel's chips.
- gnode 9y agoIn the case of Spectre/Meltdown, it's not simply a case of finding the vulnerabilities and patching them; the workarounds result in significant performance costs, and essentially mean the processors affected are now less capable than when they were sold. This incurs damages for the people whose computing is now slower / not fit for purpose, or who now have to buy more processors to meet their requirements. Openness is great, but I don't believe we should sell our guarantees for it, and put ourselves in a buyer beware situation.
- alkonaut 9y agoInterestingly this is very similar to the case of VW Diesel engines. They were cutting corners for performance, and the cheap fix (software) incurs a performance and/or efficiency penalty of the same magnitude as the Spectre/Meltdown patches. 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?
- roywiggins 9y agoVW intentionally misled buyers and regulators about the actual emissions of their cars. Unless Intel knew about Spectre/Meltdown when they were designing their chips, it's a pretty different situation legally speaking.
- mtgx 9y agoThey did know. Or at least there were papers about it back in the 90's.
- alkonaut 9y agoAgree. They did sell a product that doesn’t do what customers expect though, but I assume customers weren’t misled by that either simply because Intel don’t put performance figures on the boxes (and the theoretical performance is unchanged - it might be different if a manufacturer would e.g disable half the cache or cut clocks 15% to fix an honest design mistake)
- rrggrr 9y agoThe question that needs to be asked is this... were Intel subject to the same products liability laws as auto manufacturers or drug makers, would it make Meldown, Spectre and the ME vulnerabilities less likely? We know from other industries that products liability laws make for safer products, but we refuse to acknowledge that our CPU's are critical to safety because we don't pay much attention to how pervasively they are used, or the 2nd and 3rd order effects of flaws in the chips. 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.
- SimonBiggs 9y agoThere would need to be two separate products. One covered by higher liability intended for use in critical systems, and the other under the standard liability. 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.
- gnode 9y agoWhat's a critical system? Is it okay for some things to have compromised security?
- dfox 9y agoSafety and security are two different things that are very often at odds with each other.
- the8472 9y agoThat's pretty much what the military and satellite operators buy. Older, simpler CPUs manufactured on larger nodes, radiation-hardened to boot and with years of proven track record and bug fixes. And then they buy two or three per system for redundancy.
- chris_wot 9y agoI don't think this makes much sense. Currently the Intel chips aren't open at all. If they were open, then this article might have a point - demanding that Intel replace or fix their broken products would indeed cause issues. 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).
- confounded 9y agoHis bargain (if I’ve understood) is that they should open the software and designs, or replace physical chips.
- mmirate 9y agoIsn't this what insurance is for?
- gnode 9y agoI'd agree, although maybe it's not that simple. For insurance to work, actuaries need to be able to determine the risk with reasonable accuracy. For car crashes and medical malpractice there's a lot of statistics, for newly discovered hardware vulnerabilities, less so.
- mmirate 9y agoFair enough. But the inherent complexity of a modern Intel hardware design surely puts at least a lower bound on the probability of bugs.
- ajdlinux 9y agoThe upper bound is just as important for working out an insurance premium...
- gnode 9y agoIf there were a lower bound, then there would be no point in insuring against it. If I knew I will incur at least $1B a year in legal losses, then I'd budget for it. Insurance is for covering the upper bound.
- mozumder 9y agoAt this point, the only people that should be worrying about Spectre/Meltdown are cloud hosting providers. For individual users, Spectre/Meltdown attacks rely on malware processes running on your computer, and if that is happening, you have bigger problems to worry about.
- nokcha 9y agoJavaScript code running in a properly sandboxed modern browser can potentially exploit these vulnerabilities.
- d1zzy 9y agoIs some piece of JavaScript loaded in your browser one of those "bigger problems to worry about"? What about some Windows tool I download to help me run games in borderless fullscreen? What about videogame mods? And here I was hoping that running everything as a regular/non-admin user is sufficiently secure... 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.
- CamperBob2 9y agoIs some piece of JavaScript loaded in your browser one of those "bigger problems to worry about"? 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.
- mozumder 9y agoJavascript Spectre/Meltdown attacks are already effectively defeated through browser updates that reduce timer accuracy.
- Animats 9y agoStanford's EE 380 had a talk on these vulnerabilities yesterday, from the Red Hat guy working on mitigations. There were some CPU designers in the audience. (Not Hennessey, though.) 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.
- Dylan16807 9y ago> 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. What uses cases involve running new untrusted code on legacy unsupported systems?
- speakeron 9y ago> 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.)
- 9y ago
- perlgeek 9y agoI'm not quite buying the central point of this piece. 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.
- amarkov 9y agoYou can want transparency all you want, but you're not going to get it. I guarantee that, in any large for-profit software product you use, the devs know of at least one unprivileged read bug which they will not disclose.
- bostonvaulter2 9y agoPartially related, does anyone know if AMD support on Linux is basically on par with Intel?
- iaw 9y agoFor CPU support, last I checked: yes. I was able to use AMD CPUs transparently. Now on graphics cards support for Machine Learning applications AMD falls short of Nvidia, but that's a different processor.
- bri3d 9y agoAlso, AMD graphics card support for graphics applications is generally excellent, especially in the last few months with newer cards. AMD have released a fully open-source driver chain called AMDGPU, the only caveat being that it uses an open-source LLVM-based shader compiler toolchain that's somewhat slower on some workloads (and somewhat faster on others!) than whatever proprietary thing is in their blob drivers, which are called AMDGPU PRO.
- sangnoir 9y agoAMD is working hard on the opensource AMDGPU Linux drivers, they have been working well for me. Unfortunately, AMD doesn't have parity with Nvidia's CUDA, there are nascent efforts to compete with ROCm/OpenCL, but CUDA is quite far ahead for ML applications. Sadly, upstream TF relies on CUDA and isn't showing any signs of supporting AMD GPUs. 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.
- hi41 9y agoWhat does the Spectre/Meltdown bug mean for a person planning to buy a new Windows 10 computer? Should I buy an AMD CPU based computer instead of an Intel based computer?
- lowbloodsugar 9y agoThis is called ethics! Its interesting that the idea that a Fortune 500 company could behave ethically is immediately written off, indeed, not even discussed as a solution.
- thescriptkiddie 9y ago> To simply say, “but hardware manufacturers should ship perfect products because they are taking my money, and my code can be buggy because it’s free of charge” – is naïve. 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?
- neltnerb 9y agoYeah, I agree with you. There is no relationship, and definitely not a vendor relationship, between an open source developer and someone who downloads their work and uses it in exchange for nothing. 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.
- mannykannot 9y agoOpenness and liability seem to be largely orthogonal in practice. While I agree with the author that there would be little in the way of open-source software if its developers could be held responsible for any flaws, there is a lot of commercial, closed software that is almost as well shielded from liability. On the other hand, drugs are open in the sense that their chemical formulae are known, yet their producers carry considerable 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.
- bunnie 9y agoAfter seeing comments around the Internet on the article, one thing I wanted to add is this: 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.
- lvoudour 9y agoThe 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. 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.
- Iv 9y agoI don't trust the companies to be held accountable in court anyway. Open it up and let the market punish those who release buggy hardware with reputation loss!
- Chris2048 9y agoThe compromise is that you don't prefer transparent competitors, or launch lawsuits against them. Events like Spectre might represent a sustainable solution if the law gives the backlash teeth.
- mdip 9y agoThere's a bit of apples to oranges comparison going on here between open hardware and open source software with regard to liability. The situation here is falling into the same trap that the RIAA/MPAA/Copyright institutes fall into when trying to compare piracy against theft of goods. 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.