Re: Call for testing: updates to address today's CPU/kernel vulnerability

[Justin Forbes]

tl;dr:
We are fixing things as quickly as we can safely do so. The fixes will
be ongoing, keep testing and installing new kernels as they appear!

On Sat, Jan 6, 2018 at 1:32 PM, Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Adam Williamson <adamwill(a)fedoraproject.org&gt;
> said:
> > * If the fix does cause problems on your hardware, you can disable it
> > by booting with the kernel parameter 'nopti'.
>
>  So, on RHEL/CentOS kernels, there are three new entries in
>  /sys/kernel/debug/x86; ibpb_enabled, ibrs_enabled, and pti_enabled.  I
>  don't see these on the Fedora kernel.
>
>  Are these variables something added by Red Hat to their kernel,
>  something that will be added to Fedora, etc.?  They are useful to see
>  exactly what fix(es) are being applied, as well as to have a runtime way
>  to enable/disable them. 
These do not exist in Fedora yet. For KPTI, the feature is
implemented, but there isn't a debugfs entry.  Variant 2 Spectre
mitigation has a couple of proposed solutions. IBRS and retpoline are
both being discussed upstream, and the end result will likely be a
combination of the 2.  Unfortunately both have external requirements.
Retpoline requires GCC patches, and microcode updates for some CPUs.
IBRS requires microcode updates. While RHEL has done quite a bit of
testing with IBRS in their kernels, Fedora moves a lot quicker and
current Fedora kernels are substantially different from the current
RHEL kernels. Additionally, while RHEL was given microcode to ship
with these updates, Intel has not released them upstream  (soon I am
told). It is entirely possible that the patches floating around
upstream have not been tested with the microcode that RHEL shipped.
Given that variant 2 is difficult (not impossible) to attack, we have
been waiting to see what we can ship, when microcode is available and
GCC updates are available.  I can assure you that I have spending
pretty much all of my time tracking upstream, testing patch sets, and
doing what I can to make sure we have mitigations for all 3 variants
in place as quickly as possible.
Today's build of rawhide contains mitigation for variant 1 of spectre
and variant 3 (meltdown) for x86_64. Current stable Fedora kernels
contain mitigation for meltdown on x86_64 as well. Wednesday should
see a new kernel pushed to updates-testing with some bug fixes for the
meltdown mitigation (KPTI), and some mitigation for variant 1. I am
hoping to also get some meltdown coverage for other architectures in
that update. While I would love to see some variant 2 coverage as
well, it is unlikely in the Wednesday time frame.  If it is possible,
I will include those as well, but even then, it will not be the final
solution.  As soon as a solution is deemed ready, it will be pushed to
Fedora.

Justin

Call for testing: updates to address today's CPU/kernel vulnerability

[Matthew Miller]

On Mon, Jan 08, 2018 at 04:49:44PM -0600, Justin Forbes wrote:
>  combination of the 2.  Unfortunately both have external
> requirements.
>  Retpoline requires GCC patches, and microcode updates for some CPUs.
>  IBRS requires microcode updates. While RHEL has done quite a bit of 
Does this mean we should do a mass rebuild once those patches have
landed? We have a mass rebuild scheduled for Jan 31st (basically three
weeks from now). Is that too soon?

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

Call for testing: updates to address today's CPU/kernel vulnerability

[Matthew Miller]

On Mon, Jan 08, 2018 at 08:27:22PM -0500, Matthew Miller wrote:
>  > combination of the 2.  Unfortunately both have external
> requirements.
>  > Retpoline requires GCC patches, and microcode updates for some CPUs.
>  > IBRS requires microcode updates. While RHEL has done quite a bit of
>  
>  Does this mean we should do a mass rebuild once those patches have
>  landed? We have a mass rebuild scheduled for Jan 31st (basically three
>  weeks from now). Is that too soon? 
Or are the GCC changes just needed for the kernel itself?

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader