Comments Locked

210 Comments

Back to Article

  • plopke - Thursday, January 4, 2018 - link

    Sigh , some vendors still not even finished with Intel their ME disaster since they updated that securty bulletin to core design as far back as 3/4 gen and brief mentioning even all the way to 1gen. For me the vendor rolled out the update for last 3 core designs already so kudos to them but there is still more to be done.

    This is twice in 6 months the last 7-8 years of CPU designs have major flaws , some of the ME were embarrassing ,spectre/meltdown I can sort of forgive slipping true the cracks, but holy shit poor IT-deparments 2017-2018 was kinda horrible ,wifi,ME,cpu,....
  • Zingam - Thursday, January 4, 2018 - link

    Israeli designed CPUs, Planned Obsolescence... it all adds up to a perfect Conspiracy Theory perfectly!
    It's great to be alive!
  • negusp - Thursday, January 4, 2018 - link

    IT'S A ZIONIST CONSPIRACY REEEEEEEEE
  • Hurr Durr - Thursday, January 4, 2018 - link

    And you`re living it!
  • Bullwinkle-J-Moose - Thursday, January 4, 2018 - link

    Here is a conspiracy theory for you Hurr Durr.....

    How will you mitigate the problem with new hardware next year?

    If Intel hardware prevents you from running a "Non Spyware Platform" won't Microsoft and the NSA still have access to your secrets that are in a supposedly "secure" VM when you run a Spyware Platform like Windows 10?

    and, even if you fix the hardware, whenever you want to use the Internet, won't Windows 10 prevent you from blocking "Host Process for Windows Services" allowing Microsoft to change your O.S. whenever they want and monitor everything you do?

    How will a hardware fix prevent your Operating System from stealing your secrets?

    Snowden said that he could remotely monitor what you type "as you type it" which would prevent your secrets from being protected by any encrypted messaging app on the planet as they could be read before they are encrypted

    How can you protect your secrets with a hardware fix when Microsoft can still see your secrets?

    Why would anyone believe that protecting their secrets from everyone except MICROSOFT is somehow a solution to the problem?
  • jrs77 - Thursday, January 4, 2018 - link

    Use Linux instead of Windows. Problem solved.
  • timecop1818 - Thursday, January 4, 2018 - link

    Lol. Windows might be spying on me which i don't give a fuck about, but at least i can turn on my computer and get work done.

    With lunix i would still be deciding which of the 20 "desktop" environments to choose from or arguing finer points of emacs vs vi vs nano on internet forums.

    In nearly 3 decades, lunix dweebs still haven't produced a working OS that normal people can use.
  • Hurr Durr - Thursday, January 4, 2018 - link

    One can argue that Ubuntu is "it", but actually trying to use it after any post-Vista Windows is so very inconvenient, and I`m not talking just about different UI conventions here.
  • ender8282 - Sunday, January 7, 2018 - link

    Arguing finer points of emacs vs vi vs nano? What a stupid argument. Everyone knows the answer is vi.

    <Ducks and runs away.>
  • romrunning - Friday, January 5, 2018 - link

    Perhaps you didn't know that the OS is also part of the vulnerability to the attacks. So that means Linux is also vulnerable to these attacks along with Windows. That's why it's going to be a combination of hardware/software patches & updates that will attempt to mitigate these issues.
  • alpha754293 - Friday, January 5, 2018 - link

    LInux sucks.

    The mgag200 driver on my server is causing about a 44% performance degradation with GNOME due to a memory leak/making X think that it NEEDS all 128 GB of installed RAM.

    The solution so far has been to blacklist the mgag200 driver, which results in a performance degradation of the video adapter, but at least GNOME/X will stop eating itself to death (in terms of RAM).

    Linux problem NOT solved.
  • ender8282 - Sunday, January 7, 2018 - link

    Why are you running X on a server?
  • Wolfpup - Thursday, January 4, 2018 - link

    Windows 10 is not a "spyware platform".
  • Bullwinkle-J-Moose - Thursday, January 4, 2018 - link

    "Windows 10 is not a "spyware platform".
    -----------------------------------------------------
    Well, technically not only...
    But "Spyware Malware Extortionware Platform" was such a long descriptor
  • Alexvrb - Thursday, January 4, 2018 - link

    You're using the internet, you're exposed!! Get offline, be safe. No seriously... go offline... forever. Thanks.
  • Beaver M. - Thursday, January 4, 2018 - link

    Yep. The fact of the matter is that the NSA can order and has ordered American corporations to give them access to their data and software. And they arent even allowed to talk about it.
    And yet everyone has forgotten it again.
  • Hurr Durr - Thursday, January 4, 2018 - link

    I won`t buy your bastardization of XP, calm your tits psycho.
  • JonnyDough - Sunday, January 7, 2018 - link

    Firewall.
  • Bullwinkle-J-Moose - Monday, January 8, 2018 - link

    Firewall ???
    ----------------
    As in Plug and Play / ease of use / created for Non-Techies and Grandmothers?

    With my aftermarket firewall, I can block ALL Microsoft components in Windows XP-SP2 and still use the Internet

    You cannot do that with the built in firewalls of Windows 7, 8 or 10

    Microsoft additionally lets pretty much anyone with a "Valid" cert in and out through the default firewall even when the appmakers production line was hijacked to add malware before Worldwide distribution (think CCleaner, VLC etc)

    As long as the end user is held hostage and not allowed to secure their own box, FIREWALL alone does not adequately explain the problem OR a valid solution

    I can still use XP without any Microsoft updates and not have to worry about Meltdown and Spectre because my XP box is used for security research so no personal info or passwords are ever used on this machine

    I could care less about anyone hacking this machine
    Note to Hurr Durr >
    I have always said this box cannot be wrecked by the NSA and others but I NEVER said it couldn't be hacked

    Now you can all finally see that all of your fancy new Windows 10 machines are as vulnerable as my XP box!

    How does it feel?
  • Samus - Thursday, January 4, 2018 - link

    The real conspiracy here is that AMD had the hindsight to implement a secure prefetch and prediction algorithm when Intel didn't...

    The irony being: AMD CPU's will now likely be performance competitive across the board with Intel CPU's running patched microcode.
  • Zingam - Thursday, January 4, 2018 - link

    If you want a secure PC I have a 8088 system for sale!
  • FunBunny2 - Thursday, January 4, 2018 - link

    one hopes that's sarcasm. the 8086/8 has 0 security, which is why DOS allowed applications, games in particular and 1-2-3, were compromised daily.
  • Lord of the Bored - Thursday, January 4, 2018 - link

    Don't blame the 8086 for DOS's failings. Though you're right that the processor had no security mechanisms, systems that required a 486 still ran everything in ring 0.
  • FunBunny2 - Friday, January 5, 2018 - link

    "Don't blame the 8086 for DOS's failings. "

    well. DOS used a lot of CP/M, if only to reuse existing 8-bit peripherals in the box. fact remains, the 8086/8 is real time only chip. CP/M stands for Control Program/Microprocessor for a reason. it's not a legitimate OS, and neither is DOS (the Microsoft version; IBM mainframes are a bit different). if anyone knows of a secure OS for the 8086/8, please pipe up.
  • Wolfpup - Thursday, January 4, 2018 - link

    I got rid of mine about 13 years ago ;)
  • 50UL - Thursday, January 4, 2018 - link

    This is the simplest chart about it, 1/2 page. https://uploads.disquscdn.com/images/cab9430cb6a5a...
  • Reflex - Thursday, January 4, 2018 - link

    That chart does not appear accurate and is clearly speculative. For instance it states that Spectre is "NOT POSSIBLE" to fix on Intel but can be fixed via software on AMD. In reality Spectre is not well understood and no one yet knows what the remediation will be or what forms it will take. It also states that Spectre2 does not impact AMD, which seems contrary to Google's data. I am also not aware of any information stating that AMD is only affected on Linux, that makes little logical sense as this is an operation that occurs entirely in hardware.

    The statement on Meltdown is premature, we do not yet know if AMD is affected although so far with a small number of researchers on the issue they have not managed to execute it. That does not mean it is immune however, ARM also was initially believed to be immune but with some tweaking Meltdown was found to function on post-2011 ARM designs.

    In short that chart is speculative at best and misleading at worse...
  • Chaitanya - Friday, January 5, 2018 - link

    You are forgetting about USB exploit affecting these Nehlem derivatives.
  • Elstar - Thursday, January 4, 2018 - link

    What I don't understand about Meltdown is why Linux went with KPTI, rather than batch exceptions and deliver them at regular intervals. That would destroy the ability to measure exception latency and defeat Meltdown without the huge cost of KPTI on well behaved code.
  • Ryan Smith - Thursday, January 4, 2018 - link

    That's a really good question. And I wish I knew enough about Linux kernel dev to give you an equally good answer.

    However the more I've read about Meltdown and Spectre, the more I get the impression that the core software architects want to put a fork in keeping the kernel anywhere near user space applications. It was a lack of separation that was partially responsible for these vulnerabilities, so there's room to argue that at this time it's better to err on the side of security over performance. And that means throwing out a lot of security-weakening performance optimizations that were made in the early days to make systems fast enough to be usable.
  • Elstar - Thursday, January 4, 2018 - link

    I posted to eagerly. just reread the paper. They don't need to measure the exception directly. An entirely different process measures cacheline load latency, and the specific cacheline that loads quickly tells you one or more bits about the inaccessible memory.
  • Elstar - Thursday, January 4, 2018 - link

    Er, "too" before anybody complains.
  • name99 - Friday, January 5, 2018 - link

    I’m with you on this. To me it seems that dealing with the TIMING kills all these problems at the root. Everything else kills today’s problems, only to have tomorrow delivering another, different, timing attack.
  • Threska - Friday, January 5, 2018 - link

    https://arstechnica.com/gadgets/2018/01/whats-behi...

    I have been thinking if MRAM ever becomes viable there may no longer be a need for TLB and the associated splitting.
  • State of Affairs - Thursday, January 4, 2018 - link

    @ Ryan Smith

    Both AMD’s Ryzen Pro and Epyc series processors offer on-chip engines for secure memory encryption (SME) and secure encrypted virtualization (SEV). Do one or both of these features block exploits like those of Meltdown and Spectre? In other words, even if data can be extracted from protected memory space, it is useable by virtue of being encrypted.

    I have yet to see any article commenting on these features from AMD, yet many make the claim that all modern processors are affected. If SME and SVE do prevent exploits like Meltdown and Spectre, such conclusions are wrong. Also, and contrary to your article, it would then be a fantastic week to be AMD.

    Perhaps you could contact AMD and inquire about SME and SEV in relation to Meltdown and Spectre. Also, did you ever find out from AMD if Threadripper processors have active SME and SVE functionality? Threadripper is derived from Epyc, but in your review article on Threadripper, this matter was unresolved.
  • ddrіver - Thursday, January 4, 2018 - link

    I was wondering the same thing and eagerly awaited the delayed-because-it-will-be-very-in-depth article from AT to shed some light on whether that encryption mitigates the issue, or is everything that passes through the (trusted) CPU decrypted including the exploited data.

    But as it stands there's no additional info compared to many of the articles posted over the past few days. Definitely "worth" the wait.
  • bji - Thursday, January 4, 2018 - link

    Do you ever stop complaining?
  • StevoLincolnite - Thursday, January 4, 2018 - link

    He really doesn't.
  • MadManMark - Thursday, January 4, 2018 - link

    He doesn't stop, to my knowledge. His posts are primarily about putting down others who try to contribute understanding while making little or no attempt to actually try himself.
  • Billy Tallis - Thursday, January 4, 2018 - link

    Memory encryption should help in some cases, but probably doesn't eliminate the threat from the ASLR-defeating aspects of these attacks.
  • Reflex - Thursday, January 4, 2018 - link

    The problem with encrypted memory is that it has to be decrypted at some point to be usable, and the CPU handles that operation. It is yet another step required but it is in no way insurmountable.
  • Threska - Monday, January 8, 2018 - link

    http://people.csail.mit.edu/devadas/pubs/ascend-st...

    Encrypted computation.
  • BillyONeal - Thursday, January 4, 2018 - link

    Unlikely. Memory encryption encrypts data between the CPU die and on the DRAM, but this attack happens entirely in the CPU's caches.
  • name99 - Friday, January 5, 2018 - link

    But it COULD work.
    Each processID has an associated random number one cache line long. All data in cache is xor’ed against that number. Even learning the bits does you no good in absence of that random number.
    And this is more or less easy enough to do at L1$ speeds (just an xor), without using much energy or area.
  • linuxgeex - Saturday, January 6, 2018 - link

    That cannot be how it is implemented. If it was, then you could discover the per-process number trivially simply by accessing the value of a memory area known to be 0. So you simply must be wrong, I'm not even going to waste my time looking to confirm.
  • Kevin G - Thursday, January 4, 2018 - link

    This is a question I've brought up but in a slightly different context: Redhat is pushing a fix on the main frame System Z which has had memory encryption and compression for generations now. The presumption is that if memory could be read, it'd be in encrypted form but this certainly needs to be tested for verification.

    ARM and IBM's POWER platforms also appear to affected to some degree as well.
  • Ryan Smith - Thursday, January 4, 2018 - link

    "Do one or both of these features block exploits like those of Meltdown and Spectre?"

    Right now it does not appear to be the case. Spectre is so low level that conceptually it hits before these technologies come into play. But with that said, the industry is still in the early days of figuring all of this out.
  • FunBunny2 - Friday, January 5, 2018 - link

    "Spectre is so low level that conceptually it hits before these technologies come into play."

    which raises, for me, the most interesting question. Intel/AMD chips are CISC/ISA on RISC micro-coded hardware, with some complicated "decoder" interceding. ARM/POWER, on the other hand, are RISC on the ISA. so where's the problem? is it the ISA? or is it the firmware just on top of the metal? or is it the metal, the actual ALU, etc.? from the descriptions, it could be anywhere.
  • Reflex - Friday, January 5, 2018 - link

    The problem is the feature, not the instruction set. Which is why the issue is impacting every CPU with branch prediction and out of order execution, rather than simply x86 or RISC ISA's.
  • FunBunny2 - Friday, January 5, 2018 - link

    "The problem is the feature"

    understood, but the question is more abstract, in a way. if there's only one (or two if you count AMD doing it a different way, by not doing it, sort of) way to put the feature into hardware, because it's just an algorithm, how much of current cpu architecture, not just this one feature, relies on non-patentable algorithms? the exploits have to done in one of two ways: all the physical cpus implement the feature using identical topology, which would make sense if "there's only one smart way to do it", or the exploit is simple enough to write it to each different hardware. that's way more work, and POWER and Z are teeny fractions likely not worthy of the effort.

    could it be that, on the metal, all these 'different' cpus are really all the same? and if so, consider the implications for all sorts of commercial efforts. could it be that cpu as hardware is kind of like linux for software: hardware architecture ends up being an open source arena.
  • linuxgeex - Saturday, January 6, 2018 - link

    It doesn't matter the methodology that the feature is implemented by. The failure is that speculative lookups are happening without access controls being validated before the code is executed. The validations are instead happening after the code is executed but before it is retired. This is done for latency reasons, which affects pipeline depth and overall CPU efficiency. It's easy to do the access control checks up front but CPUs will run slower and use more power... and that is how it will be from now on for general-purpose processors which may run untrusted code. This creates a new market for less secure, higher performing, more efficient general-purposes processors down the road. There's lots of tasks we can safely run on today's processors... just not an operating system or a web browser with a JIT.
  • BillyONeal - Thursday, January 4, 2018 - link

    The timing attack isn't on when the exception is delivered for the invalid access. It's on an ordinary data access afterward
  • linuxgeex - Saturday, January 6, 2018 - link

    Exactly, for example in x86 it's a result of TSC timestamps either side of a perfectly valid read, determining whether or not it is already cached, after using the side-channel attack to cache (or not) the target code. Hammer the cache and you can make it reveal code location down to a single cache line.
  • crazylocha - Thursday, January 4, 2018 - link

    Thank you Ryan.
    I know you couldn't have had much sleep last night or this morning. The forum was wondering how long it would take.

    Now I need to grab my beach towel and put on my bathrobe and will be ready.
  • watersb - Thursday, January 4, 2018 - link

    :-)
  • mobutu - Thursday, January 4, 2018 - link

    Is there any list of the new parts that are 100% protected from this?
    Like from what intel cpu generation upwards are protected? amd? etc
  • Pork@III - Thursday, January 4, 2018 - link

    VIA processors? :D
  • Lord of the Bored - Thursday, January 4, 2018 - link

    Via's probably vulnerable. Just assume if it has cache and out-of-order execution that it is vulnerable.
  • phoenix_rizzen - Friday, January 5, 2018 - link

    Quick, everyone replace their desktops with Intel Atom and ARM Cortex-A53/A55 CPUs! In-order CPUs for the win! :)
  • linuxgeex - Saturday, January 6, 2018 - link

    It's speculation (branch/return prediction) that's the problem, not out-of-order, but yes the combination of the two, plus NUMA access delays, is what makes Spectre so powerful. big.LITTLE has large enough NUMA access delays that even the A53 is vulnerable because o-o-o isn't required if the speculation window is large enough. o-o-o just enhances the size of the speculation window by letting more work be done.
  • mobutu - Thursday, January 4, 2018 - link

    The article mentions of changing/updating the hardware to be on the safe side.
    Ok, I change my system but with what? Are the new Core8 (or 9? I don't keep track) safe from this? Are the new Ryzens safe from this?
    Hence my question above.
    Thanks
  • Pork@III - Thursday, January 4, 2018 - link

    There is no really new Ryzen before 2019.
  • Ryan Smith - Thursday, January 4, 2018 - link

    All processors are vulnerable to Spectre. All current Intel processors are vulnerable to Meltdown as well.
  • kepstin - Thursday, January 4, 2018 - link

    I'm curious whether the first-gen Atom chips (Bonnell) are also affected. They use an in-order design without speculative execution - and are, I think, Intel's last processor generation where that was true.
    (That said, they do still have branch prediction to avoid pipeline stalls, and local caches, so...?)
  • mczak - Thursday, January 4, 2018 - link

    Bonnell shouldn't be affected by Meltdown, but indeed it should be vulnerable by Spectre. While it's an in-order design, it certainly does speculative execution (otherwise you wouldn't need a branch predictor in the first place...).
  • tuxRoller - Thursday, January 4, 2018 - link

    The branch predictor is a general purpose feature that can be used for either simple pre-fetching (this is ubiquitous even in microcontrollers) or pre-fetching followed by speculative execution.
  • mczak - Thursday, January 4, 2018 - link

    Ok, but in any case all "somewhat fast" in-order cpus will do speculative execution based on branch prediction. non-pipelined simple microcontrollers don't count :-). (Ok you can certainly have pipelined cpus which don't do speculative execution, but since branches are quite frequent with "ordinary" code there's just no way around it unless you're not interested in single-thread performance.)
  • tuxRoller - Friday, January 5, 2018 - link

    Err, pretty much every (as in, I can't think of a current exception) processor is pipelined (the old fetch-decode-execute) but that's neither here nor there. Aiui, both SPECTRE and MELTDOWN requires not just speculative fetches but continued execution of that branch (doing SOMETHING with that fetch).
  • mczak - Friday, January 5, 2018 - link

    I meant cpus with somewhat longer pipelines (as all "somewhat fast" cpus have).
    But on taking a closer look at how the attack works, I think I was wrong that this could work on in-order cpus. At least the sample code is depending on a cache miss for one of the operands determining which branch is taken, then doing a load depending on the malicious value. Basically that would only really work if the cpu can reorder loads, which in-order cpus can't.
  • Threska - Friday, January 5, 2018 - link

    https://arstechnica.com/gadgets/2018/01/whats-behi...

    While Intel systems are the ones known to have the defect, they may not be the only ones affected. Some platforms, such as SPARC and IBM's S390, are immune to the problem, as their processor memory management doesn't need the split address space and shared kernel page tables; operating systems on those platforms have always isolated their kernel page tables from user mode ones.
  • crazylocha - Thursday, January 4, 2018 - link

    https://security-center.intel.com/advisory.aspx?in...

    Nearly everything Intel
  • manoj29 - Friday, January 5, 2018 - link

    New Pentium silver series (gemini lake released in dec) is not on the list
  • Threska - Thursday, January 4, 2018 - link

    All? Even SPARC,PowerPC, or S390?
  • Lord of the Bored - Thursday, January 4, 2018 - link

    In all seriousness, the concept is applicable to them.
  • Ryan Smith - Thursday, January 4, 2018 - link

    Yes. Red Hat has confirmed that System Z is vulnerable, as are POWER. I don't believe anyone has published results for SPARC yet, but the nature of the flaw means that it should be vulnerable as well.
  • Alexvrb - Thursday, January 4, 2018 - link

    What about my Alpha systems running Windows NT??
  • vladx - Friday, January 5, 2018 - link

    If it's an out-of-order design then indeed it's vulnerable though in practice you're safe because no one will target you.
  • linuxgeex - Saturday, January 6, 2018 - link

    You're right that all CPUs with MMUs are vulnerable to the cache latency side-channel attack that defeats ASLR but that's where you stop being right.

    Most embedded processors are not vulnerable to the more serious hacks like Meltdown, because their speculation window is too small to work with. The exceptions are X86 for embedded and ARM for embedded with high IPC, and NUMA, which increase the effective size of the speculation window. Without a large speculation window, Spectre not longer a threat because it can't get any work done. That's why mitigations like Retpoline which introduces latency into call returns, swallowing up the speculation window, work.
  • Zingam - Thursday, January 4, 2018 - link

    Pentium 4 FU YEAH
  • Wolfpup - Thursday, January 4, 2018 - link

    The Pentium 4 would be affected as well, as far as we know. Any modern high-performance design. I'm sure going back at least to the Pentium Pro/2, I'd assume (if not earlier).

    Umm...maybe the 486 is safe? ;)
  • edzieba - Friday, January 5, 2018 - link

    IIRC Itanium is not vulnerable (Kittson just shipped, totally still relevant guys!) as is Xeon Phi (based on P5).
  • Billy Tallis - Friday, January 5, 2018 - link

    Second-generation Xeon Phi is vulnerable, because they use more recent Atom cores that do speculative execution.
  • Reflex - Thursday, January 4, 2018 - link

    There are no modern CPU's that are protected from Spectre, it affects everything. Meltdown to date has only been able to be run on Intel and modern ARM designs (post 2011). Nothing ensures that as the details are more widely disseminated AMD and others won't be added to that basket however.
  • vladx - Friday, January 5, 2018 - link

    We'll have to go back to Pentium 1 architecture to be safe from Spectre, I wonder how fast a 5Ghz P1 would be today fabbed on 10nm.
  • FreckledTrout - Thursday, January 4, 2018 - link

    I wonder if Intels Ice Lake will have these issues? If it does will they fix the design and do another tape in so it doesn't land on silicone?
  • Pork@III - Thursday, January 4, 2018 - link

    Ice Lake is complete is not possible to change of its architecture.
  • Drumsticks - Thursday, January 4, 2018 - link

    I seem to remember them saying that Icelake had taped in, but that's likely an A0 tape in. There's no particular reason that they can't eventually have a B0 tape in if the fix (at least for meltdown) is relatively straightforward.
  • Pork@III - Thursday, January 4, 2018 - link

    How will work this architecture without predictions?
  • FreckledTrout - Thursday, January 4, 2018 - link

    Considering only Intel and some ARM chips are impacted by meltdown(not AMD and they have a predictive architecture as well) I'm assuming something can be done to resolve the issue architecturally. I'm sure it will eventually but was curious if Intel is going to tweak Ice Lake or wait until later. Just a curiosity.
  • vladx - Friday, January 5, 2018 - link

    There's no fix to Spectre only partial band-aids, like I said elsewhere we'd have to go back to P1 design to be completely clear from it.
  • MadManMark - Thursday, January 4, 2018 - link

    Note that Google informed Intel of this discovery last summer; it's merely the public that is just learning about it now.
  • SaturnusDK - Thursday, January 4, 2018 - link

    So if I'm understanding this correctly then the Windows Update rolled out yesterday is not complete for Intel system before Intel have rolled out a microcode update as well? And if so, we cannot make performance impact tests before that happens?
  • Ryan Smith - Thursday, January 4, 2018 - link

    It's looking that way. We've yet to find a system that shows as having hardware support for branch injection mitigation.
  • Dave11 - Thursday, January 4, 2018 - link

    Looks okay on my Alienware 15 R3 (Skylake)

    Microcode version C2

    PS C:\WINDOWS\system32> Get-SpeculationControlSettings
    Speculation control settings for CVE-2017-5715 [branch target injection]

    Hardware support for branch target injection mitigation is present: True
    Windows OS support for branch target injection mitigation is present: True
    Windows OS support for branch target injection mitigation is enabled: True

    Speculation control settings for CVE-2017-5754 [rogue data cache load]

    Hardware requires kernel VA shadowing: True
    Windows OS support for kernel VA shadow is present: True
    Windows OS support for kernel VA shadow is enabled: True
    Windows OS support for PCID optimization is enabled: True

    BTIHardwarePresent : True
    BTIWindowsSupportPresent : True
    BTIWindowsSupportEnabled : True
    BTIDisabledBySystemPolicy : False
    BTIDisabledByNoHardwareSupport : False
    KVAShadowRequired : True
    KVAShadowWindowsSupportPresent : True
    KVAShadowWindowsSupportEnabled : True
    KVAShadowPcidEnabled : True
  • Ryan Smith - Thursday, January 4, 2018 - link

    Aha! Thanks for that bit of info.

    What BIOS is that? And when was it released?
  • Dave11 - Friday, January 5, 2018 - link

    1.2.3 23rd or 27th of December
  • Dave11 - Friday, January 5, 2018 - link

    Bios release notes 23/12/17

    Fixes & Enhancements
    Updates to Intel ME Firmware addressing security advisory INTEL-SA-00086 & latest CPU microcode

    Version SKL1.2.3_KBL1.2.3
  • Questor - Thursday, January 4, 2018 - link

    I have to wonder? If these fixes are effective and they negatively affect performance, how do the various CPU makers justify the CPU product you bought at 3.5GHz is now only able to produce performance equal to 1.95GHz? Also, I have read several articles around the 'Net about this and it appears Intel has known about this since "mid-ish" 2017 (some reports say Feb 2017). If this is true, how can they justify continuing to sell products to consumers knowing they are defective or at least putting buyers at risk?
  • boeush - Thursday, January 4, 2018 - link

    Hmm yeah... Methinks I detect distant rumblings of a gathering class-action mega-lawsuit...
  • Reflex - Thursday, January 4, 2018 - link

    There are many performance enhancing modes your CPU can utilize that have been disabled for security or stability reasons. We are now realizing this is one that needs to fall into that bucket. This is not a bug, the feature is working as design, someone has simply figured out how to use that feature in ways not envisioned by the developers.

    You have not lost any performance, but software venders are making changes that de-optimize their products in order to avoid this exploit. They have done that dozens of times in the past as well although usually other optimizations have compensated for the overall performance loss.
  • Threska - Thursday, January 4, 2018 - link

    De-optimizing? As when Word had a bug, and the advice was, "don't use that feature"? Defeating the point of having it in the first place.
  • Reflex - Thursday, January 4, 2018 - link

    How software venders choose to utilize the hardware is not actually the hardware makers problem, although they typically do try to work collaboratively. This is basically disabling a feature that was useful but is capable of being abused. It sucks, but the alternative was to never have this perf to begin with.
  • mobutu - Thursday, January 4, 2018 - link

    Taken from FAQ @ https://www.intel.com/content/www/us/en/architectu...

    "When did Intel learn about the issue?
    The security researchers notified Intel and other companies about this issue in June 2017."
  • cfenton - Thursday, January 4, 2018 - link

    As bad as this seems for traditional computer users, I'm particularly worried about Android. At least Windows, MacOS, and Linux will get updates to mitigate these problems as soon as possible. Whatever the performance penalty might be, they will at least be protected. Many Android devices still in service haven't received a security update in years. My Xperia Z3, for example, was still on a patch from 2016 when I replaced it in October.

    Maybe this will be enough to get some manufacturers to update older phones, but given how badly some of the manufacturers support their phones, I doubt it.
  • haukionkannel - Thursday, January 4, 2018 - link

    I am afraid that you are right in there...

    Most phone manufacturers seems to think that anything that is two years old, is something to throw to trash can and do nothing. Even worse is that some manufacturers seems to newer update their phones, if they are in the cheaper end of the devices.
  • Hurr Durr - Thursday, January 4, 2018 - link

    If it was released more than 18 months prior, you can forget it. Soon to be 12 months!
  • tcliew - Thursday, January 4, 2018 - link

    Check your phone spec and the CPU listed in the link below.

    https://developer.arm.com/support/security-update
  • cfenton - Friday, January 5, 2018 - link

    Thanks for the link. It looks like a lot of Android phones will be affected by at least two of the variants. The notable exceptions are Cortex-A7 and Cortex-A53. That means some recent mid-range Snapdragons are safe, as well as some A-series and J-series Samsung phones. All the flagship phones from the past several years are affected (unless Kryo ends up being safe somehow).
  • Tams80 - Friday, January 5, 2018 - link

    This is probably the most concerning. While servers etc. offer much bigger rewards for a hacker, the exploits already are/will quickly be patched out. On the other hand older Android devices will very likely not be patched at all, and while the individual reward is far, far, far lower, it is potentially available for much, much longer. People just aren't going to start replacing their old devices because of these exploits.
  • ZolaIII - Thursday, January 4, 2018 - link

    According to Google all vendors including AMD are affected.
    We do know performance impacts for the Linux patch can be huge especially for IO related tasks which are topical for cloud/data centers. This is especially expressed most on the last gen Intel processors. Literally cutting performance in half (to 46% to be precise). Microsoft is a bloody lier (as usual). More details can be found in series of articles/benchmarks conducted/written by Michael Larabel at Phoronix.
  • Yojimbo - Thursday, January 4, 2018 - link

    Why does the spectre have a stick?

    I wonder if these issues will change people's buying decisions. Not necessarily because of the security concerns, assuming they can patch the ones that are differentiated by vendor, but because of any performance slowdown that might come about from the fix.
  • Ryan Smith - Thursday, January 4, 2018 - link

    "Why does the spectre have a stick?"

    A branch, to be precise.=)
  • SaturnusDK - Thursday, January 4, 2018 - link

    It's using branch prediction to poke the Kernel memory. Tricking it to reveal it's secrets.
  • Zingam - Thursday, January 4, 2018 - link

    NO! It is the Stick of Truth:
    http://store.steampowered.com/app/213670/South_Par...
    https://www.youtube.com/watch?v=-nSxV-44_XQ
  • SunnyNW - Thursday, January 4, 2018 - link

    Who comes up with the names? The security researchers that initially found the exploit?
  • Threska - Thursday, January 4, 2018 - link

    Well maybe the lesson is, there are no shortcuts in security. Meltdown was market-share, and bragging rights.
  • Achaios - Thursday, January 4, 2018 - link

    Ryan, Intel has announced that Skylake and later CPU's will only be minimally affected. It appears that CPU's of Haswell and earlier architectures will be those affected the most. What I want you to look at is "how many FPS I am about to lose on my Haswell/IvyB/SandyB CPU" please.
  • SaturnusDK - Thursday, January 4, 2018 - link

    That is in direct contrast to the findings on Linux platforms where they found that Skylake and never platforms suffer the most due to the SGX (Software Guard Extension) included in Skylake and newer CPUs. On linux performance test you can see that in some extreme cases Coffee Lake only performs at 46% of what it did before the bug fix whereas Haswell under the same circumstance is "only" affected by a 18% performance drop.
  • SaturnusDK - Thursday, January 4, 2018 - link

    However, regular desktop use and gaming is expected to be largely unaffected in general.
  • Threska - Thursday, January 4, 2018 - link

    I seem to remember AMD having something similar to SGX.
  • Zingam - Thursday, January 4, 2018 - link

    Does it hurt to see how your mighty 7700K melts down into oblivion?
  • Pork@III - Thursday, January 4, 2018 - link

    Intel must still sell their processors, otherwise there is no profit: D
  • Hurr Durr - Thursday, January 4, 2018 - link

    SOCKET CHANGE A YEAR KEEPS THE GOYIM IN FEAR!
  • ddrіver - Thursday, January 4, 2018 - link

    Archaios: probably none. Or 1. Or something else completely relevant to a normal gamer. Almost no game is heavy on syscalls so I wouldn't worry about it.
  • Ryan Smith - Thursday, January 4, 2018 - link

    We'll be looking into it. But we're still waiting on the necessary BIOS/microcode updates to become available for our systems.
  • ktell - Thursday, January 4, 2018 - link

    Fantastic article. Great information and well presented. Kudos to the author!
  • Threska - Thursday, January 4, 2018 - link

    Anandtech's famous graphics would help.
  • VulkanMan - Thursday, January 4, 2018 - link

    "Along with not directly being remotely exploitable"

    Incorrect.

    Mozilla Confirms Web-Based Execution Vector for Meltdown and Spectre Attacks, from https://www.bleepingcomputer.com/news/security/moz...
  • Pork@III - Thursday, January 4, 2018 - link

    https://image.prntscr.com/image/Hc3voiEiTgejzKkB0s...
  • ddrіver - Thursday, January 4, 2018 - link

    The article is both late and factually incorrect. Mozilla confirmed that it's remotely exploitable yesterday: https://blog.mozilla.org/security/2018/01/03/mitig...

    Multiple other sources also confirmed that the common practice of daisy chaining attacks makes this bug pretty accessible. The only mitigation is the software patch. The only real fix is a hardware change, as officially recommended by US-CERT.
  • Billy Tallis - Thursday, January 4, 2018 - link

    "Mozilla confirmed that it's remotely exploitable yesterday"

    No, that's not what they said, and that's not what "remotely exploitable" means. The exploit mechanism Mozilla was talking about involves downloading and running JavaScript locally, inside the browser running on your local machine. If you have reasonable security measures in place on your machine, then you'll never download the malicious JavaScript to begin with.
  • ddrіver - Thursday, January 4, 2018 - link

    Ok, dumb it down for me: the exploit involved running JS? Then the only thing standing between an attacker and a successful exploitation is the ability to run that script remotely. Am I right so far?

    Unless there's a "make this sandbox impervious to any attack" switch somewhere in all browsers then I'm pretty sure it can be exploited remotely. It may or may not involve daisy chaining attacks as I said. But remote exploitation is perfectly possible. As demonstrated by history and the multiple documented cases of breaking out of a sandbox and executing code. And Mozilla explicitly says:
    "it is possible to use similar techniques from Web content to read private information between different origins".

    The only way for the sentence to be accurate is if the exploit demands physical presence, hands on the local keyboard, eye on the CPU. Powering on a system that's not plugged in is the kind of "attack" that can't be exploited remotely. It's by design. Running JS? In a browser? Remotely? Outlandish, no?

    The article says "it's not remotely exploitable" not "you should have security measures in place to prevent remote exploitation".

    Trying to redefine what remote exploitation is just to cover up a mistake is demeaning. Nice job Billy. You started from "it's not remotely exploitable" and ended up with "you should have some measures in place to prevent it from being remotely exploitable".
  • ddrіver - Thursday, January 4, 2018 - link

    And just to be clear, I almost feel ashamed for having to go to these lengths: https://en.wikipedia.org/wiki/Exploit_(computer_se...
    "A remote exploit works over a network and exploits the security vulnerability without any prior access to the vulnerable system."

    So yeah, JS? Browsers? Remote exploitation. Which is why Mozilla is implementing the workaround in the browser. Relying on people to implement some generic "reasonable security measures" is not a barrier against exploiting this remotely.
  • cdillon - Thursday, January 4, 2018 - link

    * That's not what "remotely exploitable" means. * Which is what Billy already said. Feel free to argue with the entire security industry if you don't agree with the definition, it would be pointless to do so here. A *local* action is required -- like visiting a web site in a web browser -- to download and execute the malicious code. It is conceptually no different than downloading and executing a trojan email attachment but running JavaScript in a browser typically requires less action on your part unless you're using something like NoScript.

    "Remotely exploitable" is the equivalent of a drive-by shooting, which this is not.
  • Reflex - Thursday, January 4, 2018 - link

    ddriver - To be clear, a remote exploit would mean that your system, connected to the internet, with no applications opened or user present, could be attacked by a remote attacker and compromised. The exploits Mozilla are investigating instead require a user to take actions, such as opening a web browser and navigating to a malicious website. That is considered a local exploit since it requires local action to execute.
  • ddrіver - Thursday, January 4, 2018 - link

    I don't have much expectations from you but I did from AT editors. Here is a random security bulletin from Google listing a few RCEs (Remote code execution): https://source.android.com/security/bulletin/2017-...

    Picking one random RCE from the list (CVE-2017-0713) and going to NVD we get: Access Vector: Network exploitable - Victim must voluntarily interact with attack mechanism

    But what do Google and NVD know when they say what remote execution is?

    Anyway,.. cool, running a JS is not considered a possible remote exploit by AT editors. At least I know where we stand. I don't know if I should feel proud that I happen to know more than the AT guys or sad that I still read people who insist on defending errors instead of correcting them when they're pointed out.
  • Billy Tallis - Thursday, January 4, 2018 - link

    The remote code execution vulnerabilities you have referenced are cases where the victim is sent data by the attacker and bugs in the victim's software lead to the attacker's payload being treated as code and executed.

    The Spectre proof of concept is one where the victim's computer requests code and gets code which is then executed. There is no software bug being exploited to cause the code to run; the PoC starts from the assumption that the victim has already given the attacker permission to run arbitrary (JS) code on the victim's machine.
  • Reflex - Thursday, January 4, 2018 - link

    Others explained it already, but yes you just proved my point ddriver, thanks for that!
  • cdillon - Thursday, January 4, 2018 - link

    CVE-2017-0713 is considered a remote exploit because it does NOT require action by the user to exploit. It allows a "drive-by" attack via methods such as an unsolicited MMS message sent to your phone. You've unwittingly provided another example of the correct usage of "remote exploit" that does not support your argument.
  • BillyONeal - Thursday, January 4, 2018 - link

    A remote exploit means that someone can just send it over the network and take over machines, e.g. EternalBlue. Putting it into a malicious website is a local exploit; you have to convince a user to download that JS and execute it on their own machines.
  • FreckledTrout - Thursday, January 4, 2018 - link

    It's not remotely exploitable in a direct. Sure if there is another attack vector used to run the JS locally but then its the other virus/trojan/etc that was executed remotely that then runs the JS. You are splitting hairs however there is one way that isn't remote execution but is pretty close. Cloud providers like the article mentioned where you are hosting various companies/peoples "stuff" on virtual servers running on the same physical machine then yes a person could setup a little VM on said cloud and start up their JS program trying to steal data from the other VM's on the physical host.
  • peteNYC - Thursday, January 4, 2018 - link

    Does anybody know if current or recent SPARC CPUs are affected by this? I saw one mentioning of POWER being affected in Ryan's article, but nothing about SPARC either here or in a couple of web searches I ran today. If you have any information, please post with a link to the source - Thanks!

    PS. I don't work for or have ever worked for SUN or Oracle, but if SPARC is the odd one out, Larry Elison can buy himself yet another yacht, or at least rehire some of the hardware devs they obsoleted.
  • Reflex - Thursday, January 4, 2018 - link

    I have not seen any official statements from Oracle about SPARC, but since the T4 in 2011 they have also supported out of order execution which likely means at least Spectre is possible on them.
  • Threska - Thursday, January 4, 2018 - link

    I gather the problem is in the implementation of out of order execution, not just it's mere presence.
  • Reflex - Thursday, January 4, 2018 - link

    That is unlikely, so far we have yet to see a OOOE CPU architecture that is not impacted by it and almost none of these CPU families have similar implementations. An issue that is already known to impact POWER, Intel, AMD and ARM is really not implementation specific.
  • Lord of the Bored - Thursday, January 4, 2018 - link

    So my Ultra10 is safe? Awesome! I've got a new daily driver!
  • jjj - Thursday, January 4, 2018 - link

    Any idea why AMD is not vulnerable to Meltdown or a variant of it?

    Anyway, kudos to ARM for providing ample info and handling this well.
    Intel's spin was disgraceful while AMD could have given us more details, not just a few lines.
  • e36Jeff - Thursday, January 4, 2018 - link

    AMD CPUs don't allow processes to access kernel data without explicit permission by default. Meltdown relies on Intel processors not stopping the process from requesting data from the kernel in the first place.
  • jjj - Thursday, January 4, 2018 - link

    Yeah but the more basic idea is to exploit out of order, doesn't have to be aimed at reading the kernel. Would be a milder variant ofc.
  • Reflex - Thursday, January 4, 2018 - link

    We honestly do not know if AMD has unwittingly implemented a preventative measure. The fact that Meltdown does not work as designed today does not mean that when the broader security community is handed all the details and example code they won't be able to make changes that enable Meltdown on AMD. That is how it has worked out on ARM, which initially was reported to be immune to Meltdown but vulnerable to Spectre, but who after some modifications to the sample code for Meltdown were able to make it function on their 2011 and later architectures.

    Basically we just don't know yet.
  • Ryan Smith - Friday, January 5, 2018 - link

    "Any idea why AMD is not vulnerable to Meltdown or a variant of it?"

    AMD's statement on the matter was to the effect that they don't speculate around kernel addresses.

    However what exactly that entails isn't completely clear, since the full inner workings of their branch predictor and specular execution paths aren't completely known to the public. We don't usually get access to those kinds of low-level architectural details. So it may be that they're doing a permissions check before execution, or it could be something else entirely.

    If it were just Intel that was vulnerable to Meltdown, that would likely be a satisfactory explanation. However the fact that ARM independently made themselves vulnerable to it is as well makes all of this a lot more interesting, and hints the issue is more complex than it first appears.
  • tamalero - Friday, January 5, 2018 - link

    They flatly said they do not use any kind of speculative branching. hence why they are not affected at all.
  • tamalero - Friday, January 5, 2018 - link

    And as for your arm statement, only a single processor was affected (to meltdown not spectre).
  • Reflex - Friday, January 5, 2018 - link

    That is incorrect. Four processor lines are vulnerable to Meltdown and 6 more are vulnerable to Spectre.
  • ZolaIII - Friday, January 5, 2018 - link

    Because they are lying.
  • mooninite - Thursday, January 4, 2018 - link

    The big piece of news that no one seems to report: There is no mitigation for Spectre at this time.
  • MadManMark - Thursday, January 4, 2018 - link

    I've seen that reported in many places (including here)
  • Ryan Smith - Friday, January 5, 2018 - link

    "There is no mitigation for Spectre at this time."

    To clarify, there is no COMPLETE mitigation at this time. The risk with Spectre is that it's not just one attack, but a class of them. Right now vendors are still trying to figure out how to best protect against the whole class, and not individual attacks.
  • kjboughton - Thursday, January 4, 2018 - link

    AWS and distributed cloud computing not such a great idea now, is it?
    Quick, better ask the DOD what they think about this.
  • Reflex - Thursday, January 4, 2018 - link

    Why not? While this certainly sucks you'd be just as vulnerable in your own server room, and in this case you have effectively outsourced the remediation (which has already rolled out in Azure and AWS according to statements).
  • Bullwinkle-J-Moose - Thursday, January 4, 2018 - link

    It's a Distributed Operations Disaster (DOD)
  • Threska - Thursday, January 4, 2018 - link

    Big customer cloud providers can have Intel customize their CPUs, so there may, or may not be as big a problem?
  • tamalero - Thursday, January 4, 2018 - link

    Hang on, everyone says that Meltdown can be triggered from outside via VMs. Now you say it needs to be "in site" ?
    Or what kind of "in site" are we talking about" any kind of access to the machine?
  • Lord of the Bored - Thursday, January 4, 2018 - link

    It can be triggered from outside your VM. By code running in another VM on the same physical hardware.
  • Wolfpup - Thursday, January 4, 2018 - link

    Wow, FANTASTIC article. Just what I come here for! Most information I've gotten, AND simultaneously the easiest to understand!

    I wonder, if this can even be mitigated at all in software, if my PCs are no longer getting firmware updates (my "main" PC hasn't gotten one since 2013) does that mean it won't really be fully mitigated (if it's even possible to fully mitigate it) since I'd assume microcode and whatnot is stored in firmware?
  • PeachNCream - Thursday, January 4, 2018 - link

    Thanks Ryan for the detailed article. I'm looking forward to any follow-up performance analysis from Anandtech that covers the impact of the mitigations.
  • Ascaris - Thursday, January 4, 2018 - link

    A few nitpicks here:

    "Spectre attack abuses speculative execution in order to gleam information that should be restricted."

    Glean, not gleam.

    "The principle threat is to shared hosting environments:"

    Principal, not principle.

    "confirms that everything Core architecture-based back to the first generation (Nehalem) is affected."

    Core Solo and Duo were the first generations of Core. Nehalem is the first generation of the Core i-series.
  • Ryan Smith - Friday, January 5, 2018 - link

    Thanks for the nitpicks.

    "Core Solo and Duo were the first generations of Core. Nehalem is the first generation of the Core i-series."

    Despite how absurd it seems, Intel considers Nehalem the first generation of the Core architecture. Yonah and Conroe are not considered part of the family.
  • The_Assimilator - Friday, January 5, 2018 - link

    Oh thank god, someone else who is a better editor than the ones Anandtech actually pays money to.
  • 50UL - Thursday, January 4, 2018 - link

    This is the simplest chart about it, 1/2 page. https://uploads.disquscdn.com/images/cab9430cb6a5a...
  • 50UL - Thursday, January 4, 2018 - link

    This is the simplest chart about it, 1/2 page. https://uploads.disquscdn.com/images/cab9430cb6a5a...
  • vladx - Friday, January 5, 2018 - link

    It's false, there's no eal fix for Spectre in either Intel or AMD, to be fully safe both AMD and Intel would have to forego out-of-order execution completely which would result in massive performance downgrade.

    It's obviously made by an AMD fanboy.
  • Threska - Thursday, January 4, 2018 - link

    Retpoline: a software construct for preventing branch-target-injection

    https://support.google.com/faqs/answer/7625886
  • ash9 - Thursday, January 4, 2018 - link

    "However AMD’s CPUs are still vulnerable to Spectre attacks, and in the long run there are still a lot of unknowns about how dangerous Spectre really is, and how well it can be mitigated."

    This is misleading, you might as well have said ALL hardware is susceptible - in the current situation AMD is NOT involved.

    Really irking, AMD says Zero attack probability with these, but what's printed and echo's is Intel's bogus claims against AMD, when Intel CPUs are in 99.95 of information critical servers in the world. …

    This is what false equivalence Fake News looks like if you haven't been exposed, or head in the sand.
  • Hurr Durr - Thursday, January 4, 2018 - link

    >bbut muh amd
  • Lord of the Bored - Thursday, January 4, 2018 - link

    Actually, AMD appears to be in the wrong. The Meltdown whitepaper shows AMD as partially vulnerable. They weren't sure at time of publication why they weren't getting full power, but had demonstrated the processors were not immune.
  • Ryan Smith - Friday, January 5, 2018 - link

    "This is misleading, you might as well have said ALL hardware is susceptible"

    I did.

    "Essentially every high-performance processor ever made – Intel, AMD, ARM, and POWER – is thought to be vulnerable here"

    AMD is invulnerable to Meltdown. And that's a very good thing right now since Meltdown is the immediate risk. But they are vulnerable to Spectre attacks.
  • Reflex - Friday, January 5, 2018 - link

    We can't really conclude they are invulnerable to Meltdown. They are invulnerable to the existing Meltdown demo code. ARM was also thought to be invulnerable to it until their engineers took that code and made modifications to accommodate specifics of their architecture. We do not know what will be found when the same occurs with AMD, and I would be surprised if they really are as invulnerable as they claim.
  • manoj29 - Thursday, January 4, 2018 - link

    Intel got to know of this in Mid June and Gemini Lake was released in Dec. Are Gemini lake products also affected by meltdown?
  • Ryan Smith - Friday, January 5, 2018 - link

    According to Intel's advisory Gemini Lake is vulnerable as well, though they don't make a distinction between Meltdown and Spectre. However if GL was invulnerable to Meltdown, Intel would have said so, meaning it's reasonable to assume that Gemini Lake is Meltdown-vulnerable just like all other OoOE Atoms.
  • Banks2 - Friday, January 5, 2018 - link

    "Fifteen years ago, China decided to build homegrown processors for PCs, servers, and supercomputers. Now the country's latest chip is powering the world's fastest computer."

    And now we know the reason why. American embargo was not true reason.
  • Reflex - Friday, January 5, 2018 - link

    If their CPU's use branch prediction and OOOE they are vulnerable also. And if they perform reasonably well they likely do.
  • manoj29 - Friday, January 5, 2018 - link

    But that page doesn't list the Gemini Lake Pentium silver series among the affected platforms.
  • versesuvius - Friday, January 5, 2018 - link

    Aren't these bugs, "detectable"? Like any other bug? Apart from presenting some novelty in their method of attack which can be said about any new virus or trojan, what makes them so different from other viruses.

    And nobody should panic because as of now the bug just acquires access to kernel memory and "can" read it. What it does with what it has read, nobody knows. The "fear" is that another exploit will use the services of this exploit to "steal" data from a computer. Will that exploit be "detectable"?

    All and all, the bug looks like the operating system kernel itself. Conversely, going by what the article says every operating system is a bug or a virus, because it can do all that these bugs can do and a lot better. Nobody has ever "panicked" on that account. Everybody trusts their operating systems or there would not be a computer age. The question is what the bugs do with their gains. Then again, if these bugs are detectable, they can be removed, even if they are embedded within a legitimate application by uninstalling the application.
  • LiviuTM - Friday, January 5, 2018 - link

    The main problem is these are NOT SOFTWARE BUGS. In fact, there is no bug, these are HARDWARE DESIGN FLAWS - i.e. the processor works as intended, but a clever attack might exploit the processor characteristics to steal sensitive information which can be further used for a full attack on the machine.
  • asmian - Saturday, January 6, 2018 - link

    > if these bugs are detectable, they can be removed, even if they are embedded within a legitimate application by uninstalling the application.

    That assumes the application is uninstallable, or that you can even detect its footprint. Let me remind people again: SGX. The little bonus in every Intel chip since Skylake. The hidden mode where *you* (any management process) cannot snoop on code or data running there to verify what its doing, but thanks to this convenient flaw *that* undetectable code can now snoop on everything else you are doing, even if it didn't already have uber-privileged access due to the way SGX might have been designed. Good luck mitigating against *that*.

    Spectre/SGX is a malware-writer's wet dream. And you can bet that the acronym agencies are all over this, if they weren't already for many years.
  • Pork@III - Friday, January 5, 2018 - link

    Editing based on the accumulation of information in the public domain related to the issues described. https://image.prntscr.com/image/KlWTOHCjQBG3Y9p8qJ...
  • nik243t - Friday, January 5, 2018 - link

    As NVIDIA Denver and Apple A series chips also use speculation they also have meltdown and spectre flaw. Apple in its statement said that ios devices are affected.Yet to hear things from nvdia
  • PolarisOrbit - Friday, January 5, 2018 - link

    I'm pretty disappointed with Anandtech's coverage here. I read about this on Ars Technica and they talked about how the TLB was divided, what type of code could be used for Spectre to infer memory, and just generally went into more detail on both exploits. But on this site, the Meltdown coverage focuses on the horse race between Intel and AMD while the Spectre coverage is mainly fearmongering. I thought this site was supposed to do the deep dives and stick to facts. When did it become a gossip mill, while less focused sites like Ars now have the more detailed coverage of hardware?
  • Threska - Friday, January 5, 2018 - link

    I'm wondering if we'll be seeing more MRAM? That would allow one to have the entire page table in chip-fast memory. Dispensing with "rings", "modes" and some of the other stuff. Speculation would still exist, but the sensitive information would be out of reach since there's no splitting, or even a TLB for that matter.
  • rjttob - Friday, January 5, 2018 - link

    Two questions I haven't seen asked:

    1. With the kernel-level overhead of these changes, what are the ramifications to power efficiency?

    2. Since both host and guest OS will require the patches, what is the compounded effect of these fixes in a virtualized environment (single windows server hosting 3-4+ guest virtual machines)?

    Has anyone thought about these scenarios and setup any testing for these cases?

    This could affect sales demos on laptops with multi-tier software running across multiple virtual machines.

    Thanks
  • we - Saturday, January 6, 2018 - link

    The Pentium G series is not in the list of affected CPUs published by Intel. Is the Pentium G series unaffected, or is the list incorrect/incomplete? https://security-center.intel.com/advisory.aspx?in...
    Anybody know? (My desktop PC has a G630 and I have an unused G2030)
  • Pork@III - Saturday, January 6, 2018 - link

    Just the list of affected CPUs is not complete.
  • Pork@III - Saturday, January 6, 2018 - link

    https://i.imgur.com/GKPC4DZ.png WoW!!! Must type very big panic button here!

    for details: https://www.epicgames.com/fortnite/forums/news/ann...
  • ilux.merks - Saturday, January 6, 2018 - link

    ' Will the ninth generation intel processor be susceptible to meltdown or spectre attacks? Will they come fixed their hardware design
  • Pork@III - Saturday, January 6, 2018 - link

    Maybe 12th generation Intel Sapphire Rapids will be in health .
  • NICOXIS - Saturday, January 6, 2018 - link

    Here is a no bullshit approach from MattZN commenting on ARS:

    Ok folks, here is the jist of the two major bugs.

    (1) Meltdown bug.

    This is the 1000 pound gorilla. It's essentially a FULL kernel memory disclosure bug. Most kernel's also implement DMAPs which can extend the disclosure to all of physical memory.

    This bug is Intel-specific. Some ARM cpus might also be affected. AMD cpus are immune.

    This bug works as follows: All CPUs do speculative memory reads and speculative execution. INTEL CPUs will allow such speculative reads to cross protect domain boundaries, meaning that the speculative read can access kernel memory which is part of the shared MMU map with userspace (but protected with a bit in the page table entry).

    AMD CPUs DO NOT ALLOW such speculative reads to cross this protection domain. Thus AMD CPUs are immune to this bug.

    This is a major bug. Intel has to fix their (expletive) hardware. A lot of people won't be buying new Intel CPUs that still have this hardware bug.

    The 'mitigation' is to break the user process MMU map into *TWO* separate MMU maps, one for the user process, and one for user->kernel and kernel->user transitions. This means that every single kernel->user and user->kernel transition must reload the MMU page tables twice (in x86 land, a mov *,%cr3 or equivalent).

    The result is that all system calls and interrupts will now incur an extra 150 to 250nS worth of overhead. A system call normally has an overhead of around 100nS, so the mitigation increases this overhead to 250nS-350nS.

    Certain cpu features, such as PCID, can reduce the overhead somewhat, but its still nasty.

    Us kernel programmers have spent 20+ years reducing system call and interrupt overhead, and Intel blew it all up in one day. To say that we are all pissed would be a grave understatement.

    I think many companies will be holding off new Intel CPU purchases because of this bug, until Intel produces new silicon that doesn't have the bug.

    (2) Spectre

    Spectre is a sidechannel attack whereby the normal operation of the system where a user program passes data to the kernel in a system call or to another user program which, combined with cache massaging and branch prediction cache massaging, can cause the kernel or other user program to issue speculative reads and do speculative execution within their valid memory that allows the original user program to discern the contents of kernel memory or the memory belonging to the other user program.

    This is a much harder attack to perpetrate, and harder to mitigate. All CPUs are probably vulnerable to varying degrees. But its heads and tails harder to exploit this bug than it is to exploit the Meltdown bug.

    Specifically, the mitigation for meltdown doesn't help with this bug.

    The meltdown bug (which is Intel specific) is horrendous.

    (3) There is a third bug called a boundary attack which is easy to mitigate and can be ignored for now.

    --

    Also, all of Intel's press releases on these topics are HIGHLY deceptive. Purposefully deceptive.

    First, they try to revector and confuse the issue by saying these bugs cannot modify or delete memory... but nobody was ever saying that. These bugs DISCLOSE protected memory, meaning your cryptographic keys and web sessions aren't safe (among other things). Intel intentionally avoided mentioning that. Intel also didn't mention that Meltdown is essentially a FULL KERNEL MEMORY disclosure bug, and that it is easy to exploit. And that it is Intel-specific due to stupidity on Intel's part.

    Intel is also playing up microcode and BIOS updates for these bugs. What they aren't saying is that these microcode updates amount to ONLY minor mitigations of the Spectre bug. There aren't a complete fix to Spectre or anything close. And, more importantly, THE MICROCODE UPDATES DO NOT FIX THE MELTDOWN BUG AT ALL. We kernel programmers have to implement the horrible performance destroying mitigation to workaround meltdown on Intel CPUs.

    Intel is also trying to push all sorts of crap onto the programming community. They are pushing hard to implement horrible hacks in GCC and other compilers and are trying to push horrible hacks to indirect procedure calls as a mitigation for spectre. THIS WILL NEVER WORK!!!!!. 30,000+ applications would have to be recompiled with the changes and kernels would have more horribly hacked code pushed into them just to obtain a PARTIAL mitigation.

    Spectre can only be completely fixed in hardware.

    Intel is intentionally trying to deceive its customers and its audience. It is the WRONG RESPONSE to these extremely serious bugs, particularly to the Meltdown bug.

    To say that we are pissed at Intel right now would be an understatement of epic proportions.

    -Matt
  • FunBunny2 - Saturday, January 6, 2018 - link

    "The result is that all system calls and interrupts will now incur an extra 150 to 250nS worth of overhead. A system call normally has an overhead of around 100nS, so the mitigation increases this overhead to 250nS-350nS."

    just out of curiosity, what then is the overhead for the equivalent in AMD land?

    "Us kernel programmers have spent 20+ years reducing system call and interrupt overhead, and Intel blew it all up in one day. To say that we are all pissed would be a grave understatement."

    one might ask why it took 2 decades for anyone to notice that AMD and Intel took starkly different approaches to the algorithm? there had to be a reason and benefits, yes? or were these implementation specifics hidden behind copyright/patent/trade secret/etc. barriers?
  • Bullwinkle-J-Moose - Sunday, January 7, 2018 - link

    "Intel is intentionally trying to deceive its customers and its audience. It is the WRONG RESPONSE to these extremely serious bugs"
    --------------------------------------------------------------------------------------------------------

    How can it possibly be wrong?
    Its very profitable to sell most of your Intel stock before notifying customers

    and then there's all that inventory that needs to be sold, but not at discount prices I can tell you, no siree!
  • FMinus - Monday, January 8, 2018 - link

    How does the Epyc stack to Xeon now Anandtech?
  • Cumulus7 - Wednesday, January 10, 2018 - link

    Exactly! Now we need another server-CPU-shootout. All old test data suddenly seems obsolete....
  • Round - Monday, January 8, 2018 - link

    Sigh.. Too bad that the word "performant" gets used in an article intended for mass consumption.. It wasn't a word 10 years ago, and it still isn't a word today, irrespective of those that think it is....
  • twtech - Thursday, January 11, 2018 - link

    The hack method central to both of these attacks is really pretty ingenious, and reminds me of something Sherlock Holmes might have come up with, if he worked in information security.

    This is essentially Meltdown in a nutshell:

    Accessing data from main memory is a (comparatively) really slow operation for a CPU. For that reason, the CPU has a small amount of memory on-chip called cache where it can store the most recently used values.

    A computer program is a set of sequential instructions that tell the CPU what to do, in order. So if the processor needs to load a value from memory, normally it would wait until it reached that instruction, issue a load request, and then wait for a significant amount of time for the data to come in over the bus.

    That's not very efficient, so a feature called "speculative execution" was added. With speculative execution, in addition to executing the current instruction, the processor will also essentially look ahead beyond that point to future instructions, and see what operations it might be able to get started early.

    Since normal execution not actually there yet, it's not even guaranteed that the speculative work it's doing will actually be used. The instructions may contain a branch - which is essentially, "skip past these instructions", or "skip over these, but do those instead" - and the CPU doesn't know yet which way it will go. So rather than waiting to find out, the CPU just speculatively executes them anyway. If they turn out to be unused, the CPU will discard the unused values and everything continues on as if the speculative execution had never happened.

    Or so they thought. With Meltdown, the attacking software gets the CPU to speculatively load some data from a memory location the program isn't allowed to access, placed inside a branch that will never actually execute. So that causes the desired value to be loaded into cache, and since the program never actually executes the instructions with the invalid load, the program doesn't crash.

    But what good is that to the hack program if it can never actually inspect the value that it caused to be loaded into cache, right? That's where the ingenious trick comes in. In addition to loading in the value from a memory address it can't access, it further has the CPU speculatively load in a second value, from a memory address that the program is allowed to access. The memory location of that second variable however is chosen based on the contents of the first variable.

    Because we know that loading a value from cache is much faster than loading a value from main memory, the attacking program can then test and figure out which memory location was chosen to be the 2nd one loaded in, by timing how long the operation takes.

    Since that second memory location was chosen based on the value of the data in the first memory location, the program has now has gained some information about what is stored in the first memory location that it's not supposed to have. And due to the magic of computers being extremely fast and predictable, the attacking program can repeat this process many times over to essentially indirectly read the contents of protected memory that should only be readable by the OS.
  • thuckabay - Friday, January 12, 2018 - link

    This is NOT spam, but a legitimate comment AnandTech: I am not willing to sacrifice the kind of performance noted for my Windows 7 laptop running a Sandy Bridge i7 CPU. That is stupid, especially given that there really is NO threat. Now that so many systems are going to be updated, there is little reason for any scumbags to try to exploit these vulnerabilities, IMO. From my perspective, the cure is far worse than the disease, especially on older hardware / OS combinations. It just is not worth it. So, I believe Microsoft should make a way to have these patches be OPTIONAL and AVOIDABLE and UNINSTALLABLE. This is crap!
  • UtilityMax - Sunday, January 14, 2018 - link

    So go sue Intel or turn off the updates and run your Windows 7 unpatched. doh
  • linuxgeex - Tuesday, January 23, 2018 - link

    "More to Come
    Be sure to check back later today for some additional information on these attacks. In particular, I’m looking to further explore the importance of speculative execution, and why an attack against it may have some significant ramifications for CPU designs down the line."

    That was 18 days ago. You encouraged us to come back later the same day. Where's the update?
  • Rοb - Wednesday, January 24, 2018 - link

    @linuxgeex - I did some searching and the patches have been the subject of much criticism.

    There's been some systems rendered unbootable and some rebooting.

    Once successfully applied many benchmarks experience an insignificant change while some are over 20% slower.

    Many patches have been rolled back or withdrawn.

    Linus Torvalds has given Intel heck in a post over the weekend ...

    Apple claims they've had success ...

    ---

    One can only hope that the relative silence and possibly slower rollout of AMD's Zen 2 (Epyc 7 nm) is related to thoroughly testing and investigating that moving forward they will be immune and have the necessary isolation in place to run multiple processes with proper compartmentization.

    As the author stated at the beginning of his article, he's suffering a meltdown and haunted by spectres.

    🔥+👻=🌋🌀
  • HStewart - Monday, March 5, 2018 - link

    According to eWeek (3/2/2018), Microsoft and I assume Intel has released official patches for Windows 10 for Meltdown and Spectre

    http://www.eweek.com/security/microsoft-resumes-is...

    Hopefully this is end of this problem.

Log in

Don't have an account? Sign up now