Intel - Hardwarebug

FreeBSDs Meltdown-Patch wird auf allen Intel-CPUs funktionieren, auf denen FreeBSD läuft. Die einzige Bedingung ist, dass FreeBSD/amd64 verwendet wird, womit sehr alte Modelle rausfallen. Das sind Pentium 1, 2, 3, Pro und M komplett, sowie frühere Pentium 4 Serien. Aber die sind auch gleich so alt, dass sie sowieso nicht mehr ernsthaft in Szenarien genutzt werden, wo sie angreifbar sind. PCID werden automagisch auf CPU genutzt, die es können. Das ist ab ca. Westmere aufwärts, wobei es da durch Intels schwer durchschaubares Kern-Recycling Ausreißer in beide Richtungen gibt.

Für Spectre hat FreeBSD auf den x86-Plattformen noch gar keinen Patch. Da wird man sehr wahrscheinlich den gleichen Weg wie Linux und Windows gehen und auf eine Mischung aus Retopline und auf die per (gerade mal wieder zurückgezogenem) Microcode-Update implementierten Features gehen. Das bedeutet dann auch, dass es ohne Microcode-Update keinen vollständigen Schutz geben wird. Sprich alles was älter als Haswell ist wird teilweise verwundbar bleiben.
Allerdings ist Spectre für die meisten Endnutzer ein eher theoretisch zu sehender Angriff, um den man sich im Normalfall keine große Gedanken machen muss. Vor allem nicht, wenn man ohne ECC-RAM läuft und daher bisher auch schon durch Rowhammer (auch länger schon per Javascript möglich) angreifbar war. Das Gepatche, gerade von Intel wirkt im Desktopbereich eher als "wir müssen was machen um nicht als Patchverweigerer darzustehen" als das es nun wirklich sinnvoll und den bei vollständigen Schutz zu erwartenden, heftigen Performanceverlust wert wäre.
 
Yamagi schrieb:
Aber die sind auch gleich so alt, dass sie sowieso nicht mehr ernsthaft in Szenarien genutzt werden, wo sie angreifbar sind. PCID werden automagisch auf CPU genutzt, die es können. Das ist ab ca. Westmere aufwärts, wobei es da durch Intels schwer durchschaubares Kern-Recycling Ausreißer in beide Richtungen gibt
Zum Vergrößern anklicken....

Wobei man hier auch unterscheiden muss:
PCID gibt es "für alle" ab Sandy Bridge. Einige Westmere Xeons hatten es aber auch. Dann gibt es noch ab Haswell INVPCID. Scheinbar ist INVPCID bei Windows und Linux wichtiger, als PCID:

https://patchwork.kernel.org/patch/10035481/

So, for now, we fully disable PCIDs with KAISER when INVPCID is
not available. This is fixable, but it's an optimization that
we can do later.
Zum Vergrößern anklicken....

Das ist für Linux und vom Oktober 2017. Keine Ahnung wie der aktuelle Stand ist und keine Ahnung wie es hier bei FreeBSD aussieht.
 
Noch einmal die gleiche Messung wie in #184, nur dieses Mal mit dem PCID-Patch:

Code: 
'time make -j6 -DWITH_META_MODE buildworld buildkernel' der r328513 Sourcen auf leerem /usr/obj.

# Ohne PTI:
22155.900u 865.078s 1:38:05.05 391.1%  54657+3480k 68449+148967io 24578pf+0w

# Mit PTI
22193.461u 917.469s 1:38:29.84 391.0%  54614+3477k 68572+148403io 24590pf+0w

=> 0,41% langsamer

Code: 
'time make -j6 -DWITH_META_MODE buildworld buildkernel' der r328513 Sourcen auf gefülltem /usr/obj.
Dies baut nichts neu, feuert nur jede Menge Syscalls auf die Source- und Object-Dateien ab.

# Ohne PTI
178.254u 67.015s 1:24.44 290.4% 3986+2677k 71094+5263io 24955pf+0w 

# Mit PTI
175.149u 66.678s 1:24.24 287.0% 3751+2644k 69693+5457io 23630pf+0w

=> Gleich schnell

Code: 
'rm -Rf /usr/obj' auf das gefüllte /usr/obj. Es war ein UFS-Dateisystem, die unlink() Syscalls kehren
also (meist) sofort zurück und warten nicht auf das Dateisystem oder die SSD.

# Ohne PTI
0.145u 6.655s 0:09.75 69.6%  9+172k 166+4997io 0pf+0w

# Mit PTI
0.085u 5.686s 0:08.15 70.6%  10+180k 170+4997io 0pf+0w

=> -19,63% langsamer (wahrscheinlich durch Cache-Effekte, dumme Milchmädchenmessung)

Mit der Nutzung von PCIDs (oder wie genau das implementiert sein mag, ich habe keine besonders große Begeisterung den Patch nachzuvollziehen) ist zumindest bei meinen zugegeben schlechten bis methodisch falschen Messungen kein nennenswerter Geschwindigkeitsunterschied mehr messbar. Die Unterschiede liegen im Bereich von Messungenauigkeit. Für klarere Aussagen müsste man mehr Workloads testen.
 
Hallo,

ich fasse mal für mich zusammen:

1. Betroffen sind v.a. Server mit vielen paralellen virtuellen Maschinen (Performance Verlust durch Taskwechsel, Einfallsweg für Angriffe aus virtueller Maschine)

2. AMD Besitzer haben ein geringeres Risiko angegriffen zu werden, da bestimmte Angriffsszenarien nicht funktionieren

3. Als Desktop Benutzer von FreeBSD der über die Desktopüblichen Schnitzstellen ins Internet geht ist die Angriffswahrscheinlichkeit gering, da hier der (aktuelle) Browser wg. seinem verschleierten Timer einen Angriff ausschalten kann.

Sehe ich das richtig?

Serie300
 
Ist zwar aus der "Linux-Welt" mit dem Kernel 4.15.0-1 aber auch ein gewisser Fortschritt:

Code: 
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

Wirklich sicher fühle ich mich selten.
 
Mit dem Kernel 4.14.14-1 sieht es so aus:

Code: 
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Checking whether we're safe according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable: Minimal generic ASM retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

Woher habe ich diese Information? Sagt mir der "spectre-meltdown-checker". Habe einfach mit grub diesen Kernel gestartet.

Es gibt aber auch schon den 4.14.15-1. Diesen Kernel habe ich nicht installiert und ich kann die gewünschte Information nicht abrufen.
 
Code: 
$ uname -r
4.14.15-1-ARCH
$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline

War mit 4.14.14 auch schon so. Hängt natürlich davon ab, wer und wie dein Kernel kompiliert hat. Vermutlich wurde dein 4.14.14 noch mit einem GCC ohne Retpoline-Fähigkeit gebaut.
 
Unterstützung für die Spectre Migitation Features für FreeBSD 12-CURRENT:
Code: 
Author: kib
Date: Wed Jan 31 14:36:27 2018
New Revision: 328625
URL: https://svnweb.freebsd.org/changeset/base/328625

Log:
  IBRS support, AKA Spectre hardware mitigation.
 
  It is coded according to the Intel document 336996-001, reading of the
  patches posted on lkml, and some additional consultations with Intel.
 
  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.  Current status can be checked in sysctl
  hw.ibrs_active.  The mitigation might be inactive if the CPU feature
  is not patched in, or if CPU reports that IBRS use is not required, by
  IA32_ARCH_CAP_IBRS_ALL bit.
 
  Sponsored by:   The FreeBSD Foundation
  MFC after:   1 week
  Differential revision:   https://reviews.freebsd.org/D14029
 
FreeBSDs Meltdown- und Spectre-Patches sind am Wochenende in 11-STABLE angekommen:

Code: 
Author: kib
Date: Sat Feb 17 18:00:01 2018
New Revision: 329462
URL: https://svnweb.freebsd.org/changeset/base/329462

Log:
  MFC r328083,328096,328116,328119,328120,328128,328135,328153,328157,
  328166,328177,328199,328202,328205,328468,328470,328624,328625,328627,
  328628,329214,329297,329365:
 
  Meltdown mitigation by PTI, PCID optimization of PTI, and kernel use of IBRS
  for some mitigations of Spectre.
 
  Tested by:  emaste, Arshan Khanifar <arshankhanifar@gmail.com>
  Discussed with:   jkim
  Sponsored by:   The FreeBSD Foundation

PTI mit PCID ist auf betroffenen Prozessoren eingeschaltet, IBRS ist standardmäßig deaktiviert. Wer IBRS testen will sollte beachten, dass das man Intels aktuellen Microcode braucht. Stabiler Microcode ist nur für Skylake verfügbar, für alle anderen Familien lässt er auf sich warten oder wurde wegen Problemen wie spontanen Reboots zurückgezogen.
 
Ich habe noch einmal deutlich korrekter gemessen als oben. Das System ist ein Intel Core i7-6700k, also Skylake-Architektur mit 4 Kernen zu je 4.0 GHz. Es hat 32 Gigabyte RAM, das System läuft auf einer Samsung M.2 SSD auf ZFS. Die FreeBSD-Version ist 11.1-STABLE in r329582, der CPU-Microcode Version 0x2C. Diese Version ist laut Intel, sofern man die wirre Informationspolitik überhaupt noch versteht, die endgültige Version des Microcode-Patches für Skylake. Das System lief im Single User Mode, das Power Management war abgeschaltet. Die Ergebnisse sind aus jeweils 3 Läufen gemittelt.

Generell ist unten der erste Lauf das Bauen der Sourcen, der zweite Lauf läuft nur darüber hinweg und änderts nichts. Der erste Lauf verbrennt die meiste Zeit in den Compilern, der zweite Lauf wartet vor allem auf Syscalls.

Basiswert, "time make -j10 -DWITH_META_MODE buildworld" der 11.1-STABLE r329582 Sourcen ohne PTI und IBRS:
Code: 
# 1. Lauf: 2137 Sekunden
# 2. Lauf: 51 Sekunden

Die gleiche Messung, aber mit PTI eingeschaltet:
Code: 
# 1. Lauf: 2142 Sekunden
# 2. Lauf: 52 Sekunden

Die gleiche Messung mit PTI und IBRS:
Code: 
# 1. Lauf: 2238 Sekunden
# 2. Lauf: 66 Sekunden.

PTI ist, wie nach den vorherigen Messergebnissen weiter oben in diesem Thema schon erwartet, zumindest auf Skylake mit guter und vor allem schneller PCID Implementierung vernachlässigbar. Im ersten Lauf beträgt der Verlust 0,24 Prozent und im zweiten Lauf 1,93 Prozent. IBRS tut dann wie ebenfalls erwartet mehr weh. 4,4 Prozent im ersten Lauf und 26,92 Prozent im zweiten Lauf.

Bei allem muss man beachten, dass "make buildworld" nur ein möglicher Workload ist. Grundsätzlich gilt, dass sowohl PTI als auch IBRS Syscalls verteuern. Je mehr Syscalls ein Workload nutzt, umso mehr wird er ausgebremst. Welche Maßnahmen man einschalten sollte oder sogar muss und welche nicht, hängt somit vom Workload und vom Bedrohungsszenario ab.
 
Auch bei OpenBSD wurde nun der Meltdown fix committed.
Code: 
Modified files:
     sys/arch/amd64/amd64: cpu.c gdt.c genassym.cf identcpu.c lapic.c
     locore.S locore0.S machdep.c pmap.c spl.S
     trap.c vector.S
     sys/arch/amd64/conf: ld.script
     sys/arch/amd64/include: asm.h cpu.h cpufunc.h frame.h frameasm.h
     gdt.h pmap.h specialreg.h
Added files:
     sys/arch/amd64/include: cpu_full.h

Log message:
     Meltdown: implement user/kernel page table separation.

On Intel CPUs which speculate past user/supervisor page permission checks,
use a separate page table for userspace with only the minimum of kernel code
and data required for the transitions to/from the kernel (still marked as
supervisor-only, of course):
- the IDT (RO)
- three pages of kernel text in the .kutext section for interrupt, trap,
and syscall trampoline code (RX)
- one page of kernel data in the .kudata section for TLB flush IPIs (RW)
- the lapic page (RW, uncachable)
- per CPU: one page for the TSS+GDT (RO) and one page for trampoline
stacks (RW)

When a syscall, trap, or interrupt takes a CPU from userspace to kernel the
trampoline code switches page tables, switches stacks to the thread's real
kernel stack, then copies over the necessary bits from the trampoline stack.
On return to userspace the opposite occurs: recreate the iretq frame on the
trampoline stack, switch stack, switch page tables, and return to userspace.

mlarkin@ implemented the pmap bits and did 90% of the debugging, diagnosing
issues on MP in particular, and drove the final push to completion.
Many rounds of testing by naddy@, sthen@, and others
Thanks to Alex Wilson from Joyent for early discussions about trampolines
and their data requirements.
Per-CPU page layout mostly inspired by DragonFlyBSD.
https://marc.info/?l=openbsd-cvs&m=151924107018358&w=2
https://undeadly.org/cgi?action=article;sid=20180221201856
 
Auch bei OpenBSD 6.1 (oldstable) und OpenBSD 6.2 (stable) wurde nun der Meltdown fix zurueckportiert und kann per "syspatch" installiert werden.
The recent changes in -current mitigating the Meltdown vulnerability have been backported to the 6.1 and 6.2 (amd64) releases, and the syspatch update (for 6.2) is now available.

Happy syspatching, and don't forget to show your appreciation by donating to the project.
Zum Vergrößern anklicken....
https://undeadly.org/cgi?action=article;sid=20180228225937
 
FreeBSD hat nun einen Patch für das 11.1-RELEASE veröffentlicht, er wird per freebsd-update(8) verteilt. Der Patch unterstützt derzeit nur FreeBSD/amd64, Varianten für FreeBSD/i386 und das ältere 10.4-RELEASE werden später folgen.

Code: 
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>
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben