https://meltdownattack.com/

[bartjsmit]

Amazon has already patched its cloud https://www.neowin.net/news/amazon-aws-customers-see-slowdown-after-meltdown-patch

Bart...

[phoenix]

Amazon has already patched its cloud https://www.neowin.net/news/amazon-aws-customers-see-slowdown-after-meltdown-patch

Bart...

So have google: https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html

There's also a patch from VMware for  ESXi systems: https://kb.vmware.com/s/article/2151099

[xinnan]

I believe the word that is being tossed around is "mitigation". 

I think we are stuck with Spectre until the next slew of chips are fabricated and the problem is eliminated at the chip level. 

[opnsense_user12123]

Statement of freebsd.org (admin):

About the Meltdown and Spectre attacks: FreeBSD was made aware of the problems in late December 2017. We're working with CPU vendors and the published papers on these attacks to mitigate them on FreeBSD. Due to the fundamental nature of the attacks, no estimate is yet available for the publication date of patches.

https://forums.freebsd.org/threads/63985/#post-371432

[werner]

I'm not really convinced attacks are only possible through local access, what about hypervisors. It seems even attacks from one vm to fetch another vm's data are possible. VMWare has patches but those work together with the OS patches. If that's the case any vm running on the same hypervisor host could be used to attack.

That's the type I'm most worried about since we use OPNSense on a vCloud environment where of course other customers have vm's.

[xinnan]

Totally agree judging by what I've read, however, VM is a local attack.  It is code running on the machine.  However, If you own the machine and you are the only one running VMs on the machine I think you are in the clear. 

I don't think this really impacts most of us as far as opnsense is concerned unless we are running VMs in the cloud and we don't know what the neighbors are up to.

[franco]

There are two major areas where these attacks hurt *badly*:

* End users that browse the web, read emails, run applications and updates
* All VM deployments where end-users are deployed or unsupervised code is ran (the "cloud provider") because they make the attack local to the host, even if "sandboxed" in the guest

The best attack vector is to simply *buy* a cheap VM and start scraping the host for secrets in other VMs on it.


Cheers,
Franco

[xinnan]

The sad thing is that my box's processors are dated enough to be immune to these attacks but I bet the patches slow down my boxes anyway.  Its an epic mess.  Maybe some good will come of this and the x86 architecture will get a badly needed revamp. 

[chemlud]

@xinnan: I heard the only processors "safe by age" originate from before 1995. What am I missing?

[xinnan]

Generally true, but some of the Atom chips before 2013 and AMD chips as well are immune.  I'm talking about spectre.  Meltdown can be addressed with OS updates if I'm not misled.

I'm pretty sure that neither my Athlon X2 nor my D2700 are at risk.  However, every laptop and desktop and small server I have are.  Those are all fairly modern Intel CPUs and I do not believe intel when they say they have a fix for this.  I think they are just grasping at straws trying to prevent further devaluation.

[chemlud]

...yeah! I have an older AMD CPU machine too! :-D ...and my little farm of RaspberryPis--- :-)

[franco]

Hot off the press...

https://lists.freebsd.org/pipermail/freebsd-security/2018-January/009719.html


Cheers,
Franco

[xinnan]

Security guys are talking a big game but I feel like this is a whole new game they are not prepared for.
BTW - The firefox and google chrome patches seem to make things both slow and memory hungry if you ask me. 

I'm going to need more tinfoil...

[lattera]

I thought I'd update everyone with the progress I'm making in addressing Spectre in HardenedBSD.

• I've created a feature branch called hardened/current/retpoline in HardenedBSD's Playground repo (https://github.com/HardenedBSD/hardenedBSD-playground). This branch is based on HardenedBSD 12-CURRENT.
• I've imported FreeBSD's projects/clang600-import branch and performed some fixups.
• I merged in llvm's retpoline patch and integrated it into the build framework and enabled it by default on amd64 (the retpoline patch only addresses amd64).
• I updated my HardenedBSD laptop with the this retpoline branch.
• I'm now typing this from the same laptop with world + kernel build fully with retpoline.

What's left to do:

• Benchmarking
• Enable and build binary binary updates for the retpoline feature branch for wider testing.
• Further down the road: experimental package builds.

Note that this work is only applicable to HardenedBSD 12-CURRENT/amd64. We're still in the very early stages. Once retpoline makes it officially to llvm 6.0, it will be backported to prior versions. Applying this work to OPNsense will take some time. The work I'm doing is simply research. Getting my feet wet.

So, great progress is being made. FreeBSD's PTI patch is coming along as well.

Screenshot here: https://photos.app.goo.gl/nemutoL6zYceaVH12

[lattera]

Another update. In the past few days:

• Merged in Kostik's PTI patch into the retpoline feature branch in HardenedBSD
• Updated the retpoline patch
• Enabled retpoline for the entire HardenedBSD ports tree for users of the retpoline feature branch
• Migrated four systems over to the retpoline feature branch
• Published numerous binary updates
• Completed an experimental package build

Everything's looking good so far. Not a single issue with retpoline, even when building over 29,400 packages. I've had a few issues with PTI, but those have since been resolved. I haven't noticed any real performance impact of retpoline.

The PTI patch does come with a rather large performance hit, especially since it doesn't currently support PCID. (I've been assured by upstream FreeBSD PCID support will follow.) Kostik's PTI patch should land in upstream FreeBSD in a "default disabled" state later today.

I plan to merge into HardenedBSD 12-CURRENT the retpoline patch within the next week or two. Note that retpoline requires lld as the default linker. HardenedBSD enabled lld as the default linker for 12-CURRENT/amd64, but GNU ld remains the default in 11-STABLE/amd64.

The soon-to-be-released OPNsense 18.1 uses FreeBSD 11.1-RELEASE as its upstream, with a select few crucial HardenedBSD bits mixed in. In OPNsense, GNU ld remains the default. Thus, retpoline as currently implemented will not be applicable to OPNsense.