[kwlug-disc] Meltown fix for Linux kernel

[Chris Irwin]

The Redhat issue was due to the intel microcode, as you mentioned. At least
on RHEL/CentOS/Fedora, this is not shipped in the kernel, but in a separate
package (microcode_ctl) which has no dependency on kernel version. So you
might be bitten by this even if you did pin your kernel.

Intel was the problem here again. They posted a microcode update to their
website in early January (which might be good, afaik), around the time of
the disclosure embargo lifting. However, they failed to mention that it was
different than the pre-release microcode given to partners in December,
which everybody was urgently trying to ship out. Of course there's no
changelogs in any of these packages, and this was all determined afterwards
by observing file checksums being different. Not ideal.

When Redhat reverted the most recent microcode update, they suggested that
if you want updated microcode, get it from Intel directly. (I'd imagine
they'll again update it once tested, since they haven't changed their
policy on shipping microcode).

VMware has also pulled some of their patches. I'm sure other vendors as
well, but those are the two we use in-house here.

Apparently some hardware vendors packaged updated system firmware
(BIOS/UEFI) that contained the new microcode, so you're kind of screwed by
having a pro-active hardware vendor. Go figure.



On Mon, Jan 22, 2018 at 11:47 AM, Khalid Baheyeldin <kb at 2bits.com> wrote:

> And now, it is Intel's Microcode that causes problems, and there is a
> regression update for it.
>
> https://usn.ubuntu.com/usn/usn-3531-2/
>
> This whole Meltdown/Spectre is a horrible mess.
>
> On Sat, Jan 20, 2018 at 1:59 PM, Khalid Baheyeldin <kb at 2bits.com> wrote:
>
>> The link below is exactly why I chose to have a hold on the kernel
>> packages for my bare metal desktops and servers until all this mess is
>> sorted out, and we have stability back again, as we are used to ...
>>
>> First it was Meltdown fixes and Ubuntu: booting issues.
>> Now it is Spectre and RedHat: booting issues.
>>
>> This is why many of us fled the Microsoft ecosystem: lack of stability
>> and predictability.
>>
>> Once things are stable again, I will apply the kernel updates as I have
>> been doing for years past ...
>>
>> https://linux.slashdot.org/story/18/01/20/178204/red-hat-rev
>> erts-spectre-patches-to-address-boot-issues
>>
>> On Fri, Jan 12, 2018 at 10:25 AM, Khalid Baheyeldin <kb at 2bits.com> wrote:
>>
>>>
>>>
>>> On Fri, Jan 12, 2018 at 10:08 AM, Chris Irwin <chris at chrisirwin.ca>
>>> wrote:
>>>
>>>> On Wed, Jan 10, 2018 at 9:24 AM, Khalid Baheyeldin <kb at 2bits.com>
>>>> wrote:
>>>>
>>>>> Wow, the differences are significant ...
>>>>>
>>>>> For a dedicated server, the fix for Meltdown is not really needed,
>>>>> since no one else is accessing RAM by exploiting the speculative execution.
>>>>>
>>>>> So I am thinking of pinning the kernel to what it is on those machines.
>>>>>
>>>>
>>>> Don't pin your kernel to avoid the KPTI patches. All future kernels,
>>>> likely forever (considering linux still supports 486 CPUs), will carry this
>>>> functionality to be used with affected CPUs. Pinning your kernel will only
>>>> serve to prevent you from getting other security-related kernel updates.
>>>>
>>>
>>> This is only temporary until things settle down. Will avoid the failed
>>> reboots and such.
>>>
>>>
>>>> If you really, *really* want to disable KPTI, put "nopti" on the kernel
>>>> command-line. I obviously don't recommend this. Unless your typical
>>>> workload resembles a synthetic benchmark, the performance impact will
>>>> likely be negligible.
>>>>
>>>
>>> Meltdown and Spectre only affect machines that run a load from different
>>> parties. Think about a physical server running virtualized instances. One
>>> instance can sneakily look at the memory of another instance.
>>>
>>> But on a dedicated server, or my laptop, there is no such risk. Yes, in
>>> theory there can be, but if someone has managed to execute programs on such
>>> machines behind my back, then KPTI or not, there are bigger issues.
>>>
>>> So disabling KPTI is good for those two cases.
>>>
>>> But again, I will wait until things settle down.
>>>
>>>
>>>>
>>>> The security threat posted by meltdown and spectre is serious, even if
>>>> you don't see an attack vector. Any unrelated remote code execution exploit
>>>> (in apache, etc) could potentially in turn exploit meltdown and spectre.
>>>>
>>>
>>> If there is remote code execution, then it is a serious problem on its
>>> own, and the machine will be owned regardless.
>>>
>>> --
>>> Khalid M. Baheyeldin
>>> 2bits.com, Inc.
>>> Fast Reliable Drupal
>>> Drupal optimization, development, customization and consulting.
>>> Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
>>> Simplicity is the ultimate sophistication. --   Leonardo da Vinci
>>> For every complex problem, there is an answer that is clear, simple, and
>>> wrong." -- H.L. Mencken
>>>
>>
>>
>>
>> --
>> Khalid M. Baheyeldin
>> 2bits.com, Inc.
>> Fast Reliable Drupal
>> Drupal optimization, development, customization and consulting.
>> Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
>> Simplicity is the ultimate sophistication. --   Leonardo da Vinci
>> For every complex problem, there is an answer that is clear, simple, and
>> wrong." -- H.L. Mencken
>>
>
>
>
> --
> Khalid M. Baheyeldin
> 2bits.com, Inc.
> Fast Reliable Drupal
> Drupal optimization, development, customization and consulting.
> Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
> Simplicity is the ultimate sophistication. --   Leonardo da Vinci
> For every complex problem, there is an answer that is clear, simple, and
> wrong." -- H.L. Mencken
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>
>


-- 
Chris Irwin
<chris at chrisirwin.ca>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20180122/b3f34ac6/attachment.htm>