Spectre and Meltdown – Information leak via speculative execution side channel attacks
In January 2018, security researchers announced a new class of side channel attacks that impact most processors, including processors from Intel, AMD, ARM and IBM. The attack allows malicious userspace processes to read kernel memory and malicious code in guests to read hypervisor memory.
To address the issue in Ubuntu, updates to the kernel, processor microcode, hypervisor, and various other userspace packages will be needed. These updates are being announced in Ubuntu Security Notices as they are available.
There were three original vulnerabilities involved:
| Group | Name | Variant | Description | Ubuntu CVE Tracker |
|---|---|---|---|---|
| Jan 2018 | Spectre | Variant 1 | Bounds Check Bypass | CVE-2017-5753 |
| Jan 2018 | Spectre | Variant 2 | Branch Target Injection | CVE-2017-5715 |
| Jan 2018 | Meltdown | Variant 3 | Rogue Data Cache Load | CVE-2017-5754 |
The Spectre and Meltdown vulnerabilities have varying impacts in different environments, and the mitigations available can be difficult to understand. We’ve prepared a Technical FAQ to help answer many common questions.
This article will be updated periodically with new information as it becomes available, until the issues have been resolved.
Current status
From a guest and non-hypervisor bare-metal perspective, as of the Feb 21 kernel updates, as far as we are aware, the mitigations for Spectre and Meltdown on 64-bit amd64, ppc64el and s390x are feature-complete as long as all microcode, firmware and hypervisor updates underneath the system are done. However:
- Ubuntu kernels have been rebuilt using retpolines on i386 and amd64 for Ubuntu 17.10, Ubuntu 16.04 LTS, and Ubuntu 14.04 LTS (linux-lts-xenial aka Hardware Enablment kernel) only. We are investigating selective rebuilds of Ubuntu userspace packages to make use of retpoline.
Additionally:
- No fix is currently available for Meltdown on 32-bit x86; moving to a 64-bit kernel is the currently recommended mitigation.
- No fixes are yet available for ARM platforms. Note that a relatively small number of standard ARM cores are known to be affected.
- For Ubuntu hypervisors, further work will be required to expose the Spectre variant 2 mitigations to guests running on top of Ubuntu, including a qemu update and some additional kernel updates.
Kernel mitigations
Ubuntu enables available kernel mitigations to provide a secure-by-default experience. It should be noted that the security features to mitigate these vulnerabilities can lead to a decrease in system performance. Reputable reports of published application performance data can aide in understanding the impact in various environments. Environments which do not execute untrusted code may benefit from toggling the mitigation controls to disable some or all of the kernel mitigations.
The current kernel mitigation status is as follows:
| i386 | amd64 | ppc64el | s390x | armhf | arm64 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Ubuntu | Kernel | S1 | S2 | M | S1 | S2 | M | S1 | S2 | M | S1 | S2 | S1 | S2 | M | S1 | S2 | M | Latest USN |
| 17.10 | 4.13 | Y | R | - | Y | F,R | Y | Y | F | F | Y | F | - | - | - | Y | F | Y | USN-3581-1 on 2018-02-22 USN-3597-2 on 2018-03-15 for arm64 |
| 16.04 LTS | 4.13 HWE | Y | R | - | Y | F,R | Y | Y | F | F | Y | F | - | - | - | Y | F | Y | USN-3581-2 on 2018-02-22 USN-3597-2 on 2018-03-15 for arm64 |
| 16.04 LTS | 4.4 | Y | R | - | Y | F,R | Y | Y | F | F | Y | F | - | - | - | - | - | - | USN-3582-1 on 2018-02-22 |
| 14.04 LTS | 4.4 HWE | Y | R | - | Y | F,R | Y | Y | F | F | U | U | - | - | - | U | U | U | USN-3582-2 on 2018-02-22 |
| 14.04 LTS | 3.13 | Y | R | - | Y | F,R | Y | - | - | F | U | U | - | - | - | U | U | U | USN-3583-1 on 2018-02-22 |
| 12.04 ESM | 3.13 HWE | U | U | U | Y | F | Y | U | U | U | U | U | U | U | U | U | U | U | USN-3542-2 on 2018-01-22 |
| 12.04 ESM | 3.2 | U | U | U | Y | F | Y | U | U | U | U | U | U | U | U | U | U | U | USN-3580-1 on 2018-02-21 |
| Ubuntu | Kernel | i386 | amd64 | ppc64el | s390x | armhf | arm64 | Latest USN | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| S1 | S2 | M | S1 | S2 | M | S1 | S2 | M | S1 | S2 | S1 | S2 | M | S1 | S2 | M | |||
| 17.10 | 4.13 | Y | R | - | Y | F,R | Y | Y | F | F | Y | F | - | - | - | Y | F | Y | USN-3581-1 on 2018-02-22 USN-3597-2 on 2018-03-15 for arm64 |
| 16.04 LTS | 4.13 HWE | Y | R | - | Y | F,R | Y | Y | F | F | Y | F | - | - | - | Y | F | Y | USN-3581-2 on 2018-02-22 USN-3597-2 on 2018-03-15 for arm64 |
| 16.04 LTS | 4.4 | Y | R | - | Y | F,R | Y | Y | F | F | Y | F | - | - | - | - | - | - | USN-3582-1 on 2018-02-22 |
| 14.04 LTS | 4.4 HWE | Y | R | - | Y | F,R | Y | Y | F | F | U | U | - | - | - | U | U | U | USN-3582-2 on 2018-02-22 |
| 14.04 LTS | 3.13 | Y | R | - | Y | F,R | Y | - | - | F | U | U | - | - | - | U | U | U | USN-3583-1 on 2018-02-22 |
| 12.04 ESM | 3.13 HWE | U | U | U | Y | F | Y | U | U | U | U | U | U | U | U | U | U | U | USN-3542-2 on 2018-01-22 |
| 12.04 ESM | 3.2 | U | U | U | Y | F | Y | U | U | U | U | U | U | U | U | U | U | U | USN-3580-1 on 2018-02-21 |
| Key | Meaning |
|---|---|
| S1 | Spectre / Variant 1 / CVE-2017-5753 |
| S2 | Spectre / Variant 2 / CVE-2017-5715 |
| M | Meltdown / Variant 3 / CVE-2017-5754 |
| Y | Updates have been published to mitigate the issue |
| F | Updates have been published to mitigate the issue but require updated firmware/microcode |
| R | Kernel compiled with Retpoline, please see the FAQ around Retpoline to better understand the extent of this mitigation |
| - | Updates are not yet available |
| U | Architecture is unsupported |
Processor firmware availability
| Ubuntu Architectures | Vendor Statements | Firmware Status | Notes |
|---|---|---|---|
| i386, amd64 | Intel, AMD | Available, see USN-3531-3 and USN-3690-2 | Note that some users experienced lockups with the 180108 version of the intel-microcode |
| ppc64el | IBM | Available from IBM | |
| s390x | IBM | Available from IBM | |
| armhf, arm64 | ARM, Cavium | Available from system vendors | A relatively small number of standard ARM cores are known to be affected |
Userspace mitigations
Mitigations have been released for the following non-kernel packages:
| Package | USN | Notes |
|---|---|---|
| Firefox | USN-3516-1 | Reduces resolution of timers, disables a mechanism that could be used to build a timer |
| WebKitGTK+ | USN-3530-1 | Reduces resolution of timers, disables a mechanism that could be used to build a timer |
| NVIDIA graphics drivers | USN-3521-1 | |
| QEMU | USN-3560-1 | Exposes Spectre variant 2 mitigations, added by microcode/firmware updates, to guests (i386, amd64, and s390x only) |
| libvirt | USN-3561-1 | Exposes Spectre variant 2 mitigations, added by microcode/firmware updates, to guests (i386 and amd64 only) |
Cloud images
Cloud images which address CVE-2017-5753 and CVE-2017-5715 (aka Spectre) and CVE-2017-5754 (aka Meltdown) are available for https://cloud-images.ubuntu.com from for the following releases:
Important notes
- As release images are published in clouds many are indexed @ Ubuntu Cloud Image Finder This tool can be used to find images with the above serials, or later, with applicable fixes.
- Previously released cloud images (serial 20180109 for xenial and artful and serial 20180110 for trusty) only mitigated Meltdown
- Note: A small number of systems running linux 4.4.0-108.131 were affected by LP: #1741934 which was fixed in 4.4.0-109.132. Cloud instances were not affected by the bug. Cloud images created using 4.4.0-108.131 and its derivatives (for example, linux-aws 4.4.0-1047.56) have the mitigations for Meltdown.
- Kernels compiled with retpoline enabled compiler flags on amd64 and i386 are only available for Ubuntu 16.04 LTS and Ubuntu 17.10 (serial 20180222 for both).
Ubuntu Core images
Canonical officially supports reference kernel snaps for amd64 (pc-kernel), i386 (pc-kernel), rpi2/rpi3 (pi2-kernel) and dragonboard (dragonboard-kernel). Updates for affected architectures for Meltdown are available:
| Kernel | Snap revision | Ubuntu Core image |
|---|---|---|
| pc-kernel (amd64) | 98 | http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-amd64.img.xz |
| pc-kernel (i386) | 99 | http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-i386.img.xz |
Early Raspberry Pi 2 boards use the Cortex-A7 processor and later versions use the Cortex-A53 processor. Raspberry Pi 3 boards use the Cortex-A53 processor. 96boards Dragonboard 410c boards use the Cortex-A53. According to ARM, none of these devices support speculative execution and are therefore unaffected by Spectre and Meltdown.
Application performance
The table below collects public information posted by reliably identified sources that describes (to at least a minimal degree) how workload performance has been affected by the Meltdown and Spectre mitigations. We’ve attempted to identify what fixes were in place at the time of the run, as most reports unfortunately do not indicate those — though given the complexity of the situation, it’s not surprising that’s unclear.
For the tests which were run against AWS, note Amazon applied a first set of updates on Jan 4th, and a further set on Jan 12th, the second set generally noted as reducing the performance impact. Note also that for full protection the guest microcode and OS also needs to be updated, but not all tests implemented or compared using them.
| Workload | Source | Mitigations | Substrate | Regression Measured | Reference |
|---|---|---|---|---|---|
| Apache Spark | Databricks | Host: KPTI, retpoline? Guest: ? | AWS r3 and i3 | 3%-5% | link |
| Cassandra | The Last Pickle | KPTI only | Mobile Broadwell | 20-50% latency increase | link |
| Elasticsearch | elastic.co | KPTI only | Skylake | 0-4% | link |
| Hadoop (CDH) | Cloudera | ? | ? | 3-12% | link |
| nginx | George Liu | KPTI Only | Haswell i7 4790K | 5.5% | link |
| Percona | Percona | KPTI, IBRS, IBPB | Haswell | 15-25% | link |
| PostgreSQL | 2nd Quadrant | KPTI Only | Skylake | 7% | link |
| ScyllaDB | Scylla | Host: KPTI, STIBP? Guest: KPTI Only | AWS i3.16xlarge | 6% (guest KPTI delta only, no baseline) | link |
Mitigation controls
The Meltdown and Spectre vulnerabilities involve a performance-security tradeoff. The following describes the relevant tunables offered for selectively disabling mitigations in contexts where the tradeoffs have been evaluated and justified.
IMPORTANT: Vulnerability mitigations should only be disabled in carefully controlled environments where all of the code being executed is known and trusted. Disabling any of these mitigations in situations where untrusted code can be executed is not recommended.
CVE-2017-5754 (Meltdown)
CVE-2017-5715 (Spectre / Variant 2)
CVE-2018-3639 (aka Variant 4)
| Arch | Description | Kernel parameter | Options | Ubuntu default |
|---|---|---|---|---|
| amd64 | Fine grained mitigations | spec_store_bypass_disable=[prctl|seccomp] |
prctl - mitigations disable by default with opt-in enablement available via prctl()seccomp - same as prctl plus all applications with a seccomp filter are implicitly opted-in to mitigations |
|
| amd64 ppc64el |
Global mitigations | spec_store_bypass_disable=[on|off|auto] |
on - unconditionally enable mitigationsoff - unconditionally disable mitigationsauto - On x86, same as seccomp above. On ppc64el, the kernel and virtual machines are protected. |
auto |
| amd64 ppc64el |
Disable all mitigations (system may allow data leaks with this option) | nospec_store_bypass_disable |
Equivalent to spec_store_bypass_disable=off |
Additional side channel issues
Since Spectre and Meltdown were disclosed, additional side channel issues have been disclosed and documented in separate KnowledgeBase articles. You can see these articles at the following URLs:
| Date | Name | Description | CVE ID |
|---|---|---|---|
| May 2018 | Variant 4 | Speculative Store Bypass | CVE-2018-3639 |
| June 2018 | LazyFP | LazyFP Save/Restore | CVE-2018-3665 |
| July 2018 | BCBS | Bounds Check Bypass Store | CVE-2018-3693 |
Technical FAQ
Meltdown
Can you break out of a VM into other VMs, or into the hypervisor with Meltdown?
No, due to the fact that memory is (and has always been) isolated when running in a VM context.
Note this doesn’t hold true for paravirtualized (PV) guests, but these are relatively unused and being phased out.
Unlike Meltdown, Spectre can break out of a virtual machine.
Can you break into a VM from a process on the hypervisor with Meltdown?
Yes, a malicious userspace application running on a hypervisor can read memory in any VM hosted on it.
What mitigations are available for Meltdown?
There is only one mitigation necessary and implemented for Meltdown, KPTI (Kernel Page-Table Isolation). KPTI has now been rolled out to all supported Ubuntu releases via security updates.
What is PCID?
PCID (Process-Context Identifier) is a CPU feature which allows tagging of TLB entries so that page table switches don’t invalidate the whole cache. This reduces the performance impact of KPTI. Performance is further restored almost to previous states when PCID is used in combination with a more recent CPU feature, INVPCID. PCID and INVPCID were added in Intel’s Westmere (2010) and Haswell (2013) CPU microarchitectures respectively.
While PCID support was only included in the upstream 4.14 kernel, it has been backported along with the KPTI patchset as part of the kernel updates in the Meltdown USNs issued on Jan 9.
Virtual machines can’t use these optimisations unless the hypervisor exposes the CPU’s PCID and INVPCID features. If the VM is running with an updated kernel, KPTI will still be active and the VMs will be secure, but they will experience seriously degraded performance until the hypervisor is updated to expose them.
Is there KPTI support for 32-bit x86, a.k.a. i386?
Not currently. There is a patchset posted upstream by SUSE that may serve as the basis for this support in the future, but for now there is no way to mitigate Meltdown on 32-bit x86 kernels.
For now the recommended workaround is to install a 64-bit kernel with KPTI enabled; this is possible while still running the unmodified 32-bit userspace installation. However, even with KPTI support, a 32-bit x86 kernel cannot use PCID or INVPCID, so the performance impact will be severe.
In virtualized environments, does updating the hypervisor protect guests?
No, guests must upgrade to a kernel with KPTI in order to protect themselves from their own userspace processes.
Vulnerable hypervisors can be used to attack all system memory, including memory owned by VMs. Vulnerable VMs can leak memory between processes within that VM, including between containers. For full protection, both the hypervisor and guest kernels need to be upgraded.
Spectre
Can Spectre be exploited through a web browser
Yes, it can. Javascript is a known attack vector, and browser sandboxing is insufficient to protect from it. This means that browsing the web with a vulnerable browser can open up an end-user to attack.
While no videos have been published, there has been PoC code published that demonstrates the vulnerabilities, and Tencent have released an online checker that uses a similar approach.
Every major browser vendor had advisories linked in the vulnerability disclosure site and in the context of Ubuntu, Firefox and Chromium have been updated.
Can VMs read memory from the hypervisor, or other VMs running on the same hypervisor with Spectre?
Yes, these exploits are possible with Spectre. As we noted above, hypervisor memory is normally unavailable in VM context, but Spectre works by tricking the CPU executing in hypervisor mode into leaking memory through caches into the VM.
So Spectre indeed allows a VM to read memory which only the hypervisor should have access to, and since the hypervisor kernel has all system memory accessible, attacking the hypervisor kernel effectively provides access to all system memory.
How do the Spectre mitigations work?
Spectre mitigations are a complex topic due to the fact that there are 2 variants (named here SV1 and SV2), 4 different underlying mechanisms being used to mitigate them, and permutations in terms of support across hardware, hypervisor and operating system.
SV1 is mitigated only by patching code sequences found to be vulnerable; static analysis is the mechanism currently being used to find these. This means that many userspace attacks are likely to remain undiscovered.
There are 4 different underlying techniques SV2 mitigations utilize:
- Indirect Branch Restricted Speculation (IBRS)
- Indirect Branch Predictor Barrier (IBPB)
- Single Thread Indirect Branch Predictor (STIBP)
- Retpoline
Of those, the first 3 are implemented in hardware and require microcode updates to be accessible. They also need to be implemented on both the hypervisor and the guest levels, and the hypervisor needs to expose the features to the guests.
Retpoline
What is retpoline?
Retpoline is a software workaround that mitigates against SV2. This workaround does not require microcode in order to be active; however, it requires that code be recompiled with a compiler enabled with this feature. Recompiling the kernel with this feature is simple, but updating all of userspace is a significant effort, without which protection from speculative userspace attacks needs to rely on the slower hardware-based mitigations.
Does retpoline work on AMD, ARM, and other architectures?
Retpoline is effective on x86 CPUs from Intel and AMD. It’s not currently supported on processors from other vendors or of other architectures.
If I run on a hypervisor with retpoline enabled, is my VM protected?
No. Retpoline immunises software that is compiled with it against attacks using Spectre variant 2, but non-retpolined software running on the same system is still vulnerable. A retpolined hypervisor cannot be attacked, but in most cases (depending on how the hypervisor is configured) direct attacks between VMs and from VM processes against VM kernels are still possible. Some clouds prevent attacks between VMs, but it’s unlikely that any prevent attacks between processes or against the kernel within a VM.
If I’m using retpoline, do I still need the microcode features and corresponding firmware or hypervisor support?
Yes, for now. A kernel (and hypervisor, if in a VM) using retpoline is sufficient to defend against the existing public Spectre variant 2 attacks, but they leave any un-retpolined userspace code vulnerable. Direct attacks that bypass the kernel are inevitable, so until every piece of code on a system is rebuilt with retpoline the kernel must use microcode-based mitigations to protect userspace.
If I’m not using retpoline, do I need to have all microcode features enabled?
Yes. Updated firmware/microcode (and hypverisor, if in a VM) are required to mitigate Spectre variant 2 on amd64, ppc64el and s390x platforms.
What userspace applications are being updated?
Due to the nature of Spectre, many userspace applications are likely affected. However, we understand that most applications have a reduced attack surface, and have focused our attentions on browsers which are the most important attack vectors and where key exploits were showcased.
As mentioned earlier, Firefox has been updated, now to 58 but originally to 57 in USN 3516: USN-3516-1: Firefox vulnerabilities | Ubuntu security notices | Ubuntu – the corresponding advisory from Mozilla is at https://www.mozilla.org/en-US/security/advisories/mfsa2018-01/
Chromium is a Universe package, and as such does not receive USNs, but has been updated to version 63, which disabled SharedArrayBuffer support. We are currently awaiting the upstream release of version 64, which will contain broader Spectre mitigations.
Active Mitigations
The kernel provides an interface to check the current status of known mitigations for CPU bugs via sysfs. You can check that like:
$ head -n -0 /sys/devices/system/cpu/vulnerabilities/*
==> /sys/devices/system/cpu/vulnerabilities/l1tf <==
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
==> /sys/devices/system/cpu/vulnerabilities/mds <==
Mitigation: Clear CPU buffers; SMT disabled
==> /sys/devices/system/cpu/vulnerabilities/meltdown <==
Mitigation: PTI
==> /sys/devices/system/cpu/vulnerabilities/spec_store_bypass <==
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
==> /sys/devices/system/cpu/vulnerabilities/spectre_v1 <==
Mitigation: __user pointer sanitization
==> /sys/devices/system/cpu/vulnerabilities/spectre_v2 <==
Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling
Configuration as a Hypervisor
There are a multitude of CPU features available at the moment that are related to spectre and meltdown. Their availability depends on the architecture, manufacturer and microcode/firmware levels.
There are a few extra considerations to be done as a hypervisor:
One needs to consider the level of control about the code running in the guests to make decisions how many mitigations to apply on the host or pass through to guests which makes this a case by case decision.
- Some features might come in different generations like the older virt-ssbd and the newer and improved amd-ssbd. Yet as a hypervisor one doesn’t always know what the guest can exploit, so better pass both.
- On one hand some of them like ssbd as an example are available but usually not used. But while that is true for Ubuntu other guests might want (or even need) to handle that differently. Therefore as a hypervisor it is usually recommended to better pass more than less of those features (security point of view).
- On the other hand if you have mixed hardware in your server farm and need to consider migrations you might want to find a common denominator and only pass those features to the guest (security vs manageability trade-off)
- There are features which are not security features per se, but help to lessen the performance impact of a mitigation. An example of such would be pcid. For quite some time this feature was considered unimportant, so it is missing in the predefined models of Westmere, SandyBridge, and IvyBridge.
- Please note that some features can not be supported by all CPUs, for example pcid available on some, but not all Westmere CPUs. The same applies to different microcode levels.
With all that in mind - and considering that the list of features (and related vulnerabilities) seems to keep growing - it is worth to take a regular look at the recent:
Consider all that and map it to your hosting scenario to come up with a list of cpu features that you want/need to enable. Then look below how to do so with QEMU/KVM or Libvirt.
IMPORTANT: Even if you have a configuration - for example using host-passthrough - that does not need a configuration change, still guests needs to be fully shut down and restarted to pick up the new feature flags.
QEMU/KVM
From QEMUs point of view the CPU feature are just feature bits to pass to the guest. Initially CPU models with suffixes were added like -IBPB for AMD and -IBRS for intel. But that only covered the core features needed for meltdown. With the growing amount of related features and flags that was no more done. For example ssbd is not part of it nor are more recent flaws like md-clear for MDS.
Due to that you most likely need to modify the definition of your virtual CPU that is presented to your guest. The following illustrates how to do so at the example of the virt-ssbd feature. But all others would work the same way.
You can check if the host system has the feature used to mitigate an issue with: Note: This is just about having the feature. If you are interested in the current status of mitigations see the section Active Mitigations above.
$ grep 'virt-ssbd' /proc/cpuinfo flags : ... virt-ssbd
If the above is true then the virt-ssbd feature will automatically be passed to the guest when using the CPU model host. For all other CPU models the feature needs to be added explicitly. For example if before you had used the CPU model EPYC the respective part of the command line would then have look like:
-cpu EPYC,+virt-ssbd
Libvirt
As with QEMU above the following illustrates how to enable a CPU feature at the example of the virt-ssbd feature. But again all others would work the same way.
You can check your stack of Firmware, Kernel, QEMU and Libvirt is ready to expose the virt-ssbd flag to guests by checking the capabilities.
$ virsh domcapabilities kvm | grep -- 'virt-ssbd'
<feature policy='require' name='virt-ssbd'/>
If the above is true then the virt-ssbd feature will automatically be passed to the guest in the CPU modes host-passthrough and host-model.
In all other cases the definition of the CPU that is presented to the guest needs to be modified. You can do so in the guests CPU element. While the rest of the CPU model specification depends on your case, adding the virt-ssbd feature is the same and will look like
<cpu ... <feature policy='require' name='virt-ssbd'/> </cpu>
Timeline
- 2017 Nov 09: the Ubuntu Security team is notified by Intel under NDA
- 2017 Nov 20: the CRD is established as 2018-01-09
- 2017 Dec: the Ubuntu Security team receives notifications from additional silicon vendors about the impact to their products
- 2018 Jan 03: issue becomes public a few days before the CRD
- 2018 Jan 04: Canonical publicly communicates the planned update schedule
- 2018 Jan 04: Mozilla releases timing attack mitigations
- 2018 Jan 05: Ubuntu Firefox updates are made available in USN 3516-1
- 2018 Jan 07: Candidate kernels are beginning to be made available for testing at ppa:canonical-kernel-team/pti. This initial round will address CVE-2017-5754 (aka Meltdown or Variant 3) for x86_64. We will address CVE-2017-5715 and CVE-2017-5753 (aka Spectre or Variant 1 & 2) in a subsequent round. We will also address additional architectures in subsequent rounds.
- 2018 Jan 09: NVIDIA driver updates published, see USN-3521-1
- 2018 Jan 09: Ubuntu kernel updates are made available in USN 3522-1 (Ubuntu 16.04 LTS), USN 3523-1 (Ubuntu 17.10), USN 3522-2 (Ubuntu 14.04 LTS (HWE)), and USN-3524-1 (Ubuntu 14.04 LTS).
- 2018 Jan 09: Notification issued for livepatch users to reboot after applying kernel update.
- 2018 Jan 10: Updates for the pc-kernel snaps for Meltdown are released to the stable channel
- 2018 Jan 11: Updates to the intel-microcode package were released, see USN-3531-1
- Note: These updates were reverted on 2018 Jan 22
- 2018 Jan 11: Core image updates for amd64 and i386 are published
- 2018 Jan 12: Linux kernel version 4.13.0-29.32 for Artful 17.10 with Spectre mitigations is available in artful-proposed for testing.
- 2018 Jan 16: Linux kernel version 4.4.0-111.134 for 16.04 and 3.13.0-140.189 for 14.04 with Spectre mitigations is available in the respective -proposed pocket for testing.
- 2018 Jan 17: Linux kernel version 4.13.0-30.33 for Ubuntu Bionic with Spectre mitigations is available in the bionic-proposed pocket for testing.
- 2018 Jan 22: Previous updates to the intel-microcode package were reverted at Intel’s request, see USN-3531-2
- 2018 Jan 22: Ubuntu kernel updates addressing all three vulnerabilities (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754) across amd64, ppc64el and s390x are released in USN-3541-1 (Ubuntu 17.10), USN-3540-1 (Ubuntu 16.04 LTS), USN-3541-2 (Ubuntu 16.04 LTS (HWE)), USN-3542-1 (Ubuntu 14.04 LTS) and USN-3540-2 (Ubuntu 14.04 LTS (HWE)).
- 2018 Jan 22: Ubuntu Cloud Images have been released with Spectre kernel mitigations
- 2018 Feb 07: QEMU and libvirt security updates published to expose Spectre variant 2 mitigations to guests
- 2018 Feb 21: Ubuntu kernel update addressing Spectre for x86 for Ubuntu 12.04 ESM in USN 3580-1
- 2018 Feb 21: Ubuntu kernel updates built with retpoline compiler options for x86 to mitigate Spectre v2 are released USN 3581-1 (Ubuntu 17.10), USN 3582-1 (Ubuntu 16.04 LTS), USN 3581-2 (Ubuntu 16.04 LTS (HWE)), USN 3582-2 (Ubuntu 14.04 LTS (HWE))
- 2018 Feb 21: gcc packages supporting retpoline options for x86 published to Ubuntu 17.10, Ubuntu 16.04 LTS, and Ubuntu 14.04 LTS
- 2018 Feb 21: Ubuntu kernel update addressing meltdown for ppc64el for Ubuntu 14.04 LTS in USN 3583-1
- 2018 Feb 22: Ubuntu Cloud Images have been released with retpoline compiled kernels for amd64 and i386 for Ubuntu 17.10 and Ubuntu 16.04 LTS
- 2018 Mar 9: Ubuntu kernel update addressing spectre for amd64 and i386 Ubuntu 14.04 LTS in USN 3594-1
- 2018 Mar 13: intel-microcode 20180312 updates are made available in the ubuntu-security-proposed PPA and uploaded to Ubuntu Bionic
- 2018 Mar 15: Ubuntu kernel updates for 4.13 and 4.13 HWE released with mitigations for arm 64, see USN-3597-2
- 2018 Mar 29: intel-microcode 20180312 released, see USN-3531-3
- 2018 May 29: amd64-microcode made available for testing in the ubuntu-security-proposed PPA
- 2018 Jun 20: amd64-microcode updates released, see USN-3690-1
- 2018 Jul 05: amd64-microcode update released fixing regression, see USN-3690-2