Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Quick Links


Categories

In this Discussion

› › Your Intel x86 CPU is Deeply Flawed (Meltdown/Spectre) - Page 14
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Your Intel x86 CPU is Deeply Flawed (Meltdown/Spectre)

1…1112141617…19

Comments

  • jackbjackb Member, Host Rep
    edited January 2018

    @Zerpy said:
    I patched the first part on all my boxes, pti enabled, ibrs and ibpb seems to be disabled - despite having the recent microcode loaded and the recent CL7 kernel which according to changelogs fixes all 3 of them, so.. either microcode for the CPU's (E5-v4) isn't yet available, or this is jackshit.

    However, I see about no performance hit with pti at least, no increased response times nor increased CPU load in a rather high traffic shared hosting environment.
    If ibrs and ibpb whenever available will cause a hit.. We'll see :-D

    I have a feeling for RHEL7 based systems you need to set the microcode service to start on boot. 6 based looks like it works via udev rules instead. Worth checking out the service if you didn't already.

  • eva2000eva2000 Veteran
    edited January 2018

    Zerpy said: I patched the first part on all my boxes, pti enabled, ibrs and ibpb seems to be disabled - despite having the recent microcode loaded and the recent CL7 kernel which according to changelogs fixes all 3 of them, so.. either microcode for the CPU's (E5-v4) isn't yet available, or this is jackshit.

    same for my i7 4790k https://community.centminmod.com/posts/57896/

    2017-01-27 is last date for microcode updates for i7 4790K so there are no more recent microcode updates available for my i7 4790K yet.

    journalctl -b --no-pager | grep microcode | sed -e "s|$(hostname)|hostname|g"
Jan 05 14:44:46 hostname kernel: microcode: microcode updated early to revision 0x22, date = 2017-01-27
Jan 05 14:44:46 hostname kernel: microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x22
Jan 05 14:44:46 hostname kernel: microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x22
Jan 05 14:44:46 hostname kernel: microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x22
Jan 05 14:44:46 hostname kernel: microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x22
Jan 05 14:44:46 hostname kernel: microcode: CPU4 sig=0x306c3, pf=0x2, revision=0x22
Jan 05 14:44:46 hostname kernel: microcode: CPU5 sig=0x306c3, pf=0x2, revision=0x22
Jan 05 14:44:46 hostname kernel: microcode: CPU6 sig=0x306c3, pf=0x2, revision=0x22
Jan 05 14:44:46 hostname kernel: microcode: CPU7 sig=0x306c3, pf=0x2, revision=0x22
Jan 05 14:44:46 hostname kernel: microcode: Microcode Update Driver: v2.01 <[email protected]>, Peter Oruba
Jan 05 14:44:47 hostname systemd[1]: Starting Load CPU microcode update...
Jan 05 14:44:48 hostname systemd[1]: Started Load CPU microcode update.

    majority of intel microcode updates are scheduled for next week AFAIK

    jackb said: I have a feeling for RHEL7 based systems you need to set the microcode service to start on boot. 6 based looks like it works via udev rules instead. Worth checking out the service if you didn't already.

    on CentOS 7.4 64bit, microcode updates happened with or without service enabled on boot, but i set microcode service to boot anyway

    Thanked by 1Zerpy
  • ZerpyZerpy Member
    edited January 2018

    @eva2000 said:

    Zerpy said: I patched the first part on all my boxes, pti enabled, ibrs and ibpb seems to be disabled - despite having the recent microcode loaded and the recent CL7 kernel which according to changelogs fixes all 3 of them, so.. either microcode for the CPU's (E5-v4) isn't yet available, or this is jackshit.

    same for my i7 4790k https://community.centminmod.com/posts/57896/

    Glad to know I'm not the only one then :-D

    Meanwhile, can I ask, what output do you get from cat /sys/kernel/debug/x86/{ibpb_enabled,ibrs_enabled,pti_enabled} ?

    I assume the microcodes will arrive for ibpb and ibrs as well somewhere next week, because no matter what CPU I run (tested on like 15 different CPUs, different generations), ibpb and ibrs always stays zero even for CPUs where the microcode is up to date:

    Jan 05 22:02:51 hostname kernel: microcode: microcode updated early to revision 0xb000025, date = 2017-11-18
Jan 05 22:02:52 hostname kernel: microcode: CPU0 sig=0x406f1, pf=0x1, revision=0xb000025
Jan 05 22:02:52 hostname kernel: microcode: CPU1 sig=0x406f1, pf=0x1, revision=0xb000025
Jan 05 22:02:52 hostname kernel: microcode: CPU2 sig=0x406f1, pf=0x1, revision=0xb000025
  • SolusVMSolusVM Member, Host Rep

    FYI https://openvz.org/Download/kernel/rhel6/042stab127.2

  • eva2000eva2000 Veteran
    edited January 2018

    Zerpy said: Meanwhile, can I ask, what output do you get from cat /sys/kernel/debug/x86/{ibpb_enabled,ibrs_enabled,pti_enabled} ?

    0, 0, 1 respectively as microcode update not available yet

    Thanked by 1Zerpy
  • spycrab101spycrab101 Member

    Reading 40 bytes: Reading at malicious_x = 0xffffffffffdfebb8... Success: 0x54=’T’ score=2 Reading at malicious_x = 0xffffffffffdfebb9... Success: 0x68=’h’ score=2 Reading at malicious_x = 0xffffffffffdfebba... Success: 0x65=’e’ score=2 Reading at malicious_x = 0xffffffffffdfebbb... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffffffffffdfebbc... Success: 0x4D=’M’ score=2 Reading at malicious_x = 0xffffffffffdfebbd... Success: 0x61=’a’ score=2 Reading at malicious_x = 0xffffffffffdfebbe... Success: 0x67=’g’ score=2 Reading at malicious_x = 0xffffffffffdfebbf... Success: 0x69=’i’ score=2 Reading at malicious_x = 0xffffffffffdfebc0... Success: 0x63=’c’ score=2 Reading at malicious_x = 0xffffffffffdfebc1... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffffffffffdfebc2... Success: 0x57=’W’ score=2 Reading at malicious_x = 0xffffffffffdfebc3... Success: 0x6F=’o’ score=2 Reading at malicious_x = 0xffffffffffdfebc4... Success: 0x72=’r’ score=2 Reading at malicious_x = 0xffffffffffdfebc5... Success: 0x64=’d’ score=2 Reading at malicious_x = 0xffffffffffdfebc6... Success: 0x73=’s’ score=2 Reading at malicious_x = 0xffffffffffdfebc7... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffffffffffdfebc8... Success: 0x61=’a’ score=2 Reading at malicious_x = 0xffffffffffdfebc9... Success: 0x72=’r’ score=2 Reading at malicious_x = 0xffffffffffdfebca... Success: 0x65=’e’ score=2 Reading at malicious_x = 0xffffffffffdfebcb... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffffffffffdfebcc... Success: 0x53=’S’ score=2 Reading at malicious_x = 0xffffffffffdfebcd... Success: 0x71=’q’ score=2 Reading at malicious_x = 0xffffffffffdfebce... Success: 0x75=’u’ score=7 (second best: 0x05 score=1) Reading at malicious_x = 0xffffffffffdfebcf... Success: 0x65=’e’ score=7 (second best: 0x05 score=1) Reading at malicious_x = 0xffffffffffdfebd0... Success: 0x61=’a’ score=2 Reading at malicious_x = 0xffffffffffdfebd1... Success: 0x6D=’m’ score=2 Reading at malicious_x = 0xffffffffffdfebd2... Success: 0x69=’i’ score=2 Reading at malicious_x = 0xffffffffffdfebd3... Success: 0x73=’s’ score=2 Reading at malicious_x = 0xffffffffffdfebd4... Success: 0x68=’h’ score=2 Reading at malicious_x = 0xffffffffffdfebd5... Success: 0x20=’ ’ score=2 Reading at malicious_x = 0xffffffffffdfebd6... Success: 0x4F=’O’ score=2 Reading at malicious_x = 0xffffffffffdfebd7... Success: 0x73=’s’ score=2 Reading at malicious_x = 0xffffffffffdfebd8... Success: 0x73=’s’ score=2 Reading at malicious_x = 0xffffffffffdfebd9... Success: 0x69=’i’ score=2 Reading at malicious_x = 0xffffffffffdfebda... Success: 0x66=’f’ score=2 Reading at malicious_x = 0xffffffffffdfebdb... Success: 0x72=’r’ score=2 Reading at malicious_x = 0xffffffffffdfebdc... Success: 0x61=’a’ score=2 Reading at malicious_x = 0xffffffffffdfebdd... Success: 0x67=’g’ score=2 Reading at malicious_x = 0xffffffffffdfebde... Success: 0x65=’e’ score=2 Reading at malicious_x = 0xffffffffffdfebdf... Success: 0x2E=’.’ score=2 root@xxxxxxxx:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz

    On openVZ with an undisclosed provider.

  • sureiamsureiam Member
    edited January 2018

    @Maounique said:

    sureiam said: when they have been the only player.

    I don't recall that ever to have been the case. Virtually the only player, perhaps, i.e. having most market share by far, but the only player?

    99.4% marketshare in datacenter speaks for itself. That's single player by all accounts.

    sureiam said: Not to mention the 5% performance gains Intel has drop fed the market the past 9 years.

    There are objective factors in that, nobody can really break the laws of physics, albeit bending is possible...
    x86 is an old platform and has a lot of deadweight with it from 30-40 yers ago, maybe more.

    Sure you are limited by the node but let's look at AMDs launch of Ryzen and Eypc and the large core count. Intel's response finally the 8xxx series at 6 cores and 12thread was only the result of AMD Ryzen. It was not planned or announced before Ryzen stole sales.

    Then we have features. AMDs Memory Encryption technology in their new Eypc and Ryzen pro line processors. Are you telling me Intel couldn't come up with that?

    Intel drip fed the market chip advancements to maximize their profit. Make no doubt if AMD isn't supported despite finally having competitive products because people perceive Intel as the only choice which they now No longer are. Then we'll end up back where we were before ryzen.

    Or you can keep coming up for excuses for why a company with 20x the market cap of AMD couldn't do what AMD did with 5% the research as development resources...

    Thanked by 1default
  • sureiamsureiam Member

    @bsdguy said:

    @Clouvider said:
    Well, you don't start an in-facto monopoly business to stay competitive, do you ;p?

    Haha. But it's ugly. Look: What alternatives do people have? Jack and Joe could buy amd, yes, but will they throw away their computers and shell out 500 or 1000 bucks for new ones?
    Yes, companies could ... but will they do that? Nope, most won't.

    Now imagine intel comes up with a new product series that is about as fast as the current ones and "spectre-safe" and, say, just to make it more attractive offer a 50 or 100 bucks trade in deal.

    I think you've forgotten how convoluted the Intel platform has gotten. They released three different pin layouts and chipsets within this past year just to Keeup with AMD

  • adlyadly Veteran

    @spycrab101 interesting - it’s not surprising that OpenVZ is vulnerable but there doesn’t seem to be any news about providers updating the kernel despite an update now being available.

  • ZerpyZerpy Member

    @adly said:
    @spycrab101 interesting - it’s not surprising that OpenVZ is vulnerable but there doesn’t seem to be any news about providers updating the kernel despite an update now being available.

    There's no microcode for spectre yet - so rebooting twice within a week might suck ;)

  • gestiondbigestiondbi Member, Patron Provider

    @Zerpy said:

    @adly said:
    @spycrab101 interesting - it’s not surprising that OpenVZ is vulnerable but there doesn’t seem to be any news about providers updating the kernel despite an update now being available.

    There's no microcode for spectre yet - so rebooting twice within a week might suck ;)

    There is, depending hardware you have.

  • ZerpyZerpy Member
    edited January 2018

    @davidgestiondbi said:

    @Zerpy said:

    @adly said:
    @spycrab101 interesting - it’s not surprising that OpenVZ is vulnerable but there doesn’t seem to be any news about providers updating the kernel despite an update now being available.

    There's no microcode for spectre yet - so rebooting twice within a week might suck ;)

    There is, depending hardware you have.

    So.. please give a list of CPUs that actually has microcode available that fixes both variants of spectre - because none of the v5, v4, v3, v2 and vNothing I have actually has the microcode available that enables ibpb and ibrs.

    Let me check my E3-v6 if that has the microcode :-D

    So.. If I download the latest microcodes from Intel's website, use iucode_tool to see what's available for my CPU, then it reveals:

    # iucode_tool -tb -lS intel-ucode/*
iucode_tool: system has processor(s) with signature 0x000906e9
selected microcodes:
001: sig 0x000906e9, pf mask 0x2a, 2017-04-06, rev 0x005e, size 97280

    As you can see the microcode is from 2017-04-06 for model name : Intel(R) Xeon(R) CPU E3-1230 v6 @ 3.50GHz

    Now.. v6 is so new that it should probably have been released - some of the others, there's microcodes available that was made in november - however - none of those actually fixes both spectre variants.

    Even if you can mention a single CPU, that got microcodes for both variants, and a link to that specific microcode - then it would be good ;)

  • rdesrdes Member

    http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/intel-microcode_3.20171215.1_changelog

  • ZerpyZerpy Member

    @rdes said:
    http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/intel-microcode_3.20171215.1_changelog

    Sure - tell that to Ubuntu:
    http://archive.ubuntu.com/ubuntu/pool/main/i/intel-microcode/

    And tell it to CentOS, CloudLinux, Red Hat, Intel's own website

    If you download the microcodes directly from Intel ( https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?product=873 ) you'll not find any microcodes matching e.g. the v6 above other than the 2017-04-06.

    Now, if we take that specific deb package there, first then we'll have an available microcode:

    :~/mytm/lib/firmware# iucode_tool -tb -lS intel-ucode/*
iucode_tool: system has processor(s) with signature 0x000906e9
selected microcodes:
001: sig 0x000906e9, pf mask 0x2a, 2017-12-03, rev 0x007c, size 98304

    So the fact that Debian has a package with (possible) working microcodes, but ubuntu, RHEL based systems or intel didn't publish them

  • rdesrdes Member

    There's also some upgrade of microcode_ctl in CentOS and RHEL repos (microcode_ctl.x86_64 1:1.17-25.2.el6_9).

  • perennateperennate Member, Host Rep
    edited January 2018

    @Zerpy @rdes I posted this in the other thread, but according to https://github.com/hannob/meltdownspectre-patches#cpu-microcode RHEL, Debian, and others have pushed version 2017-12-15 that supposedly resolves Spectre variant 2, which is newer than the 2017-11-17 published on Intel's website. I don't know why Intel's website is not updated though.

    Edit: Zerpy said the update is not affecting many CPU models -- https://www.lowendtalk.com/discussion/comment/2601841/#Comment_2601841

    Thanked by 1vimalware
  • jackbjackb Member, Host Rep
    edited January 2018

    @rdes said:
    There's also some upgrade of microcode_ctl in CentOS and RHEL repos (microcode_ctl.x86_64 1:1.17-25.2.el6_9).

    I'm not sure how much use it will be. This is from that microcode_ctl package.

    [root@microcode ~]# iucode_tool -t d microcode.dat --write-all-named-to=test --date-after=2017-12-01 iucode_tool: No valid microcodes were selected, nothing to do...

  • NeoonNeoon Community Contributor, Veteran
    edited January 2018

    Uh, another flaw, this time AMD:

    https://www.theregister.co.uk/2018/01/06/amd_cpu_psp_flaw/

    Intel was aware of that issue since 2012 not 6 months ago:

    That CPU usage, #rip

    https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update

    Thanked by 1netomx
  • NeoonNeoon Community Contributor, Veteran

    Thanked by 5WSS Francisco vimalware Hxxx layfon
  • qrwteyrutiyoupqrwteyrutiyoup Member

    Thanked by 2gestiondbi vimalware
  • rm_rm_ IPv6 Advocate, Veteran
    edited January 2018

    I installed the latest Intel microcode package in Debian:

    intel-microcode                    3.20171215.1

    and yet on boot-up it says:

    [    0.000000] microcode: microcode updated early to revision 0x1c, date = 2015-02-26

    Apparently this Core i5-3570S is "too old" for Intel to bother fixing. So just because you have the latest microcode package, doesn't mean it's going to contain any fixes for your particular CPU.

    Thanked by 1vimalware
  • bsdguybsdguy Member

    @rm_ said:
    Apparently this Core i5-3570S is "too old" for Intel to bother fixing. So just because you have the latest microcode package, doesn't mean it's going to contain any fixes for your particular CPU.

    No, I don't think so. Your processor is simply too end user. I strongly presume that first there will be/are provided band aids for infrastructure critical processors, i.e. xeons.

    Side note: It seems there's a new yardstick to seperate the good and the low end VPS providers, The good one will bite it and take the performance loss, i.e. will spread their vpss over somewhat more nodes. The low end one won't.

  • bsdguybsdguy Member

    @WSS said:

    @Maounique said:

    WSS said: Please correct for 25-53%.

    That is NOT what I am seeing. Where did you take that minimum of 25?

    I made it up.

    Really? Sure? -> https://lh6.googleusercontent.com/MwzsHRXQLVbmJ3pusNuGwn0ZQVjo9h8nRJHJhIo4d3XFqbvUYCj8EPq5jV7zeVEEcHAkraNBesbbNDW_UAlIjvw-hZBd80rKt7ZYl35nBIcfCCVyRvW5V7M7KVejv9tvVBHfgSKr

    (from Epic Games re. their patched servers)

  • WSSWSS Member

    @bsdguy said:

    @WSS said:

    @Maounique said:

    WSS said: Please correct for 25-53%.

    That is NOT what I am seeing. Where did you take that minimum of 25?

    I made it up.

    Really? Sure? -> https://lh6.googleusercontent.com/MwzsHRXQLVbmJ3pusNuGwn0ZQVjo9h8nRJHJhIo4d3XFqbvUYCj8EPq5jV7zeVEEcHAkraNBesbbNDW_UAlIjvw-hZBd80rKt7ZYl35nBIcfCCVyRvW5V7M7KVejv9tvVBHfgSKr

    (from Epic Games re. their patched servers)

    Oh, no, I'm going going to go through another IP issue with Intel again!*





    * also a joke.

  • MaouniqueMaounique Host Rep, Veteran

    bsdguy said: The good one will bite it and take the performance loss, i.e. will spread their vpss over somewhat more nodes.

    I think the good ones had always some margins to account for the extra load now and then and can afford to sit back and watch what product and nodes need some intervention, if any. What you mention is the average provider.

    Thanked by 1vimalware
  • WSSWSS Member

    @rm_ said:
    I installed the latest Intel microcode package in Debian:

    intel-microcode                    3.20171215.1

    and yet on boot-up it says:

    [    0.000000] microcode: microcode updated early to revision 0x1c, date = 2015-02-26

    Apparently this Core i5-3570S is "too old" for Intel to bother fixing. So just because you have the latest microcode package, doesn't mean it's going to contain any fixes for your particular CPU.

    If you look inside the release, it's 20171117 with some supplementary binary patches:

    supplementary-ucode-CVE-2017-5715.d/s000306C3_m00000032_r00000023.fw
supplementary-ucode-CVE-2017-5715.d/s000306D4_m000000C0_r00000028.fw
supplementary-ucode-CVE-2017-5715.d/s000306F2_m0000006F_r0000003B.fw
supplementary-ucode-CVE-2017-5715.d/s00040651_m00000072_r00000021.fw
supplementary-ucode-CVE-2017-5715.d/s000406E3_m000000C0_r000000C2.fw
supplementary-ucode-CVE-2017-5715.d/s000406F1_m000000EF_r0B000025.fw
supplementary-ucode-CVE-2017-5715.d/s00050654_m000000B7_r0200003A.fw
supplementary-ucode-CVE-2017-5715.d/s000506C9_m00000003_r0000002E.fw
supplementary-ucode-CVE-2017-5715.d/s000806E9_m000000C0_r0000007C.fw
supplementary-ucode-CVE-2017-5715.d/s000906E9_m0000002A_r0000007C.fw

    I suggest anyone interested in following this without blindly rebooting or wondering why sending to /dev/cpu/microcode isn't doing anything, get familiar with iucode_tool.

    The syntax is pretty simple. Here's how you'd extract using a standard Intel .dat format file (and not the raw binary examples above) for your specific CPU:

    #/path/to/iucode_tool -t d -k --overwrite microcode-20171117.dat -K -S
iucode_tool: system has processor(s) with signature 0x0{YOURCPU}
iucode_tool: Uploading selected microcodes to: /dev/cpu/microcode
iucode_tool: Writing microcode firmware file(s) into /lib/firmware/intel-ucode
    Thanked by 3vimalware tarasis uptime
  • serverianserverian Member

    My whole weekend is dead. Thank you computers!

    Thanked by 3gestiondbi rds100 layfon
  • ZerpyZerpy Member

    @WSS said:
    If you look inside the release, it's 20171117 with some supplementary binary patches:

    supplementary-ucode-CVE-2017-5715.d/s000306C3_m00000032_r00000023.fw
supplementary-ucode-CVE-2017-5715.d/s000306D4_m000000C0_r00000028.fw
supplementary-ucode-CVE-2017-5715.d/s000306F2_m0000006F_r0000003B.fw
supplementary-ucode-CVE-2017-5715.d/s00040651_m00000072_r00000021.fw
supplementary-ucode-CVE-2017-5715.d/s000406E3_m000000C0_r000000C2.fw
supplementary-ucode-CVE-2017-5715.d/s000406F1_m000000EF_r0B000025.fw
supplementary-ucode-CVE-2017-5715.d/s00050654_m000000B7_r0200003A.fw
supplementary-ucode-CVE-2017-5715.d/s000506C9_m00000003_r0000002E.fw
supplementary-ucode-CVE-2017-5715.d/s000806E9_m000000C0_r0000007C.fw
supplementary-ucode-CVE-2017-5715.d/s000906E9_m0000002A_r0000007C.fw

    I suggest anyone interested in following this without blindly rebooting or wondering why sending to /dev/cpu/microcode isn't doing anything, get familiar with iucode_tool.

    The syntax is pretty simple. Here's how you'd extract using a standard Intel .dat format file (and not the raw binary examples above) for your specific CPU:

    #/path/to/iucode_tool -t d -k --overwrite microcode-20171117.dat -K -S
iucode_tool: system has processor(s) with signature 0x0{YOURCPU}
iucode_tool: Uploading selected microcodes to: /dev/cpu/microcode
iucode_tool: Writing microcode firmware file(s) into /lib/firmware/intel-ucode

    Which is all good, but even with iucode_tool - the microcode for a specific processor has to be available, and even if taking e.g. version 20171117 from Intel's website - it won't contain microcodes for a lot of CPUs yet, such as E3-1230v6

    A great way of testing if a microcode is available for the CPU is by doing:

    iucode_tool -tb -lS /lib/firmware/intel-ucode/*

    In case there's no microcode with a date after november or december, it's pointless to "patch" and reboot, since it won't do anything anyway.

    e.g. version 20171117 from intel:

    # iucode_tool -tb -lS intel-ucode/*
iucode_tool: system has processor(s) with signature 0x000906e9
selected microcodes:
001: sig 0x000906e9, pf mask 0x2a, 2017-04-06, rev 0x005e, size 97280

    No fix for E3-1230v6 yet ... Let's all wait happily, what can possibly go wrong :')

  • WSSWSS Member

    @Zerpy said:
    Which is all good, but even with iucode_tool - the microcode for a specific processor has to be available, and even if taking e.g. version 20171117 from Intel's website - it won't contain microcodes for a lot of CPUs yet, such as E3-1230v6

    That's why I wrote the above.

  • ZerpyZerpy Member

    @WSS said:

    @Zerpy said:
    Which is all good, but even with iucode_tool - the microcode for a specific processor has to be available, and even if taking e.g. version 20171117 from Intel's website - it won't contain microcodes for a lot of CPUs yet, such as E3-1230v6

    That's why I wrote the above.

    Just doesn't mention the fact that simply supplying the dat file, still doesn't guarantee that your CPU might be patched, simply running the command:

    root@cph1-001:~# iucode_tool -t d -k --overwrite microcode-20171117.dat -K -S
iucode_tool: system has processor(s) with signature 0x000906e9
iucode_tool: Uploading selected microcodes to: /dev/cpu/microcode
iucode_tool: Writing microcode firmware file(s) into /lib/firmware/intel-ucode

    Will give the same result regardless of a new patching being available or not compared to what the CPU already contains.

Sign In or Register to comment.