
Meltdown and Spectre Linux kernel status - dankohn1
http://kroah.com/log/blog/2018/01/06/meltdown-status/
======
amluto
One thing I'll reiterate: as Greg mentioned, the backports to kernels prior to
4.14 are derived from a rather old KAISER version. They do not match what 4.14
and 4.15 do. This has several consequences.

1\. They will have bugs. There's a reason PTI was heavily modified from the
old KAISER code. They will also tend to diverge from upstream just because the
code is so different. This means that the next time low-level x86 changes need
to be backported, it'll be a huge mess.

2\. There is only minimal upstream support. I, for example, am already largely
ignoring two bugs in the backports that aren't in the upstream version. Why?
Because I have no affiliation with a distro using an old kernel.

3\. Contrary to its marketing, KAISER does not effectively mitigate the old
kASLR leaks. PTI very nearly does, and I intend to improve it further once I
find some time to do so. I doubt those improvements will get backported to
pre-4.14 kernels.

4\. At least some versions of "KAISER", on meltdown-affected hardware, expose
the kernel stack to userspace. If that's not usable for rooting a box, I'll
eat my hat. KPTI doesn't have this problem.

If you can put pressure on your organization or suppliers to update to 4.14 or
better, please do so. Red Hat, especially, should seriously consider moving to
4.14 for RHEL 8.

~~~
lima
As far as I can tell, the RHEL/CentOS kernel has mitigations not only for
Meltdown but also Spectre (using the new MSRs).

Am I right in assuming that Red Hat built their own mitigations, independently
from upstream?

~~~
unixsurfer
The patches on RedHat 7.4 have impact on performance and capacity for a Load
Balancer type of workload, see
[https://www.spinics.net/lists/stable/msg209193.html](https://www.spinics.net/lists/stable/msg209193.html)

------
alibert
FYI, Red Hat (and CentOS) already have updated kernels with mitigation.

And that made me asking how Red Hat (and the free derivative CentOS) could
have already patched their current kernel (on Jan 4th) while the patch was
still being discussed on kernel ML the _same day_?

I don't see how they could come up with new kernel with mitigation for the
three variants, excellent KB articles on the CVEs, tunables flag, preliminary
performance test, etc. without having already patches implemented and tested
for some time.

Do they have internal kernel devs? And so, do Redhat have another
implementation?

(This is my first comment on HN, I hope I'm following adequately the
guidelines)

~~~
kashyapc
There's such a thing called: 'embargo period', wherein CVEs are (in most
cases) responsibly disclosed to various parties---including several Linux
distributions---much ahead than the general public, to coordinate security
errata.

So you can be assured that Red Hat coordinates with upstream. It also has a
serious "Upstream First" policy (with sensible exceptions, of course).

As to whether Red Hat has kernel developers, of course it does. :-) Much of
Red Hat's popularly began as a _Linux_ distribution. If you're curious, the
LWN publishes statistics about who contributes to the Linux kernel, and the
most recent one is for the 4.11 development cycle --
[https://lwn.net/Articles/720336/](https://lwn.net/Articles/720336/)

(Disclosure: /me is a Red Hatter.)

~~~
Gracana
I really dislike the term "responsible disclosure" in this context. I might
consider it responsible to notify a software vendor about a vulnerability in
their software so they have a chance to issue a fix to their customers before
the rest of the world finds out. But this situation is different. These
vulnerabilities affect everyone, and only a special few were allowed to
prepare in advance. That's just _preferential_ disclosure.

~~~
cesarb
> These vulnerabilities affect everyone, and only a special few were allowed
> to prepare in advance. That's just preferential disclosure.

In this particular case, most of the fix had to be done in the operating
system (the new microcode only enabled extra functionality needed by part of
the operating system fixes), so it makes sense that operating system
developers were allowed (and required) to prepare in advance. The three most
relevant operating systems are Windows, OSX, and Linux; for Linux, one of the
most important distributors is Red Hat. That gives two of the groups which
were notified in advance: hardware (Intel, AMD, ARM) and operating systems
(Microsoft, Apple, Red Hat, a few others).

~~~
smarx007
Ubuntu and BSD still have no fixes. It indeed seems like a preferrential
disclosure. Plus no 2nd-tier cloud providers like DO were notified.

~~~
macdice
It will be pretty unfortunate if it turns out that the projects that maintain
a kernel (FreeBSD, various others) only received notification at Christmas,
while various Linux distros (who have to deal with packaging, release, QA but
not developing their own kernel patch since that comes from upstream) got a
long warning period. It seems that way... Looking forward to reading about how
this played out when the dust settles.

~~~
gkya
There was a post to OpenBSD- tech list telling no BSDs were told anything. And
a blog post from Canonical says that the patch will be available 9th January
(IIRC).

~~~
isostatic
OpenBSD didn't respect the embargo a few months ago with the wifi issue, no
surprise that they weren't told about this up front.

------
codys
> As for how this was all handled by the companies involved, well this could
> be described as a textbook example of how NOT to interact with the Linux
> kernel community properly. The people and companies involved know what
> happened, and I’m sure it will all come out eventually

I'm looking forward to that story.

~~~
pkilgore
I'll eat my hat if it isn't some version of "here is a giant patch set we
never worked through the chain nor asked about at all please make it your
problem to mainline it immediately, followed by, well, a good old fashioned
LKML go fsck yourself."

------
Santosh83
What I'd like to know is how effective are these OS updates (both Linux and
Windows) without the associated firmware updates through microcode or
BIOS/UEFI flashing. My system is a few years old and I don't expect the OEM to
release BIOS/UEFI updates for this model.

Will the OS/microcode update still at least partially protect me or will I
have to be super-paranoid about apps and javascript for the remainder of this
machine's life?

BTW, my machine is just a normal desktop/laptop, so no server stuff running or
expected.

~~~
JdeBP
The microcode updates that people have been mentioning are not updates to your
motherboard's firmware, EFI or otherwise. They are updates to the code that
runs _inside your central processor chip_ , the so-called _microcode_ , that
does the work of understanding and enacting processor instructions (in all
programs, from the programs in your firmware to the programs that you download
and run from the WWW).

Firmware updates are largely irrelevant to this issue, only being involved in
the sense that one way to perform _microcode_ updates is for your machine's
firmware to upload the new microcode image file. But that is just _one_ way
for that to be done; your operating system can do it, too.

* [http://inertiawar.com/microcode/](http://inertiawar.com/microcode/)

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

* [https://newsroom.intel.com/wp-content/uploads/sites/11/2018/...](https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf) ([https://news.ycombinator.com/item?id=16079910](https://news.ycombinator.com/item?id=16079910))

~~~
davidjade
Windows, at least for right now, does not seem to be updating CPU microcode
during boot. If you run the PowerShell Get-SpeculationControl script that
gives you the status of the updates it states that the CVE-2017-5715 fix
requires hardware support. If you don't have it you are told to get a BIOS
update from your OEM. WIthout it, the status for CVE-2017-5715 is listed as
not enabled due to missing hardware support.

Of all of my computers only one has been issued a BIOS update so far. I ran
the PowerShell script before and after installing the BIOS. Installing the
BIOS flipped the status of the fix for CVE-2017-5715 to on.

I also ran the free HwInfo utility that will show the microcode revision
before and after installing the Windows update and before and after installing
the BIOS. It only ever changed with the BIOS update.

I hope this changes and Windows does start updating CPU microcode. I also have
a few older motherboard's that aren't likely to ever see a BIOS update again.

~~~
newman314
This appears to be my experience too. I'm checking a few VMs and they are
showing as missing hw support.

Do note that Microsoft appears to have updated their doc in the last day or
so. They are now saying that three registry settings need to be set (instead
of 2 previously).

    
    
      reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f
      reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f
      reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization" /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d "1.0" /f
    

Some quick Googling seems to indicate that Windows has the ability to update
microcode.

[http://forum.notebookreview.com/threads/how-to-update-
microc...](http://forum.notebookreview.com/threads/how-to-update-microcode-
from-windows.787152/)

Maybe this will happen with a later update from Microsoft as I'm doubtful that
BIOS updates will happen with at least one of my systems.

~~~
cyann
MinVmVersionForCpuBasedMitigations is for VM/Hyper-V:
[https://docs.microsoft.com/en-us/virtualization/hyper-v-
on-w...](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-
windows/CVE-2017-5715-and-hyper-v-vms)

------
antaviana
I use AWS instances (multi-tenant). I understand that by now AWS hypervisors
have been patched.

Does that fully protect my unpatched AWS instances from this CPU-level issues?

If not, is there any way to protect my AWS instance from a rogue unpatched
attacker instance running on the same hypervisor?

In other words, with the current CPUs deployed at AWS, will it be possible for
an attacker to simply launch an unpatched instance to steal data from other
instances (patched or not) running on the same AWS hypervisor?

I hope not, because the cloud multi-tenant model would be effectively dead
until AWS hosts with unaffected CPUs are available.

~~~
tptacek
No. The "master" software fix to Meltdown keeps userland and the kernel from
trivially sharing kernel memory pages. If your guest kernel doesn't have this
fix applied, then your guest userland shares pages with your guest kernel, and
guest processes can dump kernel memory.

~~~
tedunangst
In theory it should be possible for a hyper visor to retrofit a fix into a
guest, but it's messy and I doubt anyone will ever do it. Could be fun though.

Quick sketch: disable EPT and go back to shadow paging. Maintain a third page
table with any kernel pages unmapped. Invisibly swap between on syscalls.

~~~
wolf550e
This sounds really slow to me. What is the overhead of "disable EPT and go
back to shadow paging", or what was the performance win of EPT?

------
blockoperation
What bothers me is the lack of confirmation on the microcode updates (other
than 'soon') – apparently they're out there[1], but Intel's own package has
yet to be updated[2]. The 20171215 update carried by some distros only seems
to cover HSX/BDX/SKX, so does that mean regular HSW/BDW/SKL users are screwed,
are they covered by the 20171117 update, or are the new microcodes simply not
ready for all models yet?

Of course, the microcode updates are meaningless without the corresponding
kernel patches, but apparently only RHEL and SLES were deemed worthy of
receiving those ahead of time, having already rolled them out while Linus and
co are left scrambling to integrate the IBRS and retpoline code dumps after
the fact.

[1]
[https://tracker.debian.org/news/899110](https://tracker.debian.org/news/899110)
[2] [https://downloadcenter.intel.com/download/27337/Linux-
Proces...](https://downloadcenter.intel.com/download/27337/Linux-Processor-
Microcode-Data-File)

~~~
blockoperation
Just to add to that, it looks like some manufacturers have already pushed out
the new microcode alongside the recent ME fixes.

I flashed my Skylake laptop a few days ago, and now I'm on microcode rev 0xc2
(versus 0xba in the latest Intel tarball). CPUID output suggests IBRS support
(according to [1]).

[1]
[https://patchwork.kernel.org/patch/10147547/](https://patchwork.kernel.org/patch/10147547/)

------
davidw
Reading between the lines, it seems this is a pretty colossal fuckup by Intel;
both in terms of the bug but especially how it was handled.

~~~
JdeBP
You do not need to read in between the lines to learn that; several
commentators have come right out and said it.

* [http://lists.dragonflybsd.org/pipermail/users/2018-January/3...](http://lists.dragonflybsd.org/pipermail/users/2018-January/313758.html) ([https://news.ycombinator.com/item?id=16084641](https://news.ycombinator.com/item?id=16084641))

* [https://medium.com/@frankycaron/this-week-in-words-the-langu...](https://medium.com/@frankycaron/this-week-in-words-the-language-of-meltdown-and-spectre-126bf109e5c5) ([https://news.ycombinator.com/item?id=16075588](https://news.ycombinator.com/item?id=16075588))

* [http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect...](http://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/)

One of them you might have expected to use the word "fuck", but actually did
not. (-:

* [https://lkml.org/lkml/2018/1/3/797](https://lkml.org/lkml/2018/1/3/797) ([https://news.ycombinator.com/item?id=16066968](https://news.ycombinator.com/item?id=16066968))

In part, this was down to the cat being let out of the bag early.

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

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

~~~
arianvanp
If those 4 extra days of embargo would not have caused a total PR disasters on
Intel's side will eat my socks. This wouldn't have become any better given
another week of time.

~~~
fragmede
The fact that Intel is rumored to have know about this since _June_ lends
credence to your belief, however if that week would have let OS vendors have
updates ready, and cloud providers already patched, then it _would_ be less of
a disaster. There's a certain amount of flailing about when details are
released earlier than expected, and vendors don't have a answers or
instructions prepared.

------
_nalply
From my cursory reading I understand it is a cleverly orchestrated timing
attack.

In other words, if something would need 500 picoseconds you have bit 1, if it
is 250 picoseconds instead it is bit 0 (numbers pulled out of thin air).

This is made possible because processors execute the read speculatively even
if it is actually forbidden. This read causes a cache hit. Of course the read
is never brought into effect because first it is forbidden and second it is in
a branch which will never be executed. At the time of the speculative read the
CPU seems not to have enough information to know not to execute that read.
Even speculatively.

And that speculative read has a side effect on the cache which is measured by
the exploit.

Of course the read is never made visible to the process because later the CPU
knows not to bring it into effect. However then it is too late: there is
measurable difference in caching times.

Did I understand the way of the attack correctly?

~~~
JdeBP
Timing the L1 cache response for speculatively fetched data that one could not
normally access is _just one_ of the problems. It's the one that it is easiest
to explain, and it's also the one that the few operating system writers who
were told about this tackled first. Hence it is the one that is getting the
focus in many discussions.

* [https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne...](https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/) ([https://news.ycombinator.com/item?id=16080002](https://news.ycombinator.com/item?id=16080002))

* [https://dev.to/isaacandsuch/how-meltdown-works-28j2](https://dev.to/isaacandsuch/how-meltdown-works-28j2) ([https://news.ycombinator.com/item?id=16085592](https://news.ycombinator.com/item?id=16085592))

One of the _other_ problems is tricking the branch predictor into
speculatively jumping into code of one's choosing.

* [https://newsroom.intel.com/wp-content/uploads/sites/11/2018/...](https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf) ([https://news.ycombinator.com/item?id=16079910](https://news.ycombinator.com/item?id=16079910))

~~~
jancsika
> One of the other problems is tricking the branch predictor into
> speculatively jumping into code of one's choosing.

But to read the data one still must use timing attacks, no?

------
weinzierl
> If you rely on any other kernel tree other than 4.4, 4.9, or 4.14 right now,
> and you do not have a distribution supporting you, you are out of luck.

So, if you are running a (still supported) Debian Jessie a simple _apt-get
upgrade_ isn't gonna cut it:-(

~~~
JdeBP
As the Debian announcement says:

* [https://lists.debian.org/debian-security-announce/2018/msg00...](https://lists.debian.org/debian-security-announce/2018/msg00000.html) ([https://news.ycombinator.com/item?id=16076175](https://news.ycombinator.com/item?id=16076175))

It's not the only operating system where the process is slightly more complex
than a kernel update. Windows NT updates require the coöperation of other
softwares on one's machine. (-:

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

~~~
weinzierl
I'm not pointing at Debian. I think it is even possible to run Jessie with a
current kernel, (which is quite cool) but I haven't tried it. I just upgraded
all machines to Stretch and called it a day.

I just did the _apt-get update; apt-get upgrade_ dance in a hurry yesterday
and thought I might be good. My post was more a reminder to everyone not be
lulled into a false sense of security...

~~~
wazoox
I run (many) jessie systems with 4.9 kernels (still haven't made a 4.14
configuration). No problem at all.

~~~
pas
You might want to bite the bullet and upgrade from 4.9, because the patches
for 4.9 are not so rock solid:
[https://news.ycombinator.com/item?id=16087736](https://news.ycombinator.com/item?id=16087736)

------
lisper
Someone please correct me if I'm wrong, but both spectre and meltdown seem to
me to be local root exploits, not remote vulns. They can be used to break out
of (say) a VM into the host hypervisor, and thence into other VMs running on
the same hardware, but cannot be used to break into a machine from outside its
hardware perimeter. Is that right?

~~~
Xylakant
Essentially yes, the exploits require code running on the machine that’s
attacked. However, for example JavaScript runs on the local machine and is a
demonstrated attack vector.

It’s also strictly speaking not a privilege escalation, it’s “see things
you’re not supposed to.”, such as all sorts of secrets. The attacker does not
gain any write or execution privileges, though.

~~~
lisper
> JavaScript ... is a demonstrated attack vector

OMG, I didn't know that. Thanks.

~~~
craigyk
It also consumes lots of CPU to scan memory this way, so just be on the
lookout for webpages consuming lots of unexpected CPU.

~~~
nxc18
In the age of fancy JavaScript webapps, this seems laughable. 2 or 3 tabs in
Chrome is enough to turn my laptop into a space heater.

------
fermienrico
With so much going on - is there a way in linux to know whether my system is
patched or not?

Similar to the powershell script for Windows?

~~~
frazar0
A number of ways are listed here [1]

1\. With dmesg

dmesg -wH | grep 'page tables isolation'

2\. With /proc/cpuinfo

grep cpu_insecure /proc/cpuinfo && echo "Patched" || echo "Unpatched!"

[1] [https://askubuntu.com/questions/992137/how-to-check-that-
kpt...](https://askubuntu.com/questions/992137/how-to-check-that-kpti-is-
enabled-on-my-ubuntu)

~~~
fermienrico
Thanks. So apparently, my system:

    
    
      Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-104-generic x86_64)
    

is unpatched! Is it because of LTS version? Most servers run this including
mine.

~~~
nebulous1
Ubuntu say they will release a patch on or before the 9th of January.

They got caught out by the embargo being ended early.

------
gphreak
Based on the remarks I'm wondering if there's a distribution out there that is
similar to Ubuntu LTS but only uses LTS kernels.

I'm on CentOS right now and love it, but from what I've understand so far it
would be preferable to be on a newer kernel.

I was planning to look at Ubuntu LTS and while they do have updated kernels
available they seem to ignore LTS:
[https://wiki.ubuntu.com/Kernel/LTSEnablementStack](https://wiki.ubuntu.com/Kernel/LTSEnablementStack)

Also, 18.04 will be based on 4.15 which doesn't make sense to me.

Debian stable maybe?

EDIT: I know I can install updated kernels but I'd rather stick with what a
core distribution provides if possible

~~~
dustinkirkland
Actually, Ubuntu created the term "LTS" in 2006, for Long Term Support
releases. Greg started using the term himself just a couple of years ago.

~~~
gphreak
Re-reading my post it does sound a bit confusing.

What I meant is: Ubuntu LTS seems to not give a damn if the kernel they use is
also an LTS release.

Examples would be: 14.04, 16.04 HWE kernels, 18.04 (currently planned to be
4.15).

------
api
We applies it to the bare metal DB servers for my.zerotier.com and there is
definitely a detectable increase in IO cost. Reducing syscall overhead is
going to become even more important.

------
bertolo1988
What about Ubuntu users? Is the update our already?

~~~
cheeseprocedure
Not yet - keep an eye on their wiki page for Meltdown/Spectre:

[https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...](https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown)

------
kazinator
I've been thinking about some of this. A possible design to prevent some of
these issues would be to read all protected memory, in speculative execution
paths, as dummy all-zero bits value, and not put anything into the cache. I.e.
no actual access takes place to any protected area and no breadcrumbs are left
in any CPU storage such as a cache. (Then if that path is actually taken,
generate the exception).

The whole problem is that the kernel/user protection is just a sham that is
not being taken seriously by the CPU implementation. It allows access to take
place without a proper mode change. Basically the whole fetch-decode-execute
machinery (all of its pipelines, caches, registers and other areeas) should be
regarded as untrusted and prevented from accessing or storing anything
unauthorized according to the current security state of the CPU.

~~~
dingo_bat
The kernel/user enforcement by the CPU is a sham (kinda) in Intel CPUs when
the data you want to access is in L1 (people are guessing). This is only for
the meltdown issue.

Spectre doesn't care about kernel/user at all. So even other CPUs are
susceptible. Every CPU that speculates is vulnerable in theory.

------
throhaway2018
Is the clock still ticking on Joyent.com patching their public cloud (illumos,
SmartOS)?

[https://help.joyent.com/hc/en-
us/articles/115015938847-Secur...](https://help.joyent.com/hc/en-
us/articles/115015938847-Security-Advisory-Intel-Security-Findings)

------
Changu

        If your Linux systems are running a normal Linux
        distribution, go update your kernel. They should
        all have the updates in them already.
    

I use Linux Mint and have not seen any recent kernel updates.

Which kernel version is considered safe?

~~~
jcastro
> I use Linux Mint and have not seen any recent kernel updates.

If you're not aware Linux Mint turns off kernel security updates _off_, you
need to check by hand.

~~~
BuckRogers
I always preferred Mint for desktop Linux. I knew they had a poor security
record due to their HTTP downloads at one time, but no kernel security updates
is news to me.

If you must use desktop Linux, I guess I'll be recommending Ubuntu from now
on. In my testing Mint and Ubuntu both work pretty well out of the box on lots
of different hardware configurations unlike other distros. But learning this
really tips the scale, Ubuntu or bust.

~~~
yemich
A great advantage of linux is allowing the end user choice of distribution and
desktop environment to find their specific needs. Unfortunately, not all
choices are good. I wish Mint would go away.

------
nvus
A good way Intel could say sorry is to have a new generation hardened cpus at
a good price.

~~~
pas
Even offering ECC for mere mortals would be a good start. Of course with the
option to disable as much of the ME as possible.

------
danjoc
So if you're running a ARM64 chromebook, the answer appears to be: get fukt.

"For the 4.4 and 4.9 LTS kernels, odds are these patches will never get merged
into them, due to the large number of prerequisite patches required. All of
those prerequisite patches have been long merged and tested in the android-
common kernels, so I think it is a better idea to just rely on those kernel
branches instead of the LTS release for ARM systems at this point in time."

Great. Into the trash it goes.

------
ComputerGuru
This just reminded me: when will Ubuntu (and Debian?) fix apt’s broken kernel
update process? I have never seen a kernel update - security or otherwise -
installed via a normal “apt update; apt upgrade” on any of our machines, it’s
always “the following updates have been held back” and then it’s time to
manually use dpkg to install the relevant updates.

~~~
koenigdavidmj
“apt full-upgrade” will upgrade everything. It may also remove packages to fix
higher priority dependencies, though I’ve never seen this happen in real life.

~~~
ihattendorf
Happened to me yesterday with my Proxmox host. It wanted to install firmware-
linux-free, which conflicted with pve-firmware. It decided it wanted to remove
pve-firmware which would also completely remove proxmox-ve... Had to upgrade
with --no-recommends.

------
proginthebox
The website serves JS and does not serve it over https, and discusses Spectre
bug and how to patch it. I know he is the second most important guy on linux,
but the irony.

~~~
xroche
And you probably know much better than the second most important guy on linux
what security means on the Internet: securing some javascript script on a
random blog.

~~~
axiomofquality
HTTPS should be expected by now - ISPs keep messing with my unencrypted
traffic.

~~~
lisper
Then you should get yourself a different ISP or a VPN.

~~~
AaronFriel
This is an extremely easy thing to say for many people around the world.

But for a large number of people - Americans, folks in countries with
monopolies or state manipulation of internet traffic - it is not.

Not everyone has a different ISP to choose from. VPNs are a risky proposition
and can significantly reduce bandwidth and increase latency.

~~~
sigmar
Anyone that thinks ISPs don't mess with traffic, should check out this malware
research

[https://www.virusbulletin.com/conference/vb2017/abstracts/la...](https://www.virusbulletin.com/conference/vb2017/abstracts/last-
minute-paper-finfisher-new-techniques-and-infection-vectors-revealed/)

------
fizixer
I'm out of the loop but I heard it's the white hat hackers who exposed the
flaw (probably they were at Google?).

Is the exposition carefully publicized so the flaw is not exploitable by
malicious hackers?

Or does Project Zero expose everything, and a malicious hacker can read it and
create code that spreads over the internet to harm computers?

I hope it's not the second case because that should cause global panic.

~~~
bonzini
It's closer to the second, but:

1) the vulnerability is local, not directly tied to spreading as malware (but
these days placing JavaScript in an ad is easier and possibly more effective
than a virus...)

2) there is no such thing as "exposition carefully publicized so the flaw is
not exploitable by malicious hackers". Just assume that black hats are as
smart as white hats or smarter.

~~~
fizixer
> 2) there is no such thing as "exposition carefully publicized so the flaw is
> not exploitable by malicious hackers". Just assume that black hats are as
> smart as white hats or smarter.

You're missing the point. Not doubting the smartness of black hats, white hats
likely took their time to discover the flaw. If you make the details public in
a controlled manner and then announce the fixes shortly after, you essentially
did not give black hats enough time to fill the missing pieces of the public
announcement.

For instance, in the extreme case, the statement "we have discovered a flaw at
the hardware/CPU level in such and such chips, and we call it meltdown and
spectre", it's pretty obvious the black hats would have no clue what it is.
(They may have already discovered it on their own, and may have named the
flaws something completely different. Even then they wouldn't know if white-
hats discovered what they discovered.)

~~~
ghaff
For one thing, the fixes are up in the Linux kernel for anyone to see.

