Comments Locked

31 Comments

Back to Article

  • Drazick - Thursday, March 15, 2018 - link

    What we really need is a report of the performance hit of each solution.

    Anandtech, could you make such a report?

    Thank You.
  • Drazick - Thursday, March 15, 2018 - link

    The idea is only things which hurt performance substantially should be solved in Hardware while the rest are OK to be solved in Software.
  • iter - Thursday, March 15, 2018 - link

    The reason the problem exists in the first place was that intel took shortcuts for the sake of improving performance. Which means that both mitigation and hardware fixing will involve loss of that advantage. Mitigation in hardware will definitely take less of a hit, but will unavoidably remove the advantage that created the issue.
  • edzieba - Thursday, March 15, 2018 - link

    "The reason the problem exists in the first place was that intel took shortcuts for the sake of improving performance."

    If by 'took shortcuts' you mean 'the same shortcuts taken by everyone implementing Speculative Execution' (including AMD, ARM, IBM, etc). Spectre is a fundamentally new class of attack that everyone implementing SE is vulnerable to.
  • lmcd - Thursday, March 15, 2018 - link

    Would assume he's referring to the meltdown patches, which were Intel-specific (and supposedly the ARM A75 or something).
  • Ryan Smith - Thursday, March 15, 2018 - link

    For reference, the official tally right now is Intel Core, Arm Cortex A75, Apple 64bit ARM cores, and IBM POWER.
  • Samus - Thursday, March 15, 2018 - link

    AMD's approach to speculative execution had integrity checks.
  • Drazick - Thursday, March 15, 2018 - link

    Here is a plan:
    1. Check performance without mitigation.
    2. Check performance with software based mitigation.
    3. Spot mitigations which hurt performance significantly.
    4. Fix those of (3) in Hardware.
    5. Fix those not in (3) in software.
  • Alexvrb - Friday, March 16, 2018 - link

    That's basically what they're doing, but if you believe their marketing they make it sound like all SE attacks are completely solved at a hardware level with zero performance hit, which seems pretty unlikely. Even hardware based mitigation could hinder performance slightly and be vulnerable to future SE exploits. The performance aspect won't really matter because it will be far more than offset by IPC increases alone.

    Anyway the biggest impact of the patches is on pre-Broadwell architectures.
  • Ryan Smith - Thursday, March 15, 2018 - link

    "Anandtech, could you make such a report?"

    It's in the cards. We've just been waiting on microcode updates that have finally been delivered.=)
  • zmeul - Thursday, March 15, 2018 - link

    I'd shit my pants if they'll release a BIOS update for my X38 mobo
  • willis936 - Thursday, March 15, 2018 - link

    Yeah...

    All these microcode patches mean squat if the 15 motherboard vendors don't update their 15,000 motherboard model BIOS. I'd be shocked if ASUS even updated my 4 year old mobo let alone my Core 2 machine.
  • willis936 - Thursday, March 15, 2018 - link

    Hell it looks like my dual IVB-E system doesn't have a planned BIOS update. Basically any consumer machine older than haswell is given the finger. I'd love to see a statement or commitment to the contrary.

    https://www.asus.com/us/support/FAQ/1035538
  • XabanakFanatik - Thursday, March 15, 2018 - link

    If we're talking about ASUS, even haswell and broadwell aren't getting any love. They have only two boards listed on their consumer motherboard list, and neither of them have actually received the listed bios update yet.

    They are second generation x99 boards, so all the first generation x99 boards, z97, and z87 boards are being ignored by them, apparently.
  • Cyanara - Thursday, March 15, 2018 - link

    Yeah, ASUS and Gigabyte are the big names here in Australia, yet I noticed ASUS's lack of updates on our office's second gen X99 board. Pretty shoddy support for a recent premium product.

    Our Gigabyte X99 boards on the other hand received microcode updates at the end of January. I'm definitely happy to continue supporting them if it means they keep our business a bit safer.
  • Morawka - Friday, March 16, 2018 - link

    I've had good luck with Asus and Bios updates. I had a x48 board that got BIOS updates for 7 years, the R2E.
  • DanNeely - Thursday, March 15, 2018 - link

    There're mechanisms to allow OS drivers to load updated microcode when they startup. If you're using a currently supported mainstream OS it can load the update for you every time you run it.

    A BIOS update is still better since it protects the system at bootup, and in any OSes that don't have the updated microcode available as part of their kernel driver packages; but the delivered by the OS mechanism will allow most systems to be covered in normal use.
  • Alexvrb - Friday, March 16, 2018 - link

    They don't need to. All they need to do is release a microcode update for your CPU. If they do, you will be able to snag a patch from MS that applies the microcode before loading Windows. At first you'll have to get it directly from MS on the web, but I've heard it will eventually be rolled into Windows Update for the next major release. Unless you're on an older version... in which case... I don't know what to tell you.
  • jjj - Thursday, March 15, 2018 - link

    Can you please ask them to define hardware in this context.
  • Ryan Smith - Thursday, March 15, 2018 - link

    Unfortunately this is all we have at the moment. I expect we'll hear more from Intel once the hardware is closer to shipping.
  • bill44 - Thursday, March 15, 2018 - link

    I take it the upcoming Intel Core i7-8809G will NOT have hardware mitigation :(
  • edzieba - Thursday, March 15, 2018 - link

    It contains a Kaby Lake die, so no.
  • HStewart - Thursday, March 15, 2018 - link

    8809G should have Microcode fixes - I am curious what is difference between Microcode changes - which is update for pretty much all of Intel CPU and Hardware Migration.

    My only guess is likely in performance - that newer cpus will be faster than older generations.

    One big concern about all the Meltdown/Spectre stuff - is where is actual virus / hacks - I heard all complaints - but where is real issues - and what does it take to effect application.. who some one have to run an executable on clients machine. And lets say you have code to get some ones password by using the techniques - how does it get back to someone else - now if this can be proven to cause problem in firewall - then it could be big issue,.
  • Silma - Thursday, March 15, 2018 - link

    Your article is not clear.
    If Intel implements M&S v2 mitigations in hardware, then it should appear in the table as 'hardware-based', not 'hardware immune'.
    Hardware immune would mean no mitigation but 100 % security against the threats.
  • HStewart - Thursday, March 15, 2018 - link

    I think the best thing to do is implemented IO protection - so if some one attempts to cross boundaries in address space - that they would get exception - who cares if application attempting to invalid things slows down because of exception or crashes. I would expect this to be handle if application is user level - to real problem is this is OS level or possible some driver level.

    On 'hardware immune' no vendor ( Intel, AMD or ARM ) can ever claimed that they are 100% immune to attacks - possibly they can say that known attacks - but as can we see with Meltdown/Spectre, people can go to quite creative and technical extremes to prove a point.

    But my big question is has there been any real case of malware / virus based on Meltdown/Spectre. So far I heard nothing except for Proof of concepts
  • Ryan Smith - Thursday, March 15, 2018 - link

    A reasonable point.

    The primary purpose of the table was to note that those processors wouldn't require software fixes for those two exploits.
  • vailr - Thursday, March 15, 2018 - link

    A UEFI bios update program may be useful, for someone wanting to install updated CPU microcode on motherboards for which "official" UEFI bios firmware updates are not yet available:
    http://www.majorgeeks.com/files/details/uefi_bios_...
    The program is authored and maintained on a Russian web site, but has been translated to English.
  • ಬುಲ್ವಿಂಕಲ್ ಜೆ ಮೂಸ್ - Thursday, March 15, 2018 - link

    Ooh, Russian Firmware sounds totally Legit!

    or I could go the Bullwinkle Route and lock down Windows 10 as a Read-Only Operating system, Block ALL untrusted software from Internet connectivity and made every application portable using ThinApp or similar product and NEVER run scripts of any type

    If it worked for Windows XP, then it will work for Windows 7 / 8 & 10 without going to the very limited and locked down Windows 10-S mode!

    That way you could do all the speculative executions you wanted without any performance penalty

    There are programs available that can turn Windows 10 into a Read Only System while allowing disk writes and changes where you actually need them without ever getting persistent malware "IF you know what you are doing"

    Big "IF"
  • Zingam - Saturday, March 17, 2018 - link

    Or you can use the other 99% of the firmware which is Chinese.
  • ಬುಲ್ವಿಂಕಲ್ ಜೆ ಮೂಸ್ - Saturday, March 17, 2018 - link

    Zing!
  • nevcairiel - Friday, March 16, 2018 - link

    I looked into this tool a while ago, and a few newer versions that claim support for X99 and X299, but at least for those it just didn't work.

    Unless your board has dual-bios, i would probably be extremely wary of trying that. And even with dual-bios..

Log in

Don't have an account? Sign up now