
Meltdown, aka “Dear Intel, you suck” - fcambus
https://marc.info/?l=openbsd-tech&m=151521435721902&w=2
======
jmull
Is it the right time to call out the fundamental wrongness of
Intel(/Apple/Microsoft/etc) outrage narratives?

I mean I get it: large corporations (1) don't necessarily have my interests at
heart; (2) are not able to perfectly execute (on extremely large and
complicated) products and systems.

um. This is as radical as taking a stand that the sun sets in the west.

I like HN because of the _promise_ that people think _just a little bit_
before just typing something that strokes their feelz-good neurons. Yet, here
we are on the front page with "In tel suxxx!" (and "Apple suxxx! in the htop
thread, etc., etc. etc.)

 _sigh_ I guess it's inevitable.

People just don't like paying for intangible things, so the only way to pay
for the internet is clickz/eyeballz. And OUTRGE! clickz/eyeballz are the
cheapest and easiest.

I know, I know. There was a bug from vendor X that really irked/irks you and
it feelz good to express your outrage.

I just wish there was just some corner of the internet where this wasn't the
dominant trend and I had hoped it was here on HN. Well, at least reddit has
extremely cute dog and kitten videos, and some chuckle-memes.

~~~
tomxor
The three big BSDs aren't exactly obscure, they might not have the highest
server market share compared to windows and linux but they are the next on the
list and often a primary choice for a variety of companies critical
infrastructure, the most commonly sighted example these days is netflix.

I think the outrage is justified.

~~~
hah-muh-rabbi
Don't mistake this as OpenBSD's concern for all BSD's. This is just OpenBSD
rant because they isolated themselves by not respecting embargoes in the past.
Some ARM CPU's are also vulnerable by the way.

~~~
tomxor
That's an interesting point RE OpenBSD, especially if FreeBSD and NetBSD were
included (which I do not know), I suspect this was just down to plain
irresponsible incompetence though.

...I've no idea what your ARM comment has to do with it though. Meltdown is
Intel specific.

A relevant question however might be who coordinated the work between june
2017 and now for Meltdown mitigations? Project zero at google discovered it,
but did they hand over the responsibility to Intel or decide who else to
inform themselves?

~~~
djsumdog
Has FreedBSD/NetBSD made a statement. I know DragonFly has a patch on master.

It's an odd world where Linux is in the "big three" and the BSD counterparts
are more on the fringe. It's a far cry from the early world of the 2000s.

------
DougN7
I don’t understand the Intel hate. It’s not like their engineers are dumb or
lazy. This exploit is very hard to imagine before now. And it’s there because
chip makers were trying to wring out more performance. It’s unfortunate if
anythig.

~~~
dantillberg
From my perspective: I've been singing Intel's praises for the last decade as
they regularly (for my own tests/usage) beat out AMD in performance, clock for
clock if not dollar for dollar.

With this recent news, I feel like part of the reason that Intel has been
doing so well is that they have been _cheating_.

~~~
dtech
Clock speed has been an awful metric for 2 decades now (except for within a
single CPU model series).

All processors (including AMD/ARM) since the early 90's have been using
instruction pipelining. It's a universal performance improvement, not Intel
cheating.

~~~
jdietrich
Intel get drastically more _instructions per clock cycle_ than anyone else,
which is a very useful metric. Intel processors still dominate in single-
threaded workflows. Meltdown makes that performance advantage look slightly
suspect - Intel might be cutting corners to squeeze out extra IPC at the
expense of security, reliability or accuracy.

------
tomkat0789
Hi I'm a mostly average Linux user just now learning about these hardware
vulnerabilities as I'm planning on building a new computer. What new processor
should I buy that has the best chance of being safe when all this dust clears?
I first posted this question on a thread about Intel ME. Have processors
always been this tricky security-wise or are these low level exploits we're
finding a recent phenomena?

~~~
m-p-3
You could go with AMD which is seemingly immune to Meltdown, but apparently
someone already found a security flaw with their PSP (aka their own Intel ME).

~~~
internalfx
If you need security and it doesn't need to be fast, use a raspberry pi.

No ME, no PSP, no meltdown, and no spectre.

~~~
pritambaral
The firmware driving the VC4 on an RPi is non-free and closed, and the VC4
runs with greater privilege than the ARM core, with access to all the RAM.
This firmware may not have security bugs like the ME and the PSP have had, and
it may not contain a backdoor that we know of, but technically there's nothing
stopping it from having one without anyone in the public knowing it.

Still, no Meltdown and no Spectre on any RPi

------
loeg
> Personally, I do find it....amusing? that public announcements were moved up
> after the issue was deduced from development discussions and commits to a
> different open source OS project. Aren't we all glad that this was under
> embargo and strongly believe in the future value of embargoes?

This is a bogus criticism. The issue was successfully embargoed for something
like six months(!) before being published a week early.

------
manyoso
Meanwhile I have seen nothing from QNX or Integrity...

~~~
jacquesm
I wonder to what extent QNX would be affected. It all depends on whether or
not they map their micro kernel into the same address space as the
application, for a micro kernel there is absolutely no reason to do that, the
only things you might want to re-map are the message buffers and that can be
done with some page table trickery.

~~~
dfox
QNX does map it's kernel onto high end of user VM space.

Due to how i386 TLB works (ie. no ASID) doing that is essentially required to
get reasonable performance, micro kernel or not.

~~~
cesarb
If the kernel has no sensitive state (believable for a microkernel), what
matters is whether it maps the physical memory in its kernel space.

~~~
dfox
QNX 6.5 apparently maps first 256MB of physical memory into kernel space at
fixed location. Also I believe that QNX's kernel memory contains region that
maps to pages of user space memory of other processes (as part of the message
passing mechanism, but I'm not exactly sure that I understand correctly how it
actually works).

------
cleeus
google cache:
[https://webcache.googleusercontent.com/search?q=cache:jqSuv7...](https://webcache.googleusercontent.com/search?q=cache:jqSuv7U6AjAJ:https://marc.info/%3Fl%3Dopenbsd-
tech%26m%3D151521435721902%26w%3D2+&cd=1&hl=de&ct=clnk&gl=de)

~~~
StavrosK
Cleaner IPFS link:
[https://www.eternum.io/ipfs/QmQU1bCPsg7VY5puKqH6wZfAv1ZWBteK...](https://www.eternum.io/ipfs/QmQU1bCPsg7VY5puKqH6wZfAv1ZWBteKTCgHRKzmVGodBV/)

By the way, here's a short script that will download a (full) page with wget,
add it to IPFS (if you have a running daemon) and copy the Eternum link to
clipboard:

[https://www.pastery.net/zxkzkc/](https://www.pastery.net/zxkzkc/)

~~~
the_mitsuhiko
I love how that link just completely times out.

~~~
StavrosK
Works just fine for me? Which link?

~~~
QasimK
The link [1] that you posted does not load for me either. I get Cloudflare's
Error 504 Gateway time-out.

[1]:
[https://www.eternum.io/ipfs/QmQU1bCPsg7VY5puKqH6wZfAv1ZWBteK...](https://www.eternum.io/ipfs/QmQU1bCPsg7VY5puKqH6wZfAv1ZWBteKTCgHRKzmVGodBV/)

~~~
StavrosK
Hmm yeah, it's doing that for me now too. I'm afraid the IPFS node is a bit
unstable, I've restarted it and hopefully it'll work better, thanks.

Any other IPFS node will work just as well, such as
[https://ipfs.io/ipfs/QmQU1bCPsg7VY5puKqH6wZfAv1ZWBteKTCgHRKz...](https://ipfs.io/ipfs/QmQU1bCPsg7VY5puKqH6wZfAv1ZWBteKTCgHRKzmVGodBV/).

------
ksec
May be time for OpenBSD people ( if they have the resources ) to build a CPU
from ground up with RISC-V?

~~~
sverige
OpenBSD has struggled at times to pay their power bills. They don't have the
resources to branch off into building new hardware from first principles.

~~~
hanniabu
Hopefully there are some tech savvy new crypto millionaires that are willing
to help contribute to worthy projects such as this.

~~~
akerro
Yea, why don't you start?

------
fny
Is there not some sort of OS embargo consortium that could be created to
resolve this?

~~~
blibble
they previously broke the KRACK embargo (among others):
[https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbh...](https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbhnfz)

it's no surprise they're not high up on the list of important people to tell

~~~
temprature
He told them they could go ahead, he then regretted it but that's not
OpenBSD's fault.

From
[https://www.krackattacks.com/#openbsd](https://www.krackattacks.com/#openbsd)
:

 _> As a compromise, I allowed them to silently patch the vulnerability._

Receiving permission to patch is the opposite of breaking an embargo.

~~~
xucheng
And it continues:

> As a compromise, I allowed them to silently patch the vulnerability. In
> hindsight this was a bad decision, since others might rediscover the
> vulnerability by inspecting their silent patch. To avoid this problem in the
> future, OpenBSD will now receive vulnerability notifications closer to the
> end of an embargo.

------
JdeBP
Duplicate at
[https://news.ycombinator.com/item?id=16084670](https://news.ycombinator.com/item?id=16084670)

~~~
baxtr
This one has already more upvotes

------
alsadi
Why you single intel on this, ARM and POWER also affected

[https://www.ibm.com/blogs/psirt/potential-impact-
processors-...](https://www.ibm.com/blogs/psirt/potential-impact-processors-
power-family/)

~~~
roblabla
Everyone is affected by Spectre, but my understanding is that Meltdown is a
particularly powerful "version" of Spectre that only affects Intel CPUs ?

~~~
Fnoord
My ELI5 attempt:

There are 3 vulnerabilities.

Meltdown is 1 of the 3. Meltdown is pretty much Intel only. Some ARM SoCs are
also affected, but these are relatively rare. AMD64 is unaffected by Meltdown.

Spectre are the other 2 vulnerabilities. Spectre affects pretty much everyone.

Meltdown is more severe, and more of a blunder.

For a technical explanation, see [1]. Was recently referred to at HN as well.

[1] [https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-
vulne...](https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-
to-spectre-or-meltdown/)

~~~
K0nserv
Do you have any source on why AMD64 is unaffected? The paper only mentions
that they couldn't make their current approach work on AMD, but it doesn't
rule out that it could be improved and made work

~~~
betterunix2
AMD's microarchitecture does not perform speculative loads that would cause a
segfault, according to this AMD engineer:

[https://lkml.org/lkml/2017/12/27/2](https://lkml.org/lkml/2017/12/27/2)

~~~
K0nserv
> We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs.
> However, we did not manage to successfully leak kernel memory with the
> attack de- scribed in Section 5, neither on ARM nor on AMD. The reasons for
> this can be manifold. First of all, our im- plementation might simply be too
> slow and a more opti- mized version might succeed. For instance, a more
> shal- low out-of-order execution pipeline could tip the race condition
> towards against the data leakage. Similarly, if the processor lacks certain
> features, e.g., no re-order buffer, our current implementation might not be
> able to leak data. However, for both ARM and AMD, the toy example as
> described in Section 3 works reliably, indi- cating that out-of-order
> execution generally occurs and instructions past illegal memory accesses are
> also per- formed.

From the Meltdown paper[0] section 6.4 it would seem that out of order
execution referencing illegal memory locations still occurs unless of course
I'm misunderstanding something.

0:
[https://meltdownattack.com/meltdown.pdf](https://meltdownattack.com/meltdown.pdf)

~~~
Khoth
The section 3 toy example is demonstrating that OOO execution can cause
instructions after a faulting instruction to be speculatively executed, but in
that example the subsequent instructions do not depend on the result of the
faulting instruction.

AMD's claim is that the result of the faulting instruction can never end up
affecting a later speculated instruction - ie, for Intel the bad access says
"here's the value you asked for" and later says "actually you don't have
permission, forget you saw that". For AMD the bad access says "you don't have
permission, so no result available"

~~~
K0nserv
Thanks for the explanation. So it's down to when the access check is
performed. I wonder why Intel did it the way they did, performance maybe?

