Windows 10: Kernel memory leaking Intel processor design flaw

Page 5 of 14 FirstFirst ... 34567 ... LastLast

  1. Posts : 64
    Windows 10 Anniversary update RTM
       03 Jan 2018 #40

    no updates still stuck on .125
      My ComputerSystem Spec


  2. Posts : 64
    Windows 10 Anniversary update RTM
       03 Jan 2018 #41

    ha ha check out intel's website their trying to say its not an issue and say that other manufacturers are the ones who have the security concerns
      My ComputerSystem Spec


  3. Posts : 64
    Windows 10 Anniversary update RTM
       03 Jan 2018 #42

    im going to run before and after patch benchmarks see what happens
      My ComputerSystem Spec


  4. Posts : 6,993
    10 Home x64 (1803) (10 Pro on 2nd pc)
       03 Jan 2018 #43

    squaleca said: View Post
    no updates still stuck on .125
    It hasn't reached Windows Update servers yet, but the standalone package is available now on the Microsoft Update Catalog, link is in first post here...

    Cumulative Update KB4056892 Windows 10 v1709 Build 16299.192
      My ComputersSystem Spec


  5. Posts : 64
    Windows 10 Anniversary update RTM
       03 Jan 2018 #44

    yea i know i just found it thanks
    how come the notes for the update say nothing about fixing the flaw??
      My ComputerSystem Spec


  6. Posts : 64
    Windows 10 Anniversary update RTM
       03 Jan 2018 #45

    After


    Intel Core i7-2640M
    3,461 User benchmarks - Average bench 41%
    CPU, 1 CPU, 2 cores, 4 threads
    Base clock 2.8 GHz, turbo 3.3 GHz (avg)

    Performing above expectations (68th percentile)

    47.3%Average SC Int 71.8
    SC Float 76.2
    SC Mixed 80.6


    61% 76.2 Pts
    QC Int 210
    QC Float 210
    QC Mixed 221


    48% 214 Pts
    MC Int 207
    MC Float 215
    MC Mixed 216


    32% 213 Pts
    before

    Intel Core i7-2640M
    3,461 User benchmarks - Average bench 41%
    CPU, 1 CPU, 2 cores, 4 threads
    Base clock 2.8 GHz, turbo 3.3 GHz (avg)

    Performing as expected (54th percentile)

    44.7%Average SC Int 83.2
    SC Float 83.4
    SC Mixed 84.4


    67% 83.7 Pts
    QC Int 179
    QC Float 196
    QC Mixed 196


    43% 190 Pts
    MC Int 197
    MC Float 201
    MC Mixed 200


    30% 199 Pts
    whooo i gained performance obviously not b/c of the patch but it doesnt look like it has any impact on performance???
      My ComputerSystem Spec


  7. Posts : 1,524
    WinX Pro x64 IP current
       04 Jan 2018 #46

    squaleca said: View Post
    After


    Intel Core i7-2640M
    3,461 User benchmarks - Average bench 41%
    CPU, 1 CPU, 2 cores, 4 threads
    Base clock 2.8 GHz, turbo 3.3 GHz (avg)

    Performing above expectations (68th percentile)

    47.3%Average SC Int 71.8
    SC Float 76.2
    SC Mixed 80.6


    61% 76.2 Pts
    QC Int 210
    QC Float 210
    QC Mixed 221


    48% 214 Pts
    MC Int 207
    MC Float 215
    MC Mixed 216


    32% 213 Pts
    before

    Intel Core i7-2640M
    3,461 User benchmarks - Average bench 41%
    CPU, 1 CPU, 2 cores, 4 threads
    Base clock 2.8 GHz, turbo 3.3 GHz (avg)

    Performing as expected (54th percentile)

    44.7%Average SC Int 83.2
    SC Float 83.4
    SC Mixed 84.4


    67% 83.7 Pts
    QC Int 179
    QC Float 196
    QC Mixed 196


    43% 190 Pts
    MC Int 197
    MC Float 201
    MC Mixed 200


    30% 199 Pts
    whooo i gained performance obviously not b/c of the patch but it doesnt look like it has any impact on performance???
    cereberus said: View Post
    It is funny on other forums seeing mass hysteria about the possible 30% drop in
    performance due to new updated expected to fix intel bug.

    It shows how little the mass media understands about factors that affect performance.

    Never let a good story get in way of the truth - lol.
    See the following quotations from earlier in the thread

    pparks1 said: View Post
    Well, for a company that utilizes AWS quite heavily, where context switching at the hypervisor level is the name of the game, the impact of this software update is going to be huge. I know we have been discussing this bug at length over the past day here at the office.

    For a gamer, worried about benchmarks, probably won't feel this bug caused any noticeable change.

    Everything depends upon the workload.
    It's not rocket science, but before you go believing all the hype, it would help if you actually did more reading than what so-called modern journalists (aka bloggers) put out over the wires.

    For a good,thorough understanding of what they vulnerabilities are and are not, go directly to the sources:

    Meltdown: https://meltdownattack.com/meltdown.pdf

    Spectre: https://spectreattack.com/spectre.pdf

    And, just to make it a bit more easy to glean (since both of those papers get really technical really quickly), here is a transcription of a post I made in another forum:

    _______________________

    OK, here is some more analysis and opinion from me.

    First off, Meltdown - also known as http://www.cve.mitre.org/cgi-bin/cve...name=2017-5754

    Notice the reserve date? Yeah, 1 Feb 2017 - a year ago. While the disclaimer is right there saying that it doesn't necessarily reflect the discovery date, you can bet your bottom dollar that no company is gonna reserve a CVE that doesn't exist. Plus, this came to more light around July or August, and was brushed off back then as well.

    Second, one of the earlier links posted (I think) made a direct mention of a patch being issues for ARM devices, but that the authors did not know anything else about the patch. That right there got me digging deeper as well.

    This is not going to end well for chipmakers for 2018. Not well at all.

    First, let's tackle Meltdown - it's been under scrutiny for more than a year now. From the research paper on it: https://meltdownattack.com/meltdown.pdf


    Acknowledgment

    We would like to thank Anders Fogh for fruitful discussions at BlackHat USA 2016 and BlackHat Europe 2016, which ultimately led to the discovery of Meltdown. Fogh [5] already suspected that it might be possible to abuse speculative execution in order to read kernel memory in user mode but his experiments were not successful. We would also like to thank Jann Horn for comments on an early draft. Jann disclosed the issue to Intel in June. The subsequent activity around the KAISER patch was the reason we started investigating this issue. Furthermore, we would like Intel, ARM, Qualcomm, and Microsoft for feedback on an early draft.

    We would also like to thank Intel for awarding us with a bug bounty for the responsible disclosure process, and their professional handling of this issue through communicating a clear timeline and connecting all involved researchers. Furthermore, we would also thank ARM for their fast response upon disclosing the issue.
    I knew that at least part of the new buzz from last week was regarding this issue I had already read about, twice, in fact, both last year, once early and again around July or August. And it gets tricky, quickly, because of this:


    Meltdown fundamentally changes our perspective on the security of hardware optimizations that manipulate the state of microarchitectural elements. The fact that hardware optimizations can change the state of microarchitectural elements, and thereby imperil secure software implementations, is known since more than 20 years [20]. Both industry and the scientific community so far accepted this as a necessary evil for efficient computing. Today it is considered a bug when a cryptographic algorithm is not protected against the microarchitectural leakage introduced by the hardware optimizations. Meltdown changes the situation entirely. Meltdown shifts the granularity from a comparably low spatial and temporal granularity, e.g., 64-bytes every few hundred cycles for cache attacks, to an arbitrary granularity, allowing an attacker to read every single bit. This is nothing any (cryptographic) algorithm can protect itself against. KAISER is a short-term software fix, but the problem we uncovered is much more significant.

    We expect several more performance optimizations in modern CPUs which affect the microarchitectural state in some way, not even necessarily through the cache. Thus, hardware which is designed to provide certain security guarantees, e.g., CPUs running untrusted code, require a redesign to avoid Meltdown- and Spectre-like attacks. Meltdown also shows that even error-free software, which is explicitly written to thwart side-channel attacks, is not secure if the design of the underlying hardware is not taken into account.

    With the integration of KAISER into all major operating systems, an important step has already been done to prevent Meltdown. KAISER is also the first step of a paradigm change in operating systems. Instead of always mapping everything into the address space, mapping only the minimally required memory locations appears to be a first step in reducing the attack surface. However, it might not be enough, and an even stronger isolation may be required. In this case, we can trade flexibility for performance and security, by e.g., forcing a certain virtual memory layout for every operating system. As most modern operating system already use basically the same memory layout, this might be a promising approach.

    Meltdown also heavily affects cloud providers, especially if the guests are not fully virtualized. For performance reasons, many hosting or cloud providers do not have an abstraction layer for virtual memory. In such environments, which typically use containers, such as Docker or OpenVZ, the kernel is shared among all guests. Thus, the isolation between guests can simply be circumvented with Meltdown, fully exposing the data of all other guests on the same host. For these providers, changing their infrastructure to full virtualization or using software workarounds such as KAISER would both increase the costs significantly.

    Even if Meltdown is fixed, Spectre [19] will remain an issue. Spectre [19] and Meltdown need different defenses. Specifically mitigating only one of them will leave the security of the entire system at risk. We expect that Meltdown and Spectre open a new field of research to investigate in what extent performance optimizations change the microarchitectural state, how this state can be translated into an architectural state, and how such attacks can be prevented.
    This is not good stuff at all. But it gets worse. Spectre is way, way worse. From the Spectre paper: https://spectreattack.com/spectre.pdf


    Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim’s confidential information via a side channel to the adversary. This paper describes practical attacks that combine methodology from side channel attacks, fault attacks, and return-oriented programming that can read arbitrary memory from the victim’s process. More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/side-channel attacks. These attacks represent a serious threat to actual systems, since vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices.
    Uh, that pretty much covers everything. Everything from computers to PDAs to cell phones to IoT devices to cloud servers to you name it.

    And the solution?


    While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processor designs as well as updates to instruction set architectures (ISAs) to give hardware architects and software developers a common understanding as to what computation state CPU implementations are (and are not) permitted to leak.
    Yeah, probably gonna be putting off my build as long as possible now. If re-imagining the CPU can happen in an appropriate timeline to eliminate this type of a vulnerability (but who is to say that, in trying to work around this one, hey don't create one that is much worse?).


    The practicality of microcode fixes for existing processors is also unknown. It is possible that a patch could disable speculative execution or prevent speculative memory reads, but this would bring a significant performance penalty. Buffering speculatively-initiated memory transactions separately from the cache until speculative execution is committed is not a sufficient countermeasure, since the timing of speculative execution can also reveal information. For example, if speculative execution uses a sensitive value to form the address for a memory read, the cache status of that read will affect the timing of the next speculative operation. If the timing of that operation can be inferred, e.g., because it affects a resource such as a bus or ALU used by other threads, the memory is compromised. More broadly, potential countermeasures limited to the memory cache are likely to be insufficient, since there are other ways that speculative execution can leak information. For example, timing effects from memory bus contention, DRAM row address selection status, availability of virtual registers, ALU activity, and the state of the branch predictor itself need to be considered. Of course, speculative execution will also affect conventional side channels, such as power and EM.

    As a result, any software or microcode countermeasure attempts should be viewed as stop-gap measures pending further research.
    So, basically, we're screwed if this ever makes it into the dark web - which it just did.

    And this sums it all up:


    Software isolation techniques are extremely widely deployed under a variety of names, including sandboxing, process separation, containerization, memory safety, proof-carrying code. A fundamental security assumption underpinning all of these is that the CPU will faithfully execute software, including its safety checks. Speculative execution unfortunately violates this assumption in ways that allow adversaries to violate the secrecy (but not integrity) of memory and register contents. As a result, a broad range of software isolation approaches are impacted. In addition, existing countermeasures to cache attacks for cryptographic implementations consider only the instructions ‘officially’ executed, not effects due to speculative execution, and are also impacted.

    The feasibility of exploitation depends on a number of factors, including aspects of the victim CPU and software and the adversary’s ability to interact with the victim. While network-based attacks are conceivable, situations where an attacker can run code on the same CPU as the victim pose the primary risk. In these cases, exploitation may be straightforward, while other attacks may depend on minutiae such as choices made by the victim’s compiler in allocating registers and memory. Fuzzing tools can likely be adapted by adversaries to find vulnerabilities in current software.

    As the attack involves currently-undocumented hardware effects, exploitability of a given software program may vary among processors. For example, some indirect branch redirection tests worked on Skylake but not on Haswell. AMD states that its Ryzen processors have “an artificial intelligence neural network that learns to predict what future pathway an application will take based on past runs” [3, 5], implying even more complex speculative behavior. As a result, while the stop-gap countermeasures described in the previous section may help limit practical exploits in the short term, there is currently no way to know whether a particular code construction is, or is not, safe across today’s processors – much less future designs.

    A great deal of work lies ahead. Software security fundamentally depends on having a clear common understanding between hardware and software developers as to what information CPU implementations are (and are not) permitted to expose from computations. As a result, long-term solutions will require that instruction set architectures be updated to include clear guidance about the security properties of the processor, and CPU implementations will need to be updated to conform.

    More broadly, there are trade-offs between security and performance. The vulnerabilities in this paper, as well as many others, arise from a longstanding focus in the technology industry on maximizing performance. As a result, processors, compilers, device drivers, operating systems, and numerous other critical components have evolved compounding layers of complex optimizations that introduce security risks. As the costs of insecurity rise, these design choices need to be revisited, and in many cases alternate implementations optimized for security will be required.
    Let the games begin.
      My ComputersSystem Spec

  8.    04 Jan 2018 #47

    I wonder how long the intelligence agencies have known about these flaws and have been exploiting them - I guess we will never know. I never store passwords on my PC and keep the OS fully up to date so my password security is as good as it can be.. How secure really and the banks and other firms holding sensitive data given these flaws / bugs keep surfacing?
      My ComputersSystem Spec

  •    04 Jan 2018 #48

    Bree said: View Post
    I wonder when Intel first knew of this bug?

    https://www.fool.com/investing/2017/...-of-stock.aspx
    Since June
    (https://meltdownattack.com/meltdown.pdf)
      My ComputerSystem Spec


  • Posts : 1,524
    WinX Pro x64 IP current
       04 Jan 2018 #49

    eddward said: View Post
    No, it was disclosed to Intel then. The associated CVE was reserved in February, and the Meltdown PDF shows that researchers were already working on the bug to verify it back in 2016.
      My ComputersSystem Spec


  •  
    Page 5 of 14 FirstFirst ... 34567 ... LastLast

    Related Threads
    Looks like us Intel users are getting a free downgrade soon :( A Huge Intel Security Hole Could Slow Down Your PC Soon I’m pretty ticked about this one.
    Read more: Intel Unveils Full Intel Core-X-series Processor Family Specs; 14- to 18-Core Processors Available Starting in September
    Intel® Core™2 Duo processor T6670 in Installation and Upgrade
    I am trying to Upgrade my Protege M750 with Intel® C™2 Duo processor T6670. The Upgrade starts but after while I got message Processor not supported. Any explanention why it is happened as even older processors are supported
    Hello, I'm running a 64 bit Windows 10 laptop. On idle, the System process is showing a high memory usage of more than 150 MB, usually more than 200 MB. Using poolmon the pooltag SpDN showed up with a memory leak. It leads to the Intel Matrix...
    edge leaking memory in Browsers and Email
    Build 10240 on the pro 3, this keeps happening then fan kicks in and goes crazy, cant be right?!!!
    Our Sites
    Site Links
    About Us
    Windows 10 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 10" and related materials are trademarks of Microsoft Corp.

    © Designer Media Ltd
    All times are GMT -5. The time now is 22:30.
    Find Us