[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: current status of spectre/meltdown



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 ;)


Reply to: