FreeBSD Security Advisory FreeBSD-SA-18:03.speculative_execution

[FreeBSD Security Advisories]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

=============================================================================
FreeBSD-SA-18:03.speculative_execution Security Advisory
The FreeBSD Project

Topic: Speculative Execution Vulnerabilities

Category: core
Module: kernel
Announced: 2018-03-14
Credits: Jann Horn (Google Project Zero); Werner Haas, Thomas
Prescher (Cyberus Technology); Daniel Gruss, Moritz Lipp,
Stefan Mangard, Michael Schwarz (Graz University of
Technology); Paul Kocher; Daniel Genkin (University of
Pennsylvania and University of Maryland), Mike Hamburg
(Rambus); Yuval Yarom (University of Adelaide and Data6)
Affects: All supported versions of FreeBSD.
Corrected: 2018-02-17 18:00:01 UTC (stable/11, 11.1-STABLE)
2018-03-14 04:00:00 UTC (releng/11.1, 11.1-RELEASE-p8)
CVE Name: CVE-2017-5715, CVE-2017-5754

Special Note: Speculative execution vulnerability mitigation is a work
in progress. This advisory addresses the most significant
issues for FreeBSD 11.1 on amd64 CPUs. We expect to update
this advisory to include 10.x for amd64 CPUs. Future FreeBSD
releases will address this issue on i386 and other CPUs.
freebsd-update will include changes on i386 as part of this
update due to common code changes shared between amd64 and
i386, however it contains no functional changes for i386 (in
particular, it does not mitigate the issue on i386).

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:https://security.FreeBSD.org/>.

I. Background

Many modern processors have implementation issues that allow unprivileged
attackers to bypass user-kernel or inter-process memory access restrictions
by exploiting speculative execution and shared resources (for example,
caches).

II. Problem Description

A number of issues relating to speculative execution were found last year
and publicly announced January 3rd. Two of these, known as Meltdown and
Spectre V2, are addressed here.

CVE-2017-5754 (Meltdown)
- ------------------------

This issue relies on an affected CPU speculatively executing instructions
beyond a faulting instruction. When this happens, changes to architectural
state are not committed, but observable changes may be left in micro-
architectural state (for example, cache). This may be used to infer
privileged data.

CVE-2017-5715 (Spectre V2)
- --------------------------

Spectre V2 uses branch target injection to speculatively execute kernel code
at an address under the control of an attacker.

III. Impact

An attacker may be able to read secret data from the kernel or from a
process when executing untrusted code (for example, in a web browser).

IV. Workaround

No workaround is available.

V. Solution

Perform one of the following:

1) Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date,
and reboot.

2) To update your vulnerable system via a binary patch:

Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility, followed
by a reboot into the new kernel:

# freebsd-update fetch
# freebsd-update install
# shutdown -r now

3) To update your vulnerable system via a source code patch:

The following patches have been verified to apply to the applicable
FreeBSD release branches.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

[FreeBSD 11.1]
# fetch https://security.FreeBSD.org/patches/SA-18:03/speculative_execution-amd64-11.patch
# fetch https://security.FreeBSD.org/patches/SA-18:03/speculative_execution-amd64-11.patch.asc
# gpg --verify speculative_execution-amd64-11.patch.asc

b) Apply the patch. Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch

c) Recompile your kernel as described in
<URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.

VI. Correction details

CVE-2017-5754 (Meltdown)
- ------------------------

The mitigation is known as Page Table Isolation (PTI). PTI largely separates
kernel and user mode page tables, so that even during speculative execution
most of the kernel's data is unmapped and not accessible.

A demonstration of the Meltdown vulnerability is available at
https://github.com/dag-erling/meltdown. A positive result is definitive
(that is, the vulnerability exists with certainty). A negative result
indicates either that the CPU is not affected, or that the test is not
capable of demonstrating the issue on the CPU (and may need to be modified).

A patched kernel will automatically enable PTI on Intel CPUs. The status can
be checked via the vm.pmap.pti sysctl:

# sysctl vm.pmap.pti
vm.pmap.pti: 1

The default setting can be overridden by setting the loader tunable
vm.pmap.pti to 1 or 0 in /boot/loader.conf. This setting takes effect only
at boot.

PTI introduces a performance regression. The observed performance loss is
significant in microbenchmarks of system call overhead, but is much smaller
for many real workloads.

CVE-2017-5715 (Spectre V2)
- --------------------------

There are two common mitigations for Spectre V2. This patch includes a
mitigation using Indirect Branch Restricted Speculation, a feature available
via a microcode update from processor manufacturers. The alternate
mitigation, Retpoline, is a feature available in newer compilers. The
feasibility of applying Retpoline to stable branches and/or releases is under
investigation.

The patch includes the IBRS mitigation for Spectre V2. To use the mitigation
the system must have an updated microcode; with older microcode a patched
kernel will function without the mitigation.

IBRS can be disabled via the hw.ibrs_disable sysctl (and tunable), and the
status can be checked via the hw.ibrs_active sysctl. IBRS may be enabled or
disabled at runtime. Additional detail on microcode updates will follow.

The following list contains the correction revision numbers for each
affected branch.

Branch/path Revision
- -------------------------------------------------------------------------
stable/11/ r329462
releng/11.1/ r330908
- -------------------------------------------------------------------------

To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:

# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base

Or visit the following URL, replacing NNNNNN with the revision number:

<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>

VII. References

<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715>

<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754>

The latest revision of this advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-18:03.speculative_execution.asc>
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlqon0RfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cKORw/+Lc5lxLhDgU1rQ0JF6sb2b80Ly5k+rJLXFWBvmEQt0uVyVkF4TMJ99M04
bcmrLbT4Pl0Csh/iEYvZQ4el12KvPDApHszsLTBgChD+KfCLvCZvBZzasgDWGD0E
JhL4eIX0wjJ4oGGsT+TAqkmwXyAMJgWW/ZgZPFVXocylZTL3fV4g52VdG1Jnd2yu
hnkViH2kVlVJqXX9AHlenIUfEmUiRUGrMh5oPPpFYDDmfJ+enZ8QLxfZtOKIliD7
u+2GP8V/bvaErkxqF5wwobybrBOMXpq9Y/fWw0EH/om7myevj/oORqK+ZmGZ17bl
IRbdWxgjc1hN2TIMVn9q9xX6i0I0wSPwbpLYagKnSnE8WNVUTZUteaj1GKGTG1rj
DFH2zOLlbRr/IXUFldM9b6VbZX6G5Ijxwy1DJzB/0KL5ZTbAReUR0pqHR7xpulbJ
eDv8SKCwYiUpMuwPOXNdVlVLZSsH5/9A0cyjH3+E+eIhM8qyxw7iRFwA0DxnGVkr
tkMo51Vl3Gl7JFFimGKljsE9mBh00m8B0WYJwknvfhdehO4WripcwI7/V5zL6cwj
s018kaW4Xm77LOz6P1iN8nbcjZ9gN2AsPYUYYZqJxjCcZ7r489Hg9BhbDf0QtC0R
gnwZWiZ/KuAy0C6vaHljsm0xPEM5nBz/yScFXDbuhEdmEgBBD6w=
=fqrI
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Andrea Venturoli via freebsd-security]

On 03/14/18 05:29, FreeBSD Security Advisories wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> =============================================================================
> FreeBSD-SA-18:03.speculative_execution Security Advisory

> ...

Hello.
After upgrading two machines (one with an AMD Phenom II X4 925, the
other with a Pentium 987), I'd like to get just a couple of confirmations...

> # sysctl vm.pmap.pti
> vm.pmap.pti: 1

Of course I find this enabled on the Intel box and not on the AMD one,
but... is PTI in any way affected by a microcode update from Intel?

> The patch includes the IBRS mitigation for Spectre V2. To use the mitigation
> the system must have an updated microcode; with older microcode a patched
> kernel will function without the mitigation.
>
> IBRS can be disabled via the hw.ibrs_disable sysctl (and tunable), and the
> status can be checked via the hw.ibrs_active sysctl. IBRS may be enabled or
> disabled at runtime. Additional detail on microcode updates will follow.

None of the two box seems to have this enabled; on both I see:
> # sysctl -a|grep ibrs
> hw.ibrs_disable: 1
> hw.ibrs_active: 0

Does this mean both machine don't have a good enough microcode or is
just IBRS not enabled by default?

In the first case, I tried finding some information on what microcode is
available for what CPU (I'm interested in several other ones, not only
these two), but failed. Has anyone a pointer?



Last question: am I right that devcpu-data is nowaday useless (read no
microcode update anyway) unless this update to base is also installed?


bye & Thanks
av.

[Gordon Tetlow]

I want to send a follow up on what's going on with the Spectre/Meltdown. I
know we have been pretty silent on this recently as the work has been
ongoing in the background.

Info about the current patch
============================
What we have so far is CURRENT, 11-STABLE, and 11.1-RELEASE on amd64 now
covered with Meltdown. No user interaction is needed to use PTI as it is on
by default. If you don't want to pay the performance cost, you should put
vm.pmap.pti=0 into your loader.conf.

Spectre V2 coverage requires work on the user to enable. This isn't clear
in the SA, so I will likely issue a revision to show what is needed.

Spectre V2 is mitigated via IBRS if the user has all of the following:
- Installed the 11.1-RELEASE-p8 update
- Installed an updated microcode for the CPU to support IBRS
- Changed the sysctl hw.ibrs_disable to 0

The microcode can be installed either via a BIOS update (assuming your
manufacturer has issued one including updated microcode) or via the
sysutils/devcpu-data port/pkg. This was just updated to 1.16 to include
the required microcode for many microarchitectures (but not all).
The only way to tell for sure is to look at dmesg for:
Structured Extended Features3
which should contain IBPB and STIBP if the CPU supports IBRS. If all of
these conditions are true, check the sysctl hw.ibrs_active to see if
IBRS is turned on.

IBRS is only one way to mitigate the Spectre V2 variant. The other more
preferable way, called retpoline, has less performance impact to the
system than IBRS. However, the changes are all in the compiler which
have yet to be backported and tested with the versions of clang in 11.x
and 10.x. We wanted to get something out to allow our users to protect
themselves while the retpoline patches are finalized. Bear in mind IBRS
may have a significant impact on system performance depending on your
CPU family and workload. Users should test to decide if enabling IBRS
makes sense for their workload and tolerance for risk.

The plan for 10.x
=================
As cited in the advisory, we are working on porting the changes to 10.x for
amd64. Due to the changes in the vm system between 10.x and 11.x this is a
fair bit of work.

The plan for i386
=================
i386 is delayed as the changes needed to support PTI are more
complicated than they were on amd64. There is a high likelihood we will
fix this only in 11.x and the hope is to have it in place for the 11.2
release coming out this summer.

Gordon

[Jan Demter]

Hi Andrea!

Am 16.03.18 um 17:11 schrieb Andrea Venturoli via freebsd-security:

> On 03/14/18 05:29, FreeBSD Security Advisories wrote:
>> # sysctl vm.pmap.pti
>> vm.pmap.pti: 1
>
> Of course I find this enabled on the Intel box and not on the AMD one,
> but... is PTI in any way affected by a microcode update from Intel?

From what I have read so far, I'm pretty certain it isn't planned or
even possible to patch this via a microcode update.

>> IBRS can be disabled via the hw.ibrs_disable sysctl (and tunable), and
>> the
>> status can be checked via the hw.ibrs_active sysctl.  IBRS may be
>> enabled or
>> disabled at runtime.  Additional detail on microcode updates will follow.
>
> None of the two box seems to have this enabled; on both I see:
>> # sysctl -a|grep ibrs
>> hw.ibrs_disable: 1
>> hw.ibrs_active: 0
>
> Does this mean both machine don't have a good enough microcode or is
> just IBRS not enabled by default?

IBRS does not seem to be enabled by default:
https://reviews.freebsd.org/rS328625
"For existing processors, you need a microcode update which adds IBRS
CPU features, and to manually enable it by setting the tunable/sysctl
hw.ibrs_disable to 0."

> In the first case, I tried finding some information on what microcode is
> available for what CPU (I'm interested in several other ones, not only
> these two), but failed. Has anyone a pointer?

For Intel CPUs, there's this list:
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf

> Last question: am I right that devcpu-data is nowaday useless (read no
> microcode update anyway) unless this update to base is also installed?

The microcode update itself will work, if that is what you meant, but
just updating the microcode and not FreeBSD is useless to mitigate
Spectre V2.

Hope this helps,
Jan

[Ed Maste]

On 18 March 2018 at 13:54, Jan Demter <jan-mail...@demter.de> wrote:
> Hi Andrea!
>
> Am 16.03.18 um 17:11 schrieb Andrea Venturoli via freebsd-security:
>>
>> On 03/14/18 05:29, FreeBSD Security Advisories wrote:
>>>
>>> # sysctl vm.pmap.pti
>>> vm.pmap.pti: 1
>>
>> Of course I find this enabled on the Intel box and not on the AMD one,
>> but... is PTI in any way affected by a microcode update from Intel?
>
> From what I have read so far, I'm pretty certain it isn't planned or even
> possible to patch this via a microcode update.

That is correct. Meltdown won't ever be fixed with a microcode update
as far as we know, and no microcode update is required for the PTI
mitigation.

There's one small wrinkle: there are some recent lower-end processors
(at least some recent Celerons) which it seems are not susceptible to
Meltdown, and after a microcode update will set a bit to indicate
this. In that case a microcode update will cause FreeBSD to switch
from enabling PTI to disabling it by default -- but that CPU is not
affected by Meltdown, with or without the update.

> IBRS does not seem to be enabled by default:
> https://reviews.freebsd.org/rS328625
> "For existing processors, you need a microcode update which adds IBRS
> CPU features, and to manually enable it by setting the tunable/sysctl
> hw.ibrs_disable to 0."

That is true. Further, we expect the compiler-based retpoline to be
the usual mitigation used for Spectre V2, for CPUs before Skylake.
Development work for this is still ongoing in -CURRENT.

[Andrea Venturoli]

On 03/18/18 18:54, Jan Demter wrote:

>> Of course I find this enabled on the Intel box and not on the AMD one,
>> but... is PTI in any way affected by a microcode update from Intel?
>
> From what I have read so far, I'm pretty certain it isn't planned or
> even possible to patch this via a microcode update.

Ok, I'm wrong then: I understood Spectre was unfixable, while Intel had
provided (or was going to provide) a microcode update to patch (not
mitigate) MeltDown.

Of course PTI might be a good idea in any case.

> For Intel CPUs, there's this list:
> https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf

Thanks. Altough I was looking for AMD mostly :)

> The microcode update itself will work, if that is what you meant, but
> just updating the microcode and not FreeBSD is useless to mitigate
> Spectre V2.

Again, my fault: the "Please update your system in order to update CPU
microcode." message led me to a wrong conclusion.



bye & Thanks
av.

[Christian Weisgerber]

On 2018-03-19, Ed Maste <ema...@freebsd.org> wrote:

> There's one small wrinkle: there are some recent lower-end processors
> (at least some recent Celerons) which it seems are not susceptible to
> Meltdown, and after a microcode update will set a bit to indicate
> this.

Specifically, Goldmont cores (Apollo Lake, Denverton).

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Brett Glass]

Intel Atom processors are also not susceptible. Only one of them does any
out-of-order execution, and that one appears to do it in a way that is not
susceptible to Meltdown or Spectre.

--Brett Glass