[kwlug-disc] Meltown fix for Linux kernel

[Khalid Baheyeldin]

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-reverts-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20180120/37b2d2bf/attachment.htm>