<div dir="ltr"><div><div>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. </div><div><br></div><div></div><div>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.<br><br></div>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).<br><br></div>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.<br><br>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.<br><div><div><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 22, 2018 at 11:47 AM, Khalid Baheyeldin <span dir="ltr"><<a href="mailto:kb@2bits.com" target="_blank">kb@2bits.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>And now, it is Intel's Microcode that causes problems, and there is a regression update for it. <br><br><a href="https://usn.ubuntu.com/usn/usn-3531-2/" target="_blank">https://usn.ubuntu.com/usn/<wbr>usn-3531-2/</a><br><br></div>This whole Meltdown/Spectre is a horrible mess.<br></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sat, Jan 20, 2018 at 1:59 PM, Khalid Baheyeldin <span dir="ltr"><<a href="mailto:kb@2bits.com" target="_blank">kb@2bits.com</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 ...<br><br>First it was Meltdown fixes and Ubuntu: booting issues.<br>Now it is Spectre and RedHat: booting issues.<br><br>This is why many of us fled the Microsoft ecosystem: lack of stability and predictability. <br><br>Once things are stable again, I will apply the kernel updates as I have been doing for years past ... <br><br><a href="https://linux.slashdot.org/story/18/01/20/178204/red-hat-reverts-spectre-patches-to-address-boot-issues" target="_blank">https://linux.slashdot.org/sto<wbr>ry/18/01/20/178204/red-hat-rev<wbr>erts-spectre-patches-to-addres<wbr>s-boot-issues</a><br></div><div class="m_2607511831521220280HOEnZb"><div class="m_2607511831521220280h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 12, 2018 at 10:25 AM, Khalid Baheyeldin <span dir="ltr"><<a href="mailto:kb@2bits.com" target="_blank">kb@2bits.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Jan 12, 2018 at 10:08 AM, Chris Irwin <span dir="ltr"><<a href="mailto:chris@chrisirwin.ca" target="_blank">chris@chrisirwin.ca</a>></span> wrote:<br></span><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Wed, Jan 10, 2018 at 9:24 AM, Khalid Baheyeldin <span dir="ltr"><<a href="mailto:kb@2bits.com" target="_blank">kb@2bits.com</a>></span> wrote:<br></span><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Wow, the differences are significant ... <br><br>For a dedicated server, the fix for Meltdown is not really needed, since no one else is accessing RAM by exploiting the speculative execution. <br><br>So I am thinking of pinning the kernel to what it is on those machines.<br></div></div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div></span><div>This is only temporary until things settle down. Will avoid the failed reboots and such.<br> <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div></div></div></div></blockquote><div><br></div></span><div>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. <br><br></div><div>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. <br><br></div><div>So disabling KPTI is good for those two cases. <br><br></div><div>But again, I will wait until things settle down. <br></div><span><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div><br></div></span><div>If there is remote code execution, then it is a serious problem on its own, and the machine will be owned regardless. </div></div><span><br>-- <br><div class="m_2607511831521220280m_8239178983332004947m_-4964741724621935777gmail_signature" data-smartmail="gmail_signature">Khalid M. Baheyeldin<br><a href="http://2bits.com" target="_blank">2bits.com</a>, Inc.<br>Fast Reliable Drupal<br>Drupal optimization, development, customization and consulting.<br>Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra<br>Simplicity is the ultimate sophistication. -- Leonardo da Vinci<br>For every complex problem, there is an answer that is clear, simple, and wrong." -- H.L. Mencken<br></div>
</span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="m_2607511831521220280m_8239178983332004947gmail_signature" data-smartmail="gmail_signature">Khalid M. Baheyeldin<br><a href="http://2bits.com" target="_blank">2bits.com</a>, Inc.<br>Fast Reliable Drupal<br>Drupal optimization, development, customization and consulting.<br>Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra<br>Simplicity is the ultimate sophistication. -- Leonardo da Vinci<br>For every complex problem, there is an answer that is clear, simple, and wrong." -- H.L. Mencken<br></div>
</div>
</div></div></blockquote></div></div></div><div><div class="h5"><br><br clear="all"><br>-- <br><div class="m_2607511831521220280gmail_signature" data-smartmail="gmail_signature">Khalid M. Baheyeldin<br><a href="http://2bits.com" target="_blank">2bits.com</a>, Inc.<br>Fast Reliable Drupal<br>Drupal optimization, development, customization and consulting.<br>Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra<br>Simplicity is the ultimate sophistication. -- Leonardo da Vinci<br>For every complex problem, there is an answer that is clear, simple, and wrong." -- H.L. Mencken<br></div>
</div></div></div>
<br>______________________________<wbr>_________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a><br>
<a href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" rel="noreferrer" target="_blank">http://kwlug.org/mailman/<wbr>listinfo/kwlug-disc_kwlug.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Chris Irwin<br><<a href="mailto:chris@chrisirwin.ca" target="_blank">chris@chrisirwin.ca</a>></div></div>
</div>