Response to Meltdown and Spectre

[Sujit K M]

> Meltdown (CVE-2017-5754)
> ~~~~~~~~~~~~~~~~~~~~~~~~
> In terms of priority, the first step is to mitigate against the Meltdown
> attack (CVE-2017-5754, cited as variant 3 by Project Zero). Work for
> this is ongoing, but due to the relatively large changes needed, this is
> going to take a little while. We are currently targeting patches for
> amd64 being dev complete this week with testing probably running into
> next week. From there, we hope to give it a short bake time before
> pushing it into the 11.1-RELEASE branch. Additional work will be
> required to bring the mitigation to 10.3-RELEASE and 10.4-RELEASE.
>
> The code will be selectable via a tunable which will automatically turn
> on for modern Intel processors and off for AMD processors (since they
> are reportedly not vulnerable). Since the fix for Meltdown does incur a
> performance hit for any transition between user space and kernel space,
> this could be rather impactful depending on the workload. As such, the
> tunable can also be overridden by the end-user if they are willing to
> accept the risk.
>
> Initial work can be tracked at https://reviews.freebsd.org/D13797.
> Please note this is a work in progress and some stuff is likely to be
> broken.
>
> Spectre (CVE-2017-5753 and CVE-2017-5715)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> When it comes to the Spectre vulnerabilities, it is much harder to sort
> these out. Variant 1 (CVE-2017-5753) is going to require some static
> analysis to determine vulnerable use cases that will require barriers to
> stop speculation from disclosing information it shouldn't. While we
> haven't done the analysis to determine where we are vulnerable, the
> number of cases here are supposed to be pretty small. Apparently there
> have been some Coverity rules developed to help look for these, but we
> are still evaluating what can be done here.
>
> The other half of Spectre, variant 2 (CVE-2017-5715) is a bit trickier
> as it affects both normal processes and bhyve. There is a proposed patch
> for LLVM (https://reviews.llvm.org/D41723) that introduces a concept
> called 'retpoline' which mitigates this issue. We are likely to pull
> this into HEAD and 11-STABLE once it hits the LLVM tree. Unfortunately,
> the currently supported FreeBSD releases are using older versions of
> LLVM for which we are not sure the LLVM project will produce patches. We
> will be looking at the feasibility to backport these patches to these
> earlier versions.
>
> There are CPU microcode fixes coming out when in concert with OS changes
> would also help, but that's a bit down the road at the moment.
>
>
> If anything significantly changes I will make additional posts to
> clarify as the information becomes available.
>
> Best regards,
> Gordon Tetlow
> with security-officer hat on

>From my understanding what is happening is that an array overflow is happening.
Can't it be handled more generically.

-- 
-- Sujit K M

blog(http://kmsujit.blogspot.com/)