
Spectre/Meltdown Pits Transparency Against Liability - beardicus
https://www.bunniestudios.com/blog/?p=5127
======
bunnie
After 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
_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._

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.

------
tomc1985
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_.

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
Can 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
Intel valued speed optimizations that are inherently insecure.

~~~
samstave
ah.

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)

------
Animats
Stanford'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
> 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
> 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.)

~~~
Dylan16807
> The thinking here, I suppose, is that Meltdown makes privilege escalation
> straightforward once a malicious party has access to the system via another
> vector.

On an unpatched system, that's not likely to be hard in the first place.

------
rrggrr
The 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.

~~~
andmarios
There are more questions that arise from this. For example if Intel were more
vigilant and this lead to a 10x reduction in technological progress (CPU power
has increased exponentially), how many lives would have been affected or even
lost because cutting edge research that relies on super computers would happen
40 years from now?

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.

~~~
gnode
I'm very happy for self driving cars to move 30 years into the future if that
means not leaving their CPUs open to known vulnerabilities.

~~~
LeifCarrotson
1.25 million people die in auto-related accidents each year. That's one person
every 25 seconds.

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?

~~~
perl4ever
Everyone dies exactly once, no matter what they do, so I question whether
driving _causes_ any deaths at all. I think the comparison might need to be
put in terms of quality adjusted person-years of life lost or something.
People get tunnel vision when focused on optimizing a certain metric. If
nobody was driving, how much would life expectancy go up?

~~~
LeifCarrotson
That only strengthens the argument.

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.

------
gnode
In 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
Interestingly 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
VW 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.

~~~
alkonaut
Agree. 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)

------
jedharris
Bunnie's logic seems impeccable. Let's put down the pitchforks -- for vendors
that disclose.

That leaves plenty of uses for pitchforks...

~~~
monocasa
Well, 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.

------
mannykannot
Openness 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.

------
thescriptkiddie
> 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
Yeah, 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.

------
perlgeek
I'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
You 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.

------
lowbloodsugar
This 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.

------
chris_wot
I 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
His bargain (if I’ve understood) is that they should open the software and
designs, or replace physical chips.

------
bostonvaulter2
Partially related, does anyone know if AMD support on Linux is basically on
par with Intel?

~~~
iaw
For 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.

~~~
sangnoir
AMD 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
What 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?

------
mmirate
Isn't this what insurance is for?

~~~
gnode
I'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
Fair enough. But the inherent complexity of a modern Intel hardware design
surely puts at least a lower bound on the probability of bugs.

~~~
gnode
If 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.

------
mdip
There'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.

------
mozumder
At 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.

~~~
d1zzy
Is 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.

~~~
mozumder
Javascript Spectre/Meltdown attacks are already effectively defeated through
browser updates that reduce timer accuracy.

