On 02/21/2018 08:40 PM, Antoine Beaupré wrote: > Hi, > > Trying to do a recap here to update the wiki page correctly: > > https://wiki.debian.org/DebianSecurity/SpectreMeltdown > > See if you can fill in the blanks I've found...
(Disclaimer: not involved in all of in any capacity on the Debian side besides testing the preview gcc packages for downstream usage, so please take with a grain of salt ;) I don't know any details about non-x86, so refraining from commenting too much on those parts) > > Spectre v2 > ---------- > > My understanding of retpoline is that it was designed to fix spectre v2 > (CVE-2017-5715), yet it's not clear to me the fix is actually complete > without firmware updates. Do we have a clear status on that? retpoline fixes most avenues for v2 exploitation on most affected hardware on the kernel side. some areas (mainly KVM related) require IBPB for complete protection, which is a CPU feature provided by microcode updates for (some) recent Intel and AMD hardware. skylake and later Intel CPUs require additional work to prevent attacks via the RSB, which is a stack for return addresses which when empty, falls back to the branch predictor, which can be trained by an attacker. they are also the only platforms where you need IBRS if you have a retpolined kernel. > On Ubuntu's side, they claim it requires cpu-level firmware updates, > even though they seem to be in the process of rebuilding kernels and > userspace (at least in 18.04LTS and parts of the other releases) with > retpoline, so I'm not sure where we stand with this: > > https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown#Current_Status retpoline (and RSB stuffing and IBRS on Skylake+) solve most of the kernel issues, IBPB takes care of the rest. Qemu and other hypervisors also need support for passing through the required spec_ctrl/ibrs/ibpb CPU features to virtual CPUs in order to allow guest operating systems to decide the correct mitigation. this is obviously horrible if mixing Skylake+ with older CPUs, since the required and possible mitigations on each platform might not have an intersecting set that allows complete mitigiation (yay!). > We seem to have retpoline backported for GCC 4.9 now and work being done > to backport that or the patches back into wheezy. But what about > stretch/buster? Are we expecting an archive rebuild with retpoline? Is > so, which suites and when? don't know anything about any rebuild plans in Debian, but patched GCC 6 should be available soon in Stretch, buster/sid have gcc 7.3 which already contains the needed patches upstream. rebuilding user space makes sense to prevent v2 attacks between user space processes IMHO, but it costs performance (especially for programs doing lots of indirect calls) and of course would be a massive effort with lots of potential for regressions. > > Spectre v1 > ---------- > > And what about Specret v1? It's currently marked as unfixed in the > kernel: > > https://security-tracker.debian.org/tracker/CVE-2017-5753 > > What are the expected mitigations here? I see that 4.15.4-1 is marked as > fixed for that, but it's unclear to me if that trickles down to all > userspace, considering the scope... the fix for v1 is basically inserting serializing instructions in the right places. on the kernel side, most of those have been found using static analysis tools (with non-public rules or even tool chains, which will hopefully change in the future). those patches should trickle down to earlier stable kernels in subsequent releases (some of them already have). user space programs that want to protect against v1 need to carefully do the same analysis, and insert serializing instructions in the right places as well. this will take a lot of time, and lots of projects probably won't undergo this effor anytime soon. even deciding which instructions to insert on which platform was quite a mess, and might chagne again in future hardware generations. > Meltdown > -------- > > We currently say that only amd64 is mitigated for Meltdown in the wiki - > is there work being done in the kernel to try and fix this in other > architectures? Or is the intersection of "vulnerable design + exotic > architecture" too small to bother? there are threads discussing porting it to i386 IIRC, arm64 has a patch set as well (with various degrees of being applied upstream and in distro kernels). also, for Meltdown (v3) mitigation you absolutely want to pass through the PCID flag to your VMs in case your physical CPUs (i.e., Intel since Westmere) and guest OS support it. it makes a whole world of difference for syscall-heavy workloads. passing this through also requires support from your hypervisor stack. it's also worth noting that KPTI in 3.16 (Jessie), 4.4 (Ubuntu 16.04), 4.9 (Stretch) is vastly different from KPTI in 4.13+ (Ubuntu 17.10, Ubuntu 16.04 HWE, current latest upstream LTS, current latest upstream stable). the former uses an adapted version of the original KAISER patch set, the latter use a much more heavily adapted mainline version. upstream stable (Greg K-H)'s recommendation is thus to use 4.14 or later if at all possible - it's likely that not all subsequent fixes/improvements are easily backportable to the KAISER-based kernels (IMHO this applies to performance, regression and security fixes). this got kinda long, sorry ;)
