CPU Vulnerabilities, Meltdown and Spectre, Kernel Page Table Isolation Patches, and more

Discussion in 'Hardware Components and Aftermarket Upgrades' started by hmscott, Jan 2, 2018.

  1. hmscott

    hmscott Notebook Nobel Laureate

    Reputations:
    4,882
    Messages:
    17,044
    Likes Received:
    20,951
    Trophy Points:
    931
    Working around Intel Hardware Flaws
    by Zack Brown, on April 30, 2018
    https://www.linuxjournal.com/content/working-around-intel-hardware-flaws

    "Efforts to work around serious hardware flaws in Intel chips are ongoing. Nadav Amit posted a patch to improve compatibility mode with respect to Intel's Meltdown flaw. Compatibility mode is when the system emulates an older CPU in order to provide a runtime environment that supports an older piece of software that relies on the features of that CPU. The thing to be avoided is to emulate massive security holes created by hardware flaws in that older chip as well.

    In this case, Linux is already protected from Meltdown by use of PTI (page table isolation), a patch that went into Linux 4.15 and that was subsequently backported all over the place. However, like the BKL (big kernel lock) in the old days, PTI is a heavy-weight solution, with a big impact on system speed. Any chance to disable it without reintroducing security holes is a chance worth exploring.

    Nadav's patch was an attempt to do this. The goal was "to disable PTI selectively as long as x86-32 processes are running and to enable global pages throughout this time."

    One problem that Nadav acknowledged was that since so many developers were actively working on anti-Meltdown and anti-Spectre patches, there was plenty of opportunity for one patch to step all over what another was trying to do. As a result, he said, "the patches are marked as an RFC since they (specifically the last one) do not coexist with Dave Hansen's enabling of global pages, and might have conflicts with Joerg's work on 32-bit."

    Andrew Cooper remarked, chillingly:

    "Being 32bit is itself sufficient protection against Meltdown (as long as there is nothing interesting of the kernel's mapped below the 4G boundary). However, a 32bit compatibility process may try to attack with Spectre/SP2 to redirect speculation back into userspace, at which point (if successful) the pipeline will be speculating in 64bit mode, and Meltdown is back on the table. SMEP will block this attack vector, irrespective of other SP2 defenses the kernel may employ, but a fully SP2-defended kernel doesn't require SMEP to be safe in this case.
    And Dave, nearby, remarked, "regardless of Meltdown/Spectre, SMEP is valuable. It's valuable to everything, compatibility-mode or not."

    SMEP (Supervisor Mode Execution Protection) is a hardware mode, whereby the OS can set a register on compatible CPUs to prevent userspace code from running. Only code that already has root permissions can run when SMEP is activated.

    Andy Lutomirski said that he didn't like Nadav's patch because he said it drew a distinction between "compatibility mode" tasks and "non-compatibility mode" tasks. Andy said no such distinction should be made, especially since it's not really clear how to make that distinction, and because the ramifications of getting it wrong might be to expose significant security holes.

    Andy felt that a better solution would be to enable and disable 32-bit mode and 64-bit mode explicitly as needed, rather than guessing at what might or might not be compatibility mode.

    The drawback to this approach, Andy said, was that old software would need to be upgraded to take advantage of it, whereas with Nadav's approach, the judgment would be made automatically and would not require old code to be updated.

    Linus Torvalds was not optimistic about any of these ideas. He said, "I just feel this all is a nightmare. I can see how you would want to think that compatibility mode doesn't need PTI, but at the same time it feels like a really risky move to do this." He added, "I'm not seeing how you keep user mode from going from compatibility mode to L mode with just a far jump."

    In other words, the whole patch, and any alternative, may just simply be a bad idea.

    Nadav replied that with his patch, he tried to cover every conceivable case where someone might try to break out of compatibility mode and to re-enable PTI protections if that were to happen. Though he did acknowledge, "There is one corner case I did not cover (LAR) and Andy felt this scheme is too complicated. Unfortunately, I don't have a better scheme in mind."

    Linus remarked:

    Sure, I can see it working, but it's some really shady stuff, and now the scheduler needs to save/restore/check one more subtle bit.

    And if you get it wrong, things will happily work, except you've now defeated PTI. But you'll never notice, because you won't be testing for it, and the only people who will are the black hats.

    This is exactly the "security depends on it being in sync" thing that makes me go "eww" about the whole model. Get one thing wrong, and you'll blow all the PTI code out of the water.

    So now you tried to optimize one small case that most people won't use, but the downside is that you may make all our PTI work (and all the overhead for all the _normal_ cases) pointless.

    And Andy also remarked, "There's also the fact that, if this stuff goes in, we'll be encouraging people to deploy 32-bit binaries. Then they'll buy Meltdown-fixed CPUs (or AMD CPUs!) and they may well continue running 32-bit binaries. Sigh. I'm not totally a fan of this."

    The whole thread ended inconclusively, with Nadav unsure whether folks wanted a new version of his patch.

    The bottom line seems to be that Linux has currently protected itself from Intel's hardware flaws, but at a cost of perhaps 5% to 30% efficiency (the real numbers depend on how you use your system). And although it will be complex and painful, there is a very strong incentive to improve efficiency by adding subtler and more complicated workarounds that avoid the heavy-handed approach of the PTI patch. Ultimately, Linux will certainly develop a smooth, near-optimal approach to Meltdown and Spectre, and probably do away with PTI entirely, just as it did away with the BKL in the past.

    Until then, we're in for some very ugly and controversial patches."
     
    Riley Martin likes this.
  2. hmscott

    hmscott Notebook Nobel Laureate

    Reputations:
    4,882
    Messages:
    17,044
    Likes Received:
    20,951
    Trophy Points:
    931
    (Vulnerability Patches are Masking actual performance losses)

    CPU Utilization Is Wrong on PCs, and Getting Worse Every Year

    Joel Hruska on May 2, 2018 at 8:36 am
    https://www.extremetech.com/computi...-is-wrong-on-pcs-and-getting-worse-every-year

    "CPU utilization is wrong. That’s the argument Brandon Gregg, Netflix’s senior performance architect, has leveled against one of the most fundamental performance measurement tools we use when evaluating a system. According to Gregg, CPU utilization as reported by Windows isn’t just wrong — it’s actively getting worse over time.

    If you’ve ever dug into this topic, you’re aware of some of the ways that CPU utilization isn’t reported accurately. Ever since Intel (and now AMD) added Hyper-Threading / SMT support, there’s been a discrepancy between how cores are presented in Task Manager and what resources are actually available. Windows, Linux, and other operating systems report the total number of cores and measure CPU utilization as if each logical core was actually a physical core. But that’s not the problem Gregg is discussing. First, there’s the problem of thread stalling. If you see your CPU running at 90 percent load, you might think it looks like this:
    wjHROEX.png
    In reality, Gregg points out, what might be going on is something akin to this, in which the CPU is stalled and waiting for data but isn’t actually doing any work.
    mZoYjal.png
    If you think about it, you’ve probably seen this in action. If you’ve ever performed a rendering or Photoshop manipulation that really tasked your CPU, performance — even UI performance — may slow to a crawl while the workload is executing. There are ways to avoid this problem by setting the total number of active threads or the priority of the workload itself, but if you’ve worked with computers for any length of time you’ve probably seen instances where 100 percent CPU utilization didn’t actually mean 100 percent CPU utilization. The problem, according to Gregg, is that memory accesses often slow the system. This is known as the CPU-DRAM gap, and it’s a topic we’ve discussed before at ET.

    The entire reason we implemented advanced caching structures with L1, L2, and L3 cache is precisely because the DRAM gap stalls out CPUs and lowers overall performance. But now, there’s another problem causing issues for CPU utilization: Spectre and Meltdown patches.
    LzWOmPw.png
    CPU utilization is wrong
    Opensource.com
    Published on Apr 23, 2018
    Everyone uses %CPU to measure performance, but everyone is wrong, says Netflix's Brendan Gregg in this Lightning Talk from UpSCALE at the 2018 Southern California Linux Expo (SCALE).
     
  3. hmscott

    hmscott Notebook Nobel Laureate

    Reputations:
    4,882
    Messages:
    17,044
    Likes Received:
    20,951
    Trophy Points:
    931
    Specter NG: Intel shifts its first patches - postponed co-ordinated release
    07.05.2018 14:27 clock Jürgen Schmidt (translated from German with Google Translate)
    https://www.heise.de/security/meldu...e-Veroeffentlichung-aufgeschoben-4043790.html

    "Actually, the release of the first Specter NG patches was planned for Monday (May 7th). But Intel has requested a delay and received it. New, exclusive information shows how Specter-NG should go now."

    After c't exclusively documented the existence of several vulnerabilities in Intel's processors under the name Specter Next Generation last week, the first Specter NG patch was originally scheduled to be released on May 7th. However, Intel seems to be having problems getting the required updates ready in time, and therefore postponing the publication co-ordinated with the discoverers - once for 14 days, if possible even longer. This suggests information about the other patch plans by the processor manufacturer, heise Security and c't.

    Intel is now planning a coordinated release on May 21, 2018. New microcode updates are due to be released on this date. At the same time, technical information on the nature of at least two of the Specter NG gaps is likely to be published. However, this date is not set in stone: According to our information, Intel has already requested a further extension until July 10.

    The number of systems that need these patches is enormous. Because these Specter NG gaps not only affect all Core i processors and their Xeon derivatives at least since their release (Nehalem, 2010); These are Intel's standard CPUs for desktops, notebooks and servers. Also vulnerable are Atom-based Pentium, Celeron and Atom processors since 2013. And they are also used in tablets, smartphones and embedded devices.

    More Specter NG patches in August
    For the removal of the most dangerous Specter NG gap, Intel's customers have to wait even longer. It also affects the Core i and Xeon processors and allows them to attack their hosts or other VMs from a virtual machine. This is fatal, especially when using cloud systems. Currently, Intel plans to patch only in the third quarter. Specifically, the 14th of August is in the room. To secure the architecture, Intel plans a combination of hardware updates in the form of new microcode and software improvements that the operating system manufacturers have to implement.

    But this still does not cover all Specter NG gaps. Because at least four gaps should be defused according to Intel's plans, the software manufacturers in their products. According to our information, this is already partially tacit under the hood; but larger Specter NG patches for Windows, Linux, macOS and other affected operating systems will follow as well. Of course, we will also report on their dates as soon as we have reliable information."

    Comments (German, use Google Translate)

    Intel Spectre-NG Patches Delayed As Intel Not Able To Get Them Ready In Time
    By Ahmad Hassan, May 8, 2018
    https://segmentnext.com/2018/05/08/intel-spectre-ng-patch-delayed/

    "Recently, 8 new Spectre security vulnerabilities titled “Spectre-NG” were made public for Intel chips and Intel was working hard to roll out patches for these new security vulnerabilities, however, the upcoming Intel Spectre-NG Patches have been delayed.

    These Intel Spectre-NG Patches were supposed to drop on May 7, 2018, but now Intel has delayed the patches for the newly discovered security exploits by 14 days and are now scheduled to roll out on May 21, 2018.

    These patches will address the Spectre-NG security exploit in Intel Core processors starting from 1st gen Intel core processors to 8th gen Coffee Lake CPUs.

    These security exploits have emerged shortly after Intel revealed 8th gen CPU refreshes which have completely been redesigned to counter Spectre and Meltdown security exploits. (This is not true for recent 8th gen releases, CPU redesigns by Intel said to be in 2nd half, not now, see linked article)

    These redesigns will be seen in Intel 8th Gen core Chips that will ship in the second half of 2018. While Intel didn’t talk about the performance impact of the redesign but said that they will bring the performance improvements that are expected of the upcoming Coffee Lake Chips.

    Speaking of Intel processors, Intel has discontinued the Kaby Lake-X CPUs due to low sales and poor market response. These CPUs were announced just 11 months ago and were specifically designed and marketed to PC enthusiasts.

    According to Intel, the response from the consumers wasn’t very good and due to low sales, Intel has decided to move Intel Kaby Lake-X CPUs to EOL status.

    The Intel Kaby Lake-X CPUs are based 14nm+ architecture and are basically quad-core processors. The processors included in the Kaby Lake-X are Core i7-7740X and Core i5-7640X.

    In related news, reportedly Intel will reveal its Discrete GPUs at CES 2019. According to the report, Intel has completed the first phase of the development of its discrete GPUs and are now preparing for a big reveal and launch of the Intel Discrete GPU.

    Do you think the upcoming 8th gen refreashes of Intel Coffee Lake processors will be secure from such exploits? Let us know in the comments.

    Source: Heise "
     
    Last edited: May 8, 2018
    Riley Martin and ajc9988 like this.
  4. Papusan

    Papusan JOKEBOOKS = That sucks! Dont wast your $$ on FILTH

    Reputations:
    14,266
    Messages:
    19,354
    Likes Received:
    29,970
    Trophy Points:
    931
    Not sure if this is posted...
    KB4100347: Intel microcode updates
    Applies to: Windows Server version 1803 - Windows 10 version 1803

    As I noted on May 4, when Microsoft hurriedly released Win10 version 1803 at the end of last month, it forgot to include the Meltdown/Spectre fixes that are in Win10 1703 and 1709. With KB 4100347, it appears as if Microsoft has finally released the Spectre V2 microcode patches for Win10 1803 and Server 1803but only for Intel Kaby Lake, Coffee Lake, Broadwell, SkyLake, Haswell, Ivy Bridge and Sandy Bridge processors.

    Direct download link; KB4100347: Intel microcode updates
     
  5. Robbo99999

    Robbo99999 Notebook Prophet

    Reputations:
    3,337
    Messages:
    5,690
    Likes Received:
    4,366
    Trophy Points:
    431
    Cool, thanks! Now, to apply or not to apply - that is the question! Sandybridge microcodes - that's something new too when it comes to microcodes released from Microsoft - could do some before & after testing on my Sandybridge i7-2920XM CPU laptop.

    P.S. I know some of you think you have to apply these microcodes, I mean really should apply them (looking at you hmscott!), I'm undecided - I'll probably end up flipping between them!
     
  6. Jarip

    Jarip Notebook Enthusiast

    Reputations:
    10
    Messages:
    10
    Likes Received:
    16
    Trophy Points:
    6
    I would prefer bios update for my new Asus laptop, but I am not sure do I ever receive it from Asus. Well, then I have 2 choice, to install MS patch or not install it. I decided wait for a while, to might have bios update as well as firmware update for Intel Management Engine. Anyway, it is good to know that we have some MS patch in a case of emergency, applied for Spectre :)
     
    Last edited: May 16, 2018
    hmscott, Riley Martin and Robbo99999 like this.
  7. Jarip

    Jarip Notebook Enthusiast

    Reputations:
    10
    Messages:
    10
    Likes Received:
    16
    Trophy Points:
    6
    Deleted - where is option to delete my post ?
     
    hmscott likes this.
  8. Robbo99999

    Robbo99999 Notebook Prophet

    Reputations:
    3,337
    Messages:
    5,690
    Likes Received:
    4,366
    Trophy Points:
    431
    Yep, it's good to have the microcode update available through Microsoft if you want it.

    OK, updated my Sandybridge laptop with the new microcode delivered through Microsoft for the latest Windows 10 (version 1803), KB4100347 that Papusan mentioned a few posts back. Tested Cinebench R15 both before & after the microcode update, I lost 2.6% performance (let's call it 3%!). Weirdly enough I lost the same exact 2.6% performance on my Skylake desktop by application of the new microcode. This is an average of 3 runs of Cinebench R15. So it looks like the Spectre patch doesn't slow down Sandybridge anymore so than Skylake, which is good news! The Meltdown patch, now that's supposed to slow down Sandybridge more than the more modern CPUs (like Skylake) - that's an OS level patch though, not microcode related. InSpectre now says my laptop is protected from Spectre. My laptop feels the same before & after patch, not noticing any difference in speed of web browsing or program opening - but not measured these, just subjective.
     
    Riley Martin, Papusan and hmscott like this.
  9. James D

    James D Notebook Prophet

    Reputations:
    2,269
    Messages:
    4,852
    Likes Received:
    1,047
    Trophy Points:
    231
    Could you please now also test disabling protection from Spectre in InSpectre tool?
    My theory is that new microcodes without enabled protection in OS should bring some advantage provided you had old microcode for SB processor.
    One guy claims he got better memory allocation speeds with MS updates yet disabled protection (although he tested this on ancient Pentium D-820 so might be a fluke).
     
    hmscott likes this.
  10. Robbo99999

    Robbo99999 Notebook Prophet

    Reputations:
    3,337
    Messages:
    5,690
    Likes Received:
    4,366
    Trophy Points:
    431
    I did as you asked. No performance improvement with the new microcode and Spectre Protection disabled vs old microcode (and of course Spectre Protection disabled by default).

    Going back to my previous post I'm just pleased that the Spectre performance hit of Sandybridge isn't any bigger than that of a modern CPU like Skylake, at least when it comes to Cinebench R15.
     
    hmscott, James D and 0lok like this.
Loading...

Share This Page