info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Response to Meltdown and Spectre
0 views
Skip to first unread message
Gordon Tetlow
Jan 8, 2018, 12:58:25 PM1/8/18
to
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
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
Mike Tancsa
Jan 8, 2018, 1:15:50 PM1/8/18
to
Thanks very much for the updates!
---Mike
On 1/8/2018 12:57 PM, Gordon Tetlow wrote:
> By now, we're sure most everyone have heard of the Meltdown and Spectre--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"
---Mike
On 1/8/2018 12:57 PM, Gordon Tetlow wrote:
> By now, we're sure most everyone have heard of the Meltdown and Spectre--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"
Oliver Pinter
Jan 8, 2018, 6:03:26 PM1/8/18
to
Sujit K M
Jan 10, 2018, 6:56:34 AM1/10/18
to
Can't it be handled more generically.
--
-- Sujit K M
blog(http://kmsujit.blogspot.com/)
Peter Jeremy
Jan 11, 2018, 3:12:46 AM1/11/18
to
On 2018-Jan-10 16:46:01 +0530, Sujit K M <sjt...@gmail.com> wrote:
>>From my understanding what is happening is that an array overflow is happening.
>Can't it be handled more generically.
The array overflow in the example code is solely a convenient mechanism to
>>From my understanding what is happening is that an array overflow is happening.
>Can't it be handled more generically.
make C reference an arbitrary virtual address. An attacker could import
code from another system so it's not possible to mitigate the vulnerability
by (eg) implementing bounds checking in a compiler.
--
Peter Jeremy
Zahrir, Abderrahmane
Jan 12, 2018, 7:12:52 AM1/12/18
to
Hi Gordon,
Is it possible to include me in your distribution list so that I can get notified when the FreeBSD patch is available.
Regards, Dahman
Is it possible to include me in your distribution list so that I can get notified when the FreeBSD patch is available.
Regards, Dahman
Oliver Pinter
Jan 12, 2018, 7:15:37 AM1/12/18
to
The test patch is here: https://reviews.freebsd.org/D13797
On Friday, January 12, 2018, Zahrir, Abderrahmane <
On Friday, January 12, 2018, Zahrir, Abderrahmane <
Brett Glass
Jan 12, 2018, 1:18:33 PM1/12/18
to
All:
The fix in this patch appears to be unconditional.
I do a lot of work with embedded Intel Atom processors, which do
not implement speculative execution. (Only one of them even
implements limited out-of-order execution.) These systems aren't
terribly powerful by today's standards, and would suffer serious
performance impacts should the fix be turned on unnecessarily. Will
there be automatic detection of 32-bit Atoms (all of which are
definitely not susceptible) and 64-bit Atoms (all of which, except
for Avoton, are definitely not susceptible; Avoton might have some
very limited exposure due to out-of-order execution, but may also
not be vulnerable because the OOE is not speculative) to avoid
unnecessary performance impacts?
--Brett Glass
At 05:14 AM 1/12/2018, Oliver Pinter wrote:
>The test patch is here: https://reviews.freebsd.org/D13797
The fix in this patch appears to be unconditional.
I do a lot of work with embedded Intel Atom processors, which do
not implement speculative execution. (Only one of them even
implements limited out-of-order execution.) These systems aren't
terribly powerful by today's standards, and would suffer serious
performance impacts should the fix be turned on unnecessarily. Will
there be automatic detection of 32-bit Atoms (all of which are
definitely not susceptible) and 64-bit Atoms (all of which, except
for Avoton, are definitely not susceptible; Avoton might have some
very limited exposure due to out-of-order execution, but may also
not be vulnerable because the OOE is not speculative) to avoid
unnecessary performance impacts?
--Brett Glass
At 05:14 AM 1/12/2018, Oliver Pinter wrote:
>The test patch is here: https://reviews.freebsd.org/D13797
Mike Tancsa
Jan 12, 2018, 1:26:55 PM1/12/18
to
On 1/12/2018 1:07 PM, Brett Glass wrote:
> All:
>
> The fix in this patch appears to be unconditional.
The original email said
> All:
>
> The fix in this patch appears to be unconditional.
"The code will be selectable via a tunable which ..." Perhaps wait for
the final product.
---Mike
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
Brett Glass
Jan 12, 2018, 1:52:28 PM1/12/18
to
At 11:26 AM 1/12/2018, Mike Tancsa wrote:
>"The code will be selectable via a tunable which ..." Perhaps wait for
>the final product.
>
> ---Mike
Yes, I will be eagerly awaiting the final patch! In the meantime, I
>"The code will be selectable via a tunable which ..." Perhaps wait for
>the final product.
>
> ---Mike
have located some architectural information about the latest Intel
Atoms which indicates that they are not vulnerable even without the
patch. As the article at
https://www.anandtech.com/show/6936/intels-silvermont-architecture-revealed-getting-serious-about-mobile/2
from AnandTech (among other sources) explains, even the Atoms that
do OOE only do it on wholly register-based operations. This means
that operations which are accelerated and then conditionally
committed later cannot affect the cache. So, no processor from the
Atom family should be susceptible to Meltdown or Spectre, and the
extra security measures can safely be turned off automatically on
all of them. This would be a big help to those of us who would
otherwise have to recompile the kernel and/or set a special tunable.
--Brett Glass
Ed Maste
Jan 12, 2018, 9:59:57 PM1/12/18
to
On 12 January 2018 at 05:36, Zahrir, Abderrahmane
as a patch or SA for releases is by subscribing to
freebsd-security-notifications, which you can do at
https://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications
<Abderrahm...@ca.com> wrote:
> Hi Gordon,
>
> Is it possible to include me in your distribution list so that I can get notified when the FreeBSD patch is available.
The best way ensure you'll be notified when the changes are available
> Hi Gordon,
>
> Is it possible to include me in your distribution list so that I can get notified when the FreeBSD patch is available.
as a patch or SA for releases is by subscribing to
freebsd-security-notifications, which you can do at
https://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications
Konstantin Belousov
Jan 13, 2018, 11:10:59 AM1/13/18
to
On Mon, Jan 08, 2018 at 09:57:51AM -0800, Gordon Tetlow wrote:
> Meltdown (CVE-2017-5754)
> ~~~~~~~~~~~~~~~~~~~~~~~~
> Meltdown (CVE-2017-5754)
> ~~~~~~~~~~~~~~~~~~~~~~~~
> 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.
I consider this patch as ready for review now.
> Please note this is a work in progress and some stuff is likely to be
> broken.
Gordon Tetlow
Jan 16, 2018, 12:20:52 AM1/16/18
to
On Sat, Jan 13, 2018 at 8:10 AM, Konstantin Belousov
<kost...@gmail.com> wrote:
> On Mon, Jan 08, 2018 at 09:57:51AM -0800, Gordon Tetlow wrote:
>> Meltdown (CVE-2017-5754)
>> ~~~~~~~~~~~~~~~~~~~~~~~~
>> 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.
> I consider this patch as ready for review now.
Awesome! So, what's next? Do we have some testers we can solicit to
<kost...@gmail.com> wrote:
> On Mon, Jan 08, 2018 at 09:57:51AM -0800, Gordon Tetlow wrote:
>> Meltdown (CVE-2017-5754)
>> ~~~~~~~~~~~~~~~~~~~~~~~~
>> 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.
> I consider this patch as ready for review now.
beat on this? I believe des@ had a test case to try out? Based on
where we are, what needs to be done to get this into the tree?
Secondarily, what's needed to get this in shape for 10.3/10.4/11.1?
Gordon
Konstantin Belousov
Jan 16, 2018, 4:58:05 AM1/16/18
to
On Mon, Jan 15, 2018 at 09:20:24PM -0800, Gordon Tetlow wrote:
> On Sat, Jan 13, 2018 at 8:10 AM, Konstantin Belousov
> <kost...@gmail.com> wrote:
> > On Mon, Jan 08, 2018 at 09:57:51AM -0800, Gordon Tetlow wrote:
> >> Meltdown (CVE-2017-5754)
> >> ~~~~~~~~~~~~~~~~~~~~~~~~
> >> 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.
> > I consider this patch as ready for review now.
>
> Awesome! So, what's next? Do we have some testers we can solicit to
> beat on this? I believe des@ had a test case to try out? Based on
> where we are, what needs to be done to get this into the tree?
> Secondarily, what's needed to get this in shape for 10.3/10.4/11.1?
As expected, nothing happens WRT review.
> On Sat, Jan 13, 2018 at 8:10 AM, Konstantin Belousov
> <kost...@gmail.com> wrote:
> > On Mon, Jan 08, 2018 at 09:57:51AM -0800, Gordon Tetlow wrote:
> >> Meltdown (CVE-2017-5754)
> >> ~~~~~~~~~~~~~~~~~~~~~~~~
> >> 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.
> > I consider this patch as ready for review now.
>
> Awesome! So, what's next? Do we have some testers we can solicit to
> beat on this? I believe des@ had a test case to try out? Based on
> where we are, what needs to be done to get this into the tree?
> Secondarily, what's needed to get this in shape for 10.3/10.4/11.1?
Peter tested the patch, it seems to be fine. I put shims to allow i386
to compile. My idea is to flip the default to non-PTI and commit the
patch as is today.
Gordon Tetlow
Jan 16, 2018, 10:32:17 AM1/16/18
to
On Tue, Jan 16, 2018 at 1:57 AM, Konstantin Belousov
VM people out there).
> Peter tested the patch, it seems to be fine. I put shims to allow i386
> to compile. My idea is to flip the default to non-PTI and commit the
> patch as is today.
Is there a reason to leave the PTI off in CURRENT? I'd rather turn it
on and break some stuff to get the testing coverage than to leave it
off.
Gordon
<kost...@gmail.com> wrote:
> On Mon, Jan 15, 2018 at 09:20:24PM -0800, Gordon Tetlow wrote:
>> On Sat, Jan 13, 2018 at 8:10 AM, Konstantin Belousov
>> <kost...@gmail.com> wrote:
>> > On Mon, Jan 08, 2018 at 09:57:51AM -0800, Gordon Tetlow wrote:
>> >> Meltdown (CVE-2017-5754)
>> >> ~~~~~~~~~~~~~~~~~~~~~~~~
>> >> 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.
>> > I consider this patch as ready for review now.
>>
>> Awesome! So, what's next? Do we have some testers we can solicit to
>> beat on this? I believe des@ had a test case to try out? Based on
>> where we are, what needs to be done to get this into the tree?
>> Secondarily, what's needed to get this in shape for 10.3/10.4/11.1?
>
> As expected, nothing happens WRT review.
Who is a good person to review this? alc? (I can't think of any other
> On Mon, Jan 15, 2018 at 09:20:24PM -0800, Gordon Tetlow wrote:
>> On Sat, Jan 13, 2018 at 8:10 AM, Konstantin Belousov
>> <kost...@gmail.com> wrote:
>> > On Mon, Jan 08, 2018 at 09:57:51AM -0800, Gordon Tetlow wrote:
>> >> Meltdown (CVE-2017-5754)
>> >> ~~~~~~~~~~~~~~~~~~~~~~~~
>> >> 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.
>> > I consider this patch as ready for review now.
>>
>> Awesome! So, what's next? Do we have some testers we can solicit to
>> beat on this? I believe des@ had a test case to try out? Based on
>> where we are, what needs to be done to get this into the tree?
>> Secondarily, what's needed to get this in shape for 10.3/10.4/11.1?
>
> As expected, nothing happens WRT review.
VM people out there).
> Peter tested the patch, it seems to be fine. I put shims to allow i386
> to compile. My idea is to flip the default to non-PTI and commit the
> patch as is today.
on and break some stuff to get the testing coverage than to leave it
off.
Gordon
Konstantin Belousov
Jan 16, 2018, 10:55:04 AM1/16/18
to
On Tue, Jan 16, 2018 at 07:31:43AM -0800, Gordon Tetlow wrote:
> On Tue, Jan 16, 2018 at 1:57 AM, Konstantin Belousov
> <kost...@gmail.com> wrote:
> > On Mon, Jan 15, 2018 at 09:20:24PM -0800, Gordon Tetlow wrote:
> >> On Sat, Jan 13, 2018 at 8:10 AM, Konstantin Belousov
> >> <kost...@gmail.com> wrote:
> >> > On Mon, Jan 08, 2018 at 09:57:51AM -0800, Gordon Tetlow wrote:
> >> >> Meltdown (CVE-2017-5754)
> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~
> >> >> 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.
> >> > I consider this patch as ready for review now.
> >>
> >> Awesome! So, what's next? Do we have some testers we can solicit to
> >> beat on this? I believe des@ had a test case to try out? Based on
> >> where we are, what needs to be done to get this into the tree?
> >> Secondarily, what's needed to get this in shape for 10.3/10.4/11.1?
> >
> > As expected, nothing happens WRT review.
>
> Who is a good person to review this? alc? (I can't think of any other
> VM people out there).
amd64 pmap is only smaller part of the patch, the trampoline code is IMO
> On Tue, Jan 16, 2018 at 1:57 AM, Konstantin Belousov
> <kost...@gmail.com> wrote:
> > On Mon, Jan 15, 2018 at 09:20:24PM -0800, Gordon Tetlow wrote:
> >> On Sat, Jan 13, 2018 at 8:10 AM, Konstantin Belousov
> >> <kost...@gmail.com> wrote:
> >> > On Mon, Jan 08, 2018 at 09:57:51AM -0800, Gordon Tetlow wrote:
> >> >> Meltdown (CVE-2017-5754)
> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~
> >> >> 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.
> >> > I consider this patch as ready for review now.
> >>
> >> Awesome! So, what's next? Do we have some testers we can solicit to
> >> beat on this? I believe des@ had a test case to try out? Based on
> >> where we are, what needs to be done to get this into the tree?
> >> Secondarily, what's needed to get this in shape for 10.3/10.4/11.1?
> >
> > As expected, nothing happens WRT review.
>
> Who is a good person to review this? alc? (I can't think of any other
> VM people out there).
both more risky and more complicated.
>
> > Peter tested the patch, it seems to be fine. I put shims to allow i386
> > to compile. My idea is to flip the default to non-PTI and commit the
> > patch as is today.
>
> Is there a reason to leave the PTI off in CURRENT? I'd rather turn it
> on and break some stuff to get the testing coverage than to leave it
> off.
uncertainity about several CPU families, because we still do not have
have a test tool, and because there are some bits broken more than in
non-pti kernel.
0 new messages