Date: Tue, 9 Jan 2018 00:02:52 +0100 From: Oliver Pinter <oliver.pinter@hardenedbsd.org> To: Gordon Tetlow <gordon@tetlows.org> Cc: freebsd-security@freebsd.org Subject: Re: Response to Meltdown and Spectre Message-ID: <CAPQ4ffvnVQQmwJ5_0tCN9gz7mXJTwoRGLUUkjC7E_uqwLq9Tmg@mail.gmail.com> In-Reply-To: <20180108175751.GH9701@gmail.com> References: <20180108175751.GH9701@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/8/18, Gordon Tetlow <gordon@tetlows.org> wrote: > By now, we're sure most everyone have heard of the Meltdown and Spectre > attacks. If not, head over to https://meltdownattack.com/ and get an > overview. Additional technical details are available from Google > Project Zero. > https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html > > The FreeBSD Security Team was notified of the issue in late December > and received a briefing under NDA with the original embargo date of > January 9th. Since we received relatively late notice of the issue, our > ability to provide fixes is delayed. > > Meltdown (CVE-2017-5754) > ~~~~~~~~~~~~~~~~~~~~~~~~ > In terms of priority, the first step is to mitigate against the Meltdown > attack (CVE-2017-5754, cited as variant 3 by Project Zero). Work for > this is ongoing, but due to the relatively large changes needed, this is > going to take a little while. We are currently targeting patches for > amd64 being dev complete this week with testing probably running into > next week. From there, we hope to give it a short bake time before > pushing it into the 11.1-RELEASE branch. Additional work will be > required to bring the mitigation to 10.3-RELEASE and 10.4-RELEASE. > > The code will be selectable via a tunable which will automatically turn > on for modern Intel processors and off for AMD processors (since they > are reportedly not vulnerable). Since the fix for Meltdown does incur a > performance hit for any transition between user space and kernel space, > this could be rather impactful depending on the workload. As such, the > tunable can also be overridden by the end-user if they are willing to > accept the risk. > > Initial work can be tracked at https://reviews.freebsd.org/D13797. > Please note this is a work in progress and some stuff is likely to be > broken. > > Spectre (CVE-2017-5753 and CVE-2017-5715) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > When it comes to the Spectre vulnerabilities, it is much harder to sort > these out. Variant 1 (CVE-2017-5753) is going to require some static > analysis to determine vulnerable use cases that will require barriers to > stop speculation from disclosing information it shouldn't. While we > haven't done the analysis to determine where we are vulnerable, the > number of cases here are supposed to be pretty small. Apparently there > have been some Coverity rules developed to help look for these, but we > are still evaluating what can be done here. > > The other half of Spectre, variant 2 (CVE-2017-5715) is a bit trickier > as it affects both normal processes and bhyve. There is a proposed patch > for LLVM (https://reviews.llvm.org/D41723) that introduces a concept > called 'retpoline' which mitigates this issue. We are likely to pull > this into HEAD and 11-STABLE once it hits the LLVM tree. Unfortunately, > the currently supported FreeBSD releases are using older versions of > LLVM for which we are not sure the LLVM project will produce patches. We > will be looking at the feasibility to backport these patches to these > earlier versions. > > There are CPU microcode fixes coming out when in concert with OS changes > would also help, but that's a bit down the road at the moment. > > > If anything significantly changes I will make additional posts to > clarify as the information becomes available. > > Best regards, > Gordon Tetlow > with security-officer hat on > Thanks for the information and for the hard work too!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPQ4ffvnVQQmwJ5_0tCN9gz7mXJTwoRGLUUkjC7E_uqwLq9Tmg>