[kwlug-disc] Meltown fix for Linux kernel

Ron Singh ronsingh149 at gmail.com
Sun Jan 21 11:53:47 EST 2018


Yes, as a relative newbie to the Linux world(one year), I was pretty
dismayed with the developments in the last few weeks.

Running LM allows me to have pretty easy and complete control over the
kernel installed/used.

I just updated from 4.4.0.97 to 4.4.0.104 today.
The LM repo shows 4.4.0.109 available since the "108" release caused issues
for quite a few users.

I am sticking with a self-imposed 90-day  update cycle to the 4.4 kernel if
there is a really compelling reason(from reading the changelog) to update.
If no "urgency=medium/high" are listed i nthe changelog, I will just ignore
the kernel updates.

I know delaying kernel updates can potentially be quite dangerous and LM
has been criticized for their Software Updater default update settings, but
I prefer it simply to have a better shot at the best system stability.

I am very averse to a re-install as I am lazy to the core. and not keen on
dealing with the spectre of a total system meltdown due to applying
kernel/firmware changes as soon as they appear. Sorry...just had to do it.


Thanks,

Ron Singh
"in transit, via mobile comm device"

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-
> 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
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20180121/4b1e1738/attachment.htm>


More information about the kwlug-disc mailing list