<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <font size="-1">Hello Phil,<br>
      <br>
      I appreciate the reply...  please see inline for a few questions..<br>
      <br>
    </font><br>
    <blockquote
      cite="mid:d6350c6d-7ca0-e648-4deb-48e255f30e06@elrepo.org"
      type="cite"><a class="moz-txt-link-freetext" href="https://elrepo.org/bugs/view.php?id=810">https://elrepo.org/bugs/view.php?id=810</a>
      <br>
      <br>
      It looks like it was fixed in 4.4.110
      <br>
    </blockquote>
    <br>
    Excellent, thank you.  One thing I've struggled to *simply* figure
    out is what fixes get into what releases.  For example, what release
    of the 3.2 or 3.16 LTS kernels have this fix?  Sure, I can find the
    git commit in that branch that has the fix BUT it's not clear how to
    see what commits are in what release.  Maybe there is a simple way
    to do this?<br>
    <br>
    <br>
    <blockquote
      cite="mid:d6350c6d-7ca0-e648-4deb-48e255f30e06@elrepo.org"
      type="cite">
      Generally though, users should run the latest release, built from
      the latest upstream kernel sources to ensure they have all the
      latest patches.
      <br>
    </blockquote>
    <br>
    Absolutely understood but that's not always possible in a quick turn
    around.  I'm also waiting to really hear what the exploitability of
    this is going to be.  Sounds like web browser vendors are de-tuning
    their JavaScript's timing engines to avoid this but what else from a
    practical point of view is needed to avoid remote exploitability? 
    Time will tell I suppose.<br>
    <br>
    <br>
    <blockquote
      cite="mid:d6350c6d-7ca0-e648-4deb-48e255f30e06@elrepo.org"
      type="cite">Yes. As I understand this package applies microcode
      patches to the CPU regardless of the running kernel. I would also
      check with hardware vendors for any bios updates that also address
      the issue.
      <br>
    </blockquote>
    <br>
    Excellent, thank you though you bring up an interesting point on the
    BIOS.  In my experience, there is little to zero chance of getting
    that to happen on older motherboards by even the best vendors like
    Intel, Asus, etc.  I'm curious though, if the newer microcode can be
    installed by the OS, why do we need to worry about the BIOS?  I
    generally don't have enough understanding of the initialization
    handoff between the BIOS and the Linux kernel but I was under the
    impression Linux doesn't need much of the legacy BIOS or modern UEFI
    equivalents anymore.<br>
    <br>
    <br>
    <blockquote
      cite="mid:d6350c6d-7ca0-e648-4deb-48e255f30e06@elrepo.org"
      type="cite">
      As you are aware, EL5 is EOL, so if still running should not be
      internet facing as there will be many other security risks besides
      meltdown and spectre. But to address these issues specifically,
      one should run the latest release of a supported kernel branch,
      check for any vendor bios updates and apply the latest microcode
      updates. For the latter, you could either look to build an updated
      package containing the latest upstream microcode from Intel, or
      you can download the microcode files from Intel, unpack the
      intel-ucode folder into /usr/lib/firmware/intel-ucode/ overwriting
      the files provided by the microcode_ctl package and manually force
      an update without rebooting by doing:
      <br>
    </blockquote>
    <br>
    Thank you for the details there as well.  Two things I'm looking
    for:<br>
    <br>
       - Is it possible to still find the last SRPMs that were used for
    ElRepo's LT kernels?  If I have that, I can hopefully shoehorn in a
    newer kernel (maybe 3.2 or 3.16) with all the required fixes.  <br>
    <br>
       - If I can also find the SRPM for the last Centos 5 microcode_ctl
    package ( <a class="moz-txt-link-freetext"
href="https://www.centos.org/docs/5/html/5.5/Technical_Notes/microcode_ctl.html">https://www.centos.org/docs/5/html/5.5/Technical_Notes/microcode_ctl.html</a>
    ) , maybe I can load in the new Intel firmware into that too.  If
    not, maybe shoehorning the required firmware into the kernel package
    itself might work ( <a class="moz-txt-link-freetext"
href="https://www.dotslashlinux.com/2017/04/30/building-intel-cpu-microcode-updates-directly-into-the-linux-kernel/">https://www.dotslashlinux.com/2017/04/30/building-intel-cpu-microcode-updates-directly-into-the-linux-kernel/
      )</a><br>
    <br>
    <br>
    <blockquote
      cite="mid:d6350c6d-7ca0-e648-4deb-48e255f30e06@elrepo.org"
      type="cite">
      echo 1 &gt; /sys/devices/system/cpu/microcode/reload
      <br>
    </blockquote>
    <br>
    Cool trick and I never imagined you could do that hot like that. 
    Impressive!<br>
    <br>
    --David<br>
  </body>
</html>