
Solving Spectre and Meltdown may ultimately require a new type of processor - tosh
https://www.pcworld.com/article/3299477/components-processors/solving-spectre-and-meltdown-may-ultimately-require-an-entirely-new-type-of-processor.html
======
furi
Solving Meltdown absolutely does not require a new type of processor.
Performing out-of-order executions of privileged instructions is something you
can just not do, nobody except Intel is doing it right now in fact. Lots of
Spectre variants likewise don't require entirely new processor varieties, such
as the lazy floating point speculation vulnerability or the new L1 terminal
fault vulnerabilities. The only one that possibly requires a new type of
processor is the original Spectre, which is quite hard to completely stamp out
all possibility of while retaining the concept of speculative execution.

~~~
nickpsecurity
Since gruez mentioned it, I'll note Intel also pushed Itanium which had
security benefits almost nobody talks about in x86 vs Itanium discussions.
Secure64, co-founded by Itanium designer, uses them in SourceT OS which they
claimed got positive analysis by Matasano Security.

[https://www.intel.com/content/dam/www/public/us/en/documents...](https://www.intel.com/content/dam/www/public/us/en/documents/white-
papers/intel-itanium-secure-white-paper.pdf)

They also claimed the Itanium-based solutions were immune to Spectre and
Meltdown. I'm not a CPU expert. I'll let others review that. A lot of attacks
are showing up.

[https://secure64.com/not-vulnerable-intel-itanium-
secure64-s...](https://secure64.com/not-vulnerable-intel-itanium-
secure64-sourcet/)

So, the processor that was about stronger reliability and security that _the
market and mainstream security ignored_ seems to mitigate some of the risks
both are now griping about. Maybe folks who don't depend specifically on x86
might buy some Itaniums to signal they'll pay for security-enhanced
processors. Be sure to tell the sales rep why so they can pass it up the
chain. :)

For embedded stuff, there's also Microsemi's CodeSEAL and Dover's CoreGuard
which have advanced protections. The first has encrypted/authenticated RAM
plus control-flow integrity at CPU level. The second has a flexible, metadata
unit that enforces many types of security policies at CPU level on per-
instruction basis.

~~~
close04
Itanium is dead, after 15 years on the death bed. To my knowledge there is no
plan to launch any new Itanium CPU. The only reason the 9700 was launched in
2017 is to serve as a drop-in replacement for old CPUs, most likely for
contractual obligations.

There's simply no "killer feature" for Itanium. It's not coming back.

~~~
nickpsecurity
That serves my point that introducing a security-enhanced processor didn't
work for Intel. i432 APX and i960 also failed at a loss of over a billion
dollars so far when Intel tries to make better, safer CPU's. The customers
wanted backward compatible with x86's warts, highest performance per dollar,
and decreased energy. That's what Intel gave them at billions in profit.
They're making patches for the security weaknesses and/or fixing them in newer
CPU's. Vendors of insecure processors still dominate while the few processors
with better security sell almost nothing.

So, Intel should continue to make deliberately insecure processors and patch
them since that's what people pay for. It's the market's fault for rarely
buying anything better. Plus, voters not doing something about patent reform
which would've led to more x86 competitors. The Chinese supplier is an
interesting development where we might get a secure-ish x86 that way.

"There's simply no "killer feature" for Itanium. It's not coming back."

I just named its killer feature: security enhancements that make it hard to
inject code into it. Most security audits of OS's find problems. The one of
SourceT on Itanium didn't find a way to inject code into it since it used
hardware to mitigate and contain most of that. Whereas, the protections on x86
are a source of vulnerabilities at the moment.

Unfortunately, that was the only company that I'm aware of which saw that
potential. The market's direction means they're porting the product to
insecure hardware right now. Who knows what they'll come up with since it's
impossible to secure software on insecure hardware. I'm so grateful to the
markets for buying such things so little that they basically don't exist in
the mainstream space.

Note: Another example was Cell processor. Green Hills, who make INTEGRITY-178B
OS for high security, did an assessment of the Cell processor for baking
security into systems. It had some nice capabilities for that. Market wasn't
going to buy it even to protect their systems, though. So, they're not pushing
that.

~~~
close04
> Intel should continue to make deliberately insecure processors and patch
> them since that's what people pay for.

Unfortunately... What's more disappointing is that while you expect the
average Joe to go for shiny-new-fast, enterprises should have been a little
more restrained.

But hey, it's only an issue when it's found and with the power of hindsight
all decisions are easy.

~~~
nickpsecurity
It wasn't hindsight: we've been publishing and describing these risks along
with techniques to mitigate them for decades.

[https://news.ycombinator.com/item?id=16092183](https://news.ycombinator.com/item?id=16092183)

Mainstream security ignores it for political reasons. They're like a cliche
that pretend all prior work that's not like theirs or are outside their social
groups didn't happen. Enterprise ignores it since management gets rewarded for
either high-growth or low-cost deployments. Those tend to favor insecure
deployments. The consumers don't care enough for I guess psychological
reasons. They don't even adopt usable, free stuff like Signal most of the
time. Much less paid options.

The high-assurance, security field has steadily done their part producing
secure versions of hardware and software to address these risks. They usually
knock out entire classes of attack. Almost nobody uses them outside of
aerospace and defense. For hardware, few companies will build the secure
prototypes since prior examples went bankrupt. The Spectre/Meltdown situation
gives potential to use it as a buzzword pushing new hardware. That hardware
needs to be totally compatible with existing OS's/RTOS's and C language,
though, with almost no performance or cost hit. I think secure ARM's or MIPS's
are best start. CoreGuard is example targeting them plus RISC-V. We'll see
what happens.

~~~
close04
Because the regular timing attacks were always relatively easy to mitigate in
software with low performance penalties?

Unless I'm misreading your comment, you're saying Meltdown and Spectre are
just the "run of the mill" cache timing attacks about which tens or hundreds
of papers were written in the past years. In which case the same mitigations
should still apply since they have been used in cryptography for decades.

If this is the case and there's nothing more to them, and since you appear to
be working in the field, I have one question: what is it that triggered this
kind of response now that wasn't already triggered by the swath of already
existing papers?

~~~
nickpsecurity
Now you're putting words in my mouth. I'm saying almost all of the advice and
techniques were ignored by security community for years whether it incurred a
performance penalty or not. That's covert channels in general plus cache-based
timing channels. I mean, when is the last time you saw someone writing FOSS
with crypto or for security say they did a covert, channel analysis of their
software? Pretty much never happens even though it was a mandated step in
older and current evaluations with every certified product at EAL5 or above
getting one. Heck, we couldn't even get a lot of developers to stop using C
when safer languages like Ada or Modula-3 were available that fit their use
case. Companies that claimed to take security seriously and had money for
secure products wouldn't buy them. People who had money or whose uses could
fit safer processors often didn't buy them.

Hell, one company whose products got lots of analysis were selling a secure
RTOS, file system, and network stack for $50,000 license with no royalties. A
router company could've greatly reduced attack surface that way on top of
reliability/predictability improvements. The big players had huge piles of
money, too. IIRC, only one company, not a big vendor, put a separation kernel
in a network switch. And withdrew it later since nobody bought it. Sirrix is
still selling stuff with similar design (Google Mikro-SINA architecture) but
not same assurance or amount of evaluation. GENU is using OpenBSD variant.
Only two I can think of that probably sell a lot of product and will be around
a while.

It's pretty systematic that strong methods and products are ignored. Far as
security folks, most of them don't know anything about this stuff despite it
being in colleges, conferences, here on HN, and so on a long time. Those that
hear about it mostly dismiss it often not even knowing what's in it. A
cultural thing given they're dismissing stuff that resists attack well in
favor of stuff that often fails. If they didn't, they'd have known about
cache-based, timing channels in 1992. A paper somewhere in 1992-1995 range
referencing that work analyzing either VAX or x86 noted potential leaks in
many components and modes. It called for every component to be made leak proof
to maintain the security policy. As usual, both private sector _and security
folks_ acted like that stuff didn't exist. They patted themselves on the back
when rediscovering the same shit in 2005. Others digging into it more found
Meltdown/Spectre many years later. NICTA doing a systematic analysis more like
1990's work found all kinds of attack surface in one pass:

[https://ts.data61.csiro.au/publications/nicta_full_text/9074...](https://ts.data61.csiro.au/publications/nicta_full_text/9074.pdf)

Meanwhile, those in CompSci and industry that paid attention were working on
hardware architectures that minimized problems. Partitioning caches,
asynchronous execution with randomization (I independently invented this), and
masking are examples. An product example is Rockwell-Collins' AAMP7G CPU that
was mathematically verified for correctness, embedded a separation kernel that
does time/space partitioning between processes, did a proof it was correct,
and triplicated the registers with voting to increase reliability in face of
cosmic rays or individual failures. So, the CPU itself mitigates timing
channels plus separates processes with maybe stronger assurance than seL4
given a microcode-level proof on verified CPU. They also have tools to prove
your algorithm and assembly code match to prevent abstraction attacks. They
sell those CPU's commercially in aerospace and defense. They use the tools to
build stuff for their customers, esp crypto for NSA.

Cambridge is doing CHERI which runs FreeBSD; Microsemi's CodeSEAL has control-
flow integrity with encrypted, authenticated RAM for FreeRTOS;
Softbound/Hardbound/Watchdog team has theirs for safety; several teams have
done non-interference for hardware with one proven down to the gates; Edmison
did encrypted/authenticated RAM in a way that preserved legacy processor
architecture and blocked some software attacks; Dover is doing SAFE
architecture (crash-safe.org) for ARM/MISP/RISC-V called CoreGuard; SCOMP,
first system certified by NSA, had security kernel, leak analysis, and an
IO/MMU in 1985; AS/400's predecessor had capability-based security at hardware
level; Burroughs B5000, the first mainframe in 1961, was immune at CPU level
to most forms of code injection at CPU level.

These methods were published enough that all kinds of people were building on
them. Most security professionals ignore them, even claiming nothing was ever
achieved (just "red tape"). That's straight-up slander. The industry and
consumers mostly didn't buy them since they wanted to either minimize cost
(security is externality) or wanted specific benefits of insecure stuff (often
got hacked). If they want secure CPU's, they can just buy some I mentioned
that still exist and/or (supply side) build them based on highly-detailed
descriptions of other stuff. CHERI is even open-source running C language and
FreeBSD on FPGA board. You can bet a MIPS licensee hasn't built a CHERI SoC
since they believe market won't pay for it.

" I have one question: what is it that triggered this kind of response now
that wasn't already triggered by the swath of already existing papers?"

You'll find that most things in IT, including INFOSEC, are driven by mass
psychology more than technical reasons. I'll demonstrate instead of explain
using Heartbleed. It drove a lot of security discussion and fixes. Yet, it
would've been prevented by pre-existing advice on using safe languages like
Ada or a combo of tools plus development practices on C code. David A. Wheeler
illustrates all the stuff that was available which developers were ignoring
here:

[https://www.dwheeler.com/essays/heartbleed.html](https://www.dwheeler.com/essays/heartbleed.html)

So, someone finds the attack, they publish it with a catchy name, and suddenly
people are all over this issue. It drove even more activity in that part of
the field. They can either adopt the advice of the people who managed to dodge
all that or they can't focus on the narrow problem affecting them right now.
Most response to Heartbleed did the latter with them still using unsafe
practices and underusing available tooling. Baseline did increase in some
places, though. That was good.

I think Spectre/Meltdown is just another example of that effect in action. It
probably has a name already like herd behavior, getting on bandwagons, etc.
Like before, they have at least two choices: listen to the people who used
specific techniques to discover everything from cache-based channels to
operating system leaks, using those same techniques that worked again; ignore
all that to focus on every way you can squeeze a side channel out of the same
or other components of x86. The correct answer is the first since it will do
the second as a side effect plus show you all the other channels elsewhere.
Kemmerer's and Wray's methods were universally applicable. Most work following
Meltdown/Spectre is ignoring that to react to the specifics of the attack with
narrower focus. Most, hopefully not all, of the solutions being designed will
fail since they clean up a problem here while ignoring those over there. And
we'll get another fix and another. Avoidable damage will keep happening.

I am _hoping_ that a better scenario plays out with things like CoreGuard
coming to market right as hardware is getting attacked. The better scenario is
it sells profitably due to heightened awareness which fuels further
development of secure hardware/software. We'll see.

~~~
close04
I wasn't trying to put words in your mouth, it's just what I could conclude
from this put in context:

> It wasn't hindsight: we've been publishing and describing these risks along
> with techniques to mitigate them for decades.

>[https://news.ycombinator.com/item?id=16092183](https://news.ycombinator.com/item?id=16092183)

It worked for decades and the issues were "ignored" (not given much of a
second thought) because everybody assumed that's all there is to the exploits.
Corner cases that can be easily mitigated in software. It's just when
everybody realized that the whole implementation _in hardware_ was broken that
the point was driven home.

Performance is what sold those CPUs when security just couldn't. Without the
critical mass of revelations recently I doubt security would have been
considered too much today. Just like privacy became a concern only with a
similarly shocking volume of revelations.

So looking back it's hard to say if Intel would have chosen another way. Yeah,
in hindsight you could say "if they just fixed it back then..." but in reality
nobody would have cared.

~~~
nickpsecurity
"Performance is what sold those CPUs when security just couldn't. Without the
critical mass of revelations recently I doubt security would have been
considered too much today. "

I meant to respond to this earlier. Yeah, it seems the mainstream acts when
it's in their face, there's working exploits, they're dressed up somehow, and
there's an immediate action to take. I guess the route to get secure
hardware/software architectures is a series of highly-publicized breaks in
every component with a Right Thing solution and alternative suppliers that
used it. They also move fastest when the damage is high.

So there's a recipe for change. Of course, there's possibly some ethical and
legal issues in there. ;)

------
noobermin
Something very relevant to this discussion was this article[0] from a few
weeks back. A bit of a clickbait title, but the points are very relevant: C,
based on the PDP-11, has a computation model that no longer really tracks with
how a computer actually works today, and in those gaps is where people insert
in stuff like speculative execution in the first place to be faster while
maintaining the guise to app developers of a "fast PDP-11".

[0]
[https://queue.acm.org/detail.cfm?id=3212479](https://queue.acm.org/detail.cfm?id=3212479)

Old discussion (skip the first reply for meat!)

[https://news.ycombinator.com/item?id=16967675](https://news.ycombinator.com/item?id=16967675)

~~~
flukus
Correct me if I'm wrong but assembly doesn't offer many more entries into this
computation model either does it, especially when considering some non-
standard extensions to C? So they've added a lot of processor features with no
API.

Is there a reason speculative execution had to be added to the processor and
not compilers? Would we have been better off if the true memory model was
exposed to compilers?

~~~
xenadu02
The ground is littered with the dead bodies of CPU designers who said “we’ll
just make a smart compiler”.

The CPU knows what the software is actually doing and has done in the past.
The compiler does not.

The CPU can change implementations; the compiler must bake any assumptions in
at build time.

Speculative execution is required so long as memory latencies are so large.
That trend isn’t reversing itself anytime soon.

~~~
gruez
>The CPU knows what the software is actually doing and has done in the past.
The compiler does not.

profile guided optimizations?

~~~
gmueckl
Profiles capture only program brhabiour under test Data and sssumed that that
pattern is prevalent. If the actual runtime behaviour is bimodal or worse,
then only one mode will be optimized at most. A CPU can keep statiatics at
runtime (the branch predictor does) and thus adapt ever so slightly to the
actual current program behaviour.

~~~
flukus
Runtime optimizations have there own problems. Sometimes the rare case will
also be the most sensitive, sometimes the statistics will take too long to
turn around, etc.

At least profile guided optimization gives you a degree of control.

------
Bucephalus355
During World War I, in order to get a decent working radio, the US government
suspended lots of IP restrictions and made companies pool their patents.
Perhaps in the future we could see something like this.

Considering that radio stocks were the “hot item” in the 20’s, to a point
where it became something of a bubble, it doesn’t look like businesses made
out too bad.

------
_chris_
I gave a talk on this topic at a recent RISC-V conference (slides here: [1]).

I think this can entirely be hidden below the ISA abstraction, but it will be
a lot of development work to do this and unfortunately getting new hardware
into the field is a slow process. One part of this is buffering and killing
speculative updates (or flushing on "time domain" switches). The other, and
harder part, is to manage/avoid bandwidth contentions caused by speculation.

I think the better, long-term solutions will involve address IDs/capabilities
to better denote security boundaries to the hardware. But that requires a lot
of buy-in across many layers of the compute stack(OS/platform change for
starters).

[1] [https://content.riscv.org/wp-
content/uploads/2018/05/13.00-1...](https://content.riscv.org/wp-
content/uploads/2018/05/13.00-13.15-Celio-Barcelona-Workshop-8-Talk.pdf)

------
zlynx
I heard rumors that Intel set up a research group to fix this in hardware as
soon as the Spectre exploit showed up.

Mill may be cool and all but x86 isn't going anywhere.

Although I think it'd be hilarious if Intel decided to bring back Itanium with
explicit per task cache indexing and no speculative execution. They already
have the technology while Mill has never had a silicon implementation.

------
mindslight
Yeah - AMD!

(I kid)

Although seriously with the "invisible hand" pushing platform lockdowns across
the industry, it's time to stockpile some G34's next to the canned goods.

~~~
lysp
The Alternate Mitigation Device cpu?

------
gwbas1c
Two of the most important things about security is understanding how valuable
information is and how likely an attack is. Specter is very hard to pull off,
thus it will probably only be used for highly valuable information.

------
TwoBit
I keep thinking, surely Intel and AMD were internally aware of spectre. How
could they not foresee it?

~~~
acdha
The same way most security bugs happen: people are focused on making the
expected results happen. The skill of thinking about how something could
creatively be abused is hard to cultivate – theoretically this class of bugs
has been around for decades but it wasn’t publicly exploited until now.

------
alexeiz
Am I the only one with the impression that Spectre and Meltdown
vulnerabilities are way overblown? At the company I work for, nobody cries
bloody murder about them. I don't see other organizations scrambling to update
their infrastructure either. For the amount of press these vulnerabilities get
there is very little action taken.

------
acct1771
RISC is good.

------
mhkool
The "new processor" is already being developed. Mill computing is designing
the Mill CPU and made 13 videos so far on Youtube explaining most
characteristics of the new CPU. The CPU is on par with the latest Xeon, uses
10x less power, and has many great features that enhance performance and
security a lot. For example, portals calls are function calls from protection
domains to another protection domain and automagically only allow the
parameters to be read by the callee and the results be read by the caller. The
rest of the data of the other protection domain cannot be accessed. The stack
is also secure since there are 2 stacks: one holds all data that one normally
find on a stack and is modifiable by the program and the second stack is a
hardware-managed stack with the return addresses which is hidden from
software. Also the protection on the stack changes with each call and each
return such that a stack overflow results in an immediate fault. The CPU has
many more features, too many to name here.

~~~
bsder
> The CPU is on par with the latest Xeon, uses 10x less power, and has many
> great features that enhance performance and security a lot.

Here's the last two companies to spout this line of garbage: Transmeta and
SiByte. Remember them?

Your statement implies that the Intel engineers have left a lot of design on
the table. I assure you, this hasn't been true for quite a long time (circa
1996, arguably, but certainly not since 2000--that's why both Transmeta and
SiByte failed).

The simple answer to this is: graph the active area vs power consumed for all
the chips of a particular technology node. Unless Intel is significantly below
that line, you're not going to beat them by much.

~~~
wtallis
> Your statement implies that the Intel engineers have left a lot of design on
> the table.

The Mill folks would rather argue that Intel's problem is they _aren 't_
leaving things on the table—instead, they're shoving tons of extra machinery
into their core designs while the Mill tries to avoid extremely power-hungry
performance enhancing techniques like speculative out of order execution.

> graph the active area vs power consumed for all the chips of a particular
> technology node

Setting aside the difficulties of accounting for differences between different
manufacturer's processes at the same node, this still isn't a very informative
measure. Active areas of the chip don't all make the same contribution to
performance. Speculative execution can light up a lot of silicon executing
instructions that don't actually need to be executed.

I'm quite skeptical that the Mill guys will ever produce a core that beats
Intel on raw performance, but they have plenty of convincing arguments for why
their power consumption will be much lower, and I think it's plausible that
they will be able to beat Intel on performance per watt for some workloads.

~~~
bsder
> Mill tries to avoid extremely power-hungry performance enhancing techniques
> like speculative out of order execution.

Go look at Alpha 21164 vs x86 in the timeframe. You don't save as much as you
think (and Intel's designs were much shoddier back then).

> Setting aside the difficulties of accounting for differences between
> different manufacturer's processes at the same node, this still isn't a very
> informative measure.

You would think so, but the graph is remarkably consistent. Just because a
measure has noise does not make it a useless measure.

Intel _could_ be significantly below the curve. But _beating_ the curve is
ferociously difficult.

