
Why Intel x86 must die: Our cloud-centric future depends on open source chips - rbanffy
http://www.zdnet.com/article/why-intel-x86-must-die-our-cloud-centric-future-depends-on-open-source-chips-meltdown/
======
wwarner
The fact that Spectre was manifest on Intel, AMD and ARM suggests that any
open source solution that utilized the same performance strategies would have
also had the same attack vector.

~~~
_chris_
_> any open source solution that utilized the same performance strategies
would have also had the same attack vector._

And then researchers, armed with open-source hardware implementations, can
openly probe the systems with white box attacks; then they can fix the system;
and then they can verify the fix.

In reading the Spectre/Meltdown white papers, I was a little disturbed at how
the authors had to grok through the fog to figure out how to attack the
machine, and that they could not say with certain if a particular CPU was
actually invulnerable or if their particular attack was simply ineffective.

------
newman314
Much as I am in support of open source, this isn't a magic cure.

I just got confirmation that POWER is susceptible to Meltdown/Spectre so
there's that...

~~~
rbanffy
But, at least, if the architecture (not just the ISA) are open, the safety can
be verified and, if we are lucky, even proven.

BTW, it seems SPARC (also open) is not vulnerable.

~~~
ThrowawayR2
> _...if the architecture (not just the ISA) are open, the safety can be
> verified..._

That's just the old "many eyes make all bugs shallow" fallacy, which has long
been discredited. Given that architects at nearly all of the processor makers
on the planet missed Spectre and the article itself notes that only "chip
weenies" (their phrasing, not mine) could've figured it out, there's no real
basis for such claims.

> _BTW, it seems SPARC (also open) is not vulnerable._

OpenSPARC happened to be open and happened to be not vulnerable, therefore the
former caused the latter? Unless there's some persuasive evidence otherwise,
that's clearly faulty reasoning.

~~~
rbanffy
The facts behind Meltdown and Spectre are not new. We all knew not all side
effects of speculative execution were reversed and some could even be
impossible to (even if you clear a cache, if a read went to the bus, the CPU
already disclosed to an external observer an execution path that was later
discarded).

What happened is that someone insanely clever figured out a way to exploit
those side effects we all thought were innocuous.

In the future, when someone looks at an open CPU design and spots an out of
order core that leaks side effects of instructions that were on branches not
taken, they'll hopefully remember this mess and proceed with care.

Processor erratas are always a worthy, even if sometimes terrifying, read.

And even if we consider the eyeballs are not optimally distributed, the more
eyeballs we have, the shallower the bugs will be. Like I mentioned, we all
knew (and I'm not even actively working in chip design - I'm just someone who
reads research papers when I can) some speculative execution side-effects
remain after the CPU rewrites the past and discards the primary effects.

------
nitr0wned
On the other hand AWS is moving toward its own proprietary chipset handling
networking and storage (Nitro). The next step might be to create their own
(proprietary) CPU that is more amenable to large scale virtualization and
doesn’t have the x86 baggage.

~~~
Stranger43
But who is going to be able to use those new completely non-compatible chips
for real world workload?

The problem for any fix is the same that faced Intels Itanium chips and the
manycore/CELL architectures is that you kind of have to reinvent the compiler
to use them and for manycore even that is not enough.

~~~
nitr0wnedalso
In the AWS case it probably would have to be transparent to users if they
designed their own cpu. I can’t imagine they’d get very far requiring
recompilation or with a performance impacting translation layer.

My main point is that cloud services infrastructure seems to be moving away
from open source software hypervisors (eg Xen) on commodity hardware towards
opaque custom virtualization on custom hardware. If they wanted to assure
their own security against bugs like spectre they would be more likely to
design their own CPUs than to use an open source one.

------
ksec
There is no silver bullet and it is not x86, its ISA problem, it is the
implementation that matters.

On the x86 must die notes, there are rumours that Intel is working on a new
ISA that takes the best part of X86-64 but put compatibility in the back-seat.
I just wish they call the new ISA "AE86".

------
Stranger43
The problem is more that we are still horribly addicted to single core
performance and cannot really utilize a proper manycore architecture likes the
ones coming out of china's higher end semiconductor industry.

This forces the semiconductor industry to keep coming up with clever hacks to
make their cores more efficient despite not being able to actually increasing
speed by introducing all sorts of "clever logic" that suffers the same kind of
bugs as software directly into the silicon, and until we stop doing that
spectra like bugs will likely keep resurfacing.

At this point the only thing unaffected seams to be low end arm cores(which
don't attempt to be smarter then they are), and a couple of obscure legacy
architectures like SPARC and Itanium.

------
mankash666
Looks like everyone's forgotten about the heart bleed bug - existed for a LONG
time in open source software.

Open source doesn't guarantee a big free, or backdoor free implementation.
Only validation budget & intensity does

------
anigbrowl
What does this portend for RISC/V and other architectures?

~~~
rbanffy
RISC-V is an ISA. You can implement it in vulnerable and not vulnerable ways.
My suggestion would be to extend, if needed, the ISA to mark instructions the
compiler can tell aren't safe to speculatively execute so that implementations
could use that instead of figuring it out on their own at runtime.

SPARC and POWER are also open. So far, it seems SPARC M7 and M8 are safe, but
all current POWER CPUs are not (but don't trust me on that - I didn't check
it).

~~~
anigbrowl
I'm sorry for phrasing it poorly. What I mean is, do you think the shifting
economic incentives will provide the push necessary for people to invest in
production and development on the RISC-V architecture? I'm not especially into
it myself, but I've been wondering if this might be the thing to get people to
move on from the x86 paradigm. I've always admired RISC because small
instruction sets seem that bit easier to validate, though (as you can tell)
I'm no expert on chip design.

