(Mis)Uses of Technology

by Karl Bode


Filed Under:
chipsets, intel, security

Companies:
intel



A Major Security Vulnerability Has Plagued 'Nearly All' Intel CPUs For Years

from the whoops-a-daisy dept

Intel is in for a very challenging few weeks. Reports began to bubble forth this week suggesting that "nearly all" intel chipsets (and some chipsets from other vendors) have been plagued by a security vulnerability over the last decade that could impact millions upon millions of users. While the full details of the vulnerability have been largely been kept under secret embargo by the security community, the scale of the flaw appears to be monumental. From what's currently known, the vulnerability currently allows programs to gain access to the layout or contents of what previously was believed to be protected kernel memory.

You know, the area where everything from passwords, login keys, and files cached from disk are presumably stored away from prying eyes. The problem appears to be unprecedented, and the entire security community is rushing to quickly push out updates for the problem:

"There is presently an embargoed security bug impacting apparently all contemporary CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads. There are hints the attack impacts common virtualization environments including Amazon EC2 and Google Compute Engine, and additional hints the exact attack may involve a new variant of Rowhammer.

So for one, this appears to have been in the wild for years, raising questions as to whether this has already been exploited by the intelligence community and others. And while the nature of the vulnerability isn't being fully disclosed, AMD hinted at the structure of a problem in an e-mail over the holiday to the Linux kernel mailing list stating that AMD products aren't affected:

"AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

At least one computer science PHD candidate at Vrije Universiteit Amsterdam claims to have already developed a proof of concept capable of exploiting the flaw to read kernel memory from user mode:

And while the vulnerability can be patched on the OS level (patches for the Linux kernel are already available even though the notes try to tap dance around the true nature of the issue), early reports indicate these updates could come with a much as a 30% performance penalty, something that will make gamers and other enthusiasts likely weep:

"Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit. Your mileage may vary."

In other words, Intel's not only about to take a severe beating for a massive security vulnerability, but the performance of much of its product lineup is about to be dramatically impacted by the fix, which could flood the market with people looking for new, unimpacted CPUs. That's likely great news for AMD sales, but notably less so for Intel PR reps coming off of their holiday break, who'll be tasked with softening the perceived impact of the flaw ahead of more details in a week or two.


Reader Comments

Subscribe: RSS

View by: Time | Thread


  • icon
    Ninja (profile), 3 Jan 2018 @ 12:00pm

    I've been reading about the issue and maybe games won't be as impacted as some other workloads because they don't rely heavily on syscalls. Ars has a good article about the probable culprit.

    As CPUs get more and more complex we are introducing more attack surface like that case where Intel stuff was running an entire OS with full access to the system core functions. I expected unintended consequences like this to be a lot more common in the future. I'd love to say criminals around the world are thrilled but I don't think they are as thrilled as our authoritarian govts...

    reply to this | link to this | view in chronology ]

    • identicon
      Anonymous Coward, 3 Jan 2018 @ 1:10pm

      Re:

      I run something which uses sockets out of a VeraCrypt file on my end.

      So I either have to patch which makes this situation completely unworkable because of the sheer amount of I/O system calls...

      ...or remain vulnerable.

      So fair, vulnerability is winning.

      reply to this | link to this | view in chronology ]

    • identicon
      Anonymous Coward, 3 Jan 2018 @ 1:11pm

      Re:

      Also, don't forget about Denuvo.

      reply to this | link to this | view in chronology ]

  • identicon
    Anonymous Coward, 3 Jan 2018 @ 12:01pm

    From the same people who brought you the Minix backdoor

    Obviously, Intel was too busy installing hardware back doors to bother with protecting the poor users.

    reply to this | link to this | view in chronology ]

  • identicon
    Anonymous Coward, 3 Jan 2018 @ 12:02pm

    The security community has know about this since may

    Bits of the minix issue have been known since May but it was mostly limited to data center users.

    reply to this | link to this | view in chronology ]

  • icon
    Uriel-238 (profile), 3 Jan 2018 @ 12:27pm

    And I got AMD because they were cheaper for the speed.

    Today I'm glad I was a cheapskate.

    reply to this | link to this | view in chronology ]

    • identicon
      Thad, 3 Jan 2018 @ 1:00pm

      Re: And I got AMD because they were cheaper for the speed.

      It's not clear yet whether AMD processors have the same flaw. It may even exist on ARM chips.

      As Ninja noted, Ars has a good rundown of what we know so far.

      reply to this | link to this | view in chronology ]

      • identicon
        Anonymous Coward, 3 Jan 2018 @ 3:13pm

        Re: Re: And I got AMD because they were cheaper for the speed.

        It's not clear yet whether AMD processors have the same flaw.

        That's true until we know the details, but they denied this class of bugs with some specificity. Compare that with Intel's non-statement.

        reply to this | link to this | view in chronology ]

        • identicon
          Pixelation, 3 Jan 2018 @ 9:48pm

          Re: Re: Re: And I got AMD because they were cheaper for the speed.

          "That's true until we know the details, but they denied this class of bugs with some specificity. Compare that with Intel's non-statement."

          Exactly, because Nothing Said is Alarming...

          reply to this | link to this | view in chronology ]

      • identicon
        Anonymous Coward, 3 Jan 2018 @ 6:05pm

        Re: Re: And I got AMD because they were cheaper for the speed.

        A newer article from Ars that has technical details:
        https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-processor-has-unfi xable-security-flaws/

        Doesn't really list what's affected though... seems like the answer to that is 'everything' - Intel, AMD and ARM.

        Ars reports the patches for some usage scenarios may result in a 40-60% slowdown. That's an incredibly high penalty. But I suppose the vendors will refine patches later and push down the penalty to a lower figure.

        reply to this | link to this | view in chronology ]

      • identicon
        Anonymous Coward, 4 Jan 2018 @ 6:08am

        Re: Re: And I got AMD because they were cheaper for the speed.

        AMD is not vulnerable to Meltdown. Only Intel and some select ARM chips are.

        reply to this | link to this | view in chronology ]

    • identicon
      Anonymous Coward, 3 Jan 2018 @ 2:55pm

      Re: And I got AMD because they were cheaper for the speed.

      Is this the "Intel Management Engine" issue? Where it was designed for someone on the outside to access the whole system remotely for (apparently) tech support purposes?

      I've heard that AMD CPUs also have a similar function, so don't think that switching to them will save you. Even if their implementation claims to be completely different, it just means that it hasn't been broken to our knowledge, yet.

      reply to this | link to this | view in chronology ]

      • identicon
        Anonymous Coward, 3 Jan 2018 @ 3:17pm

        Re: Re: And I got AMD because they were cheaper for the speed.

        Is this the "Intel Management Engine" issue?

        The information we've seen suggests it isn't, and that it may be an infoleak related to speculative execution. See AMD's statement, and note that some sources are saying CPUs since the Pentium Pro are affected (they seriously predate the IME).

        reply to this | link to this | view in chronology ]

        • identicon
          Anonymous Coward, 3 Jan 2018 @ 3:42pm

          Re: Re: Re: And I got AMD because they were cheaper for the speed.

          Hahahaha - remember the Pentium FDIV bug?

          reply to this | link to this | view in chronology ]

          • identicon
            Anonymous Coward, 3 Jan 2018 @ 4:07pm

            Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.

            Yeah but not in detail. Are you hinting that Intel had some bogus denial? Or that they'll need to replace CPUs now, as they did then?

            reply to this | link to this | view in chronology ]

            • identicon
              Anonymous Coward, 3 Jan 2018 @ 6:26pm

              Re: Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.

              Yeah, they said the average user would not even notice the diff ... heh, it's not the point here.

              reply to this | link to this | view in chronology ]

              • identicon
                Anonymous Coward, 4 Jan 2018 @ 4:30am

                Re: Re: Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.

                Well, that seems untrue, plus the papers say (at least some of) the attacks were tested and work on AMD CPUs. Good call with the FDIV comparison.

                reply to this | link to this | view in chronology ]

                • icon
                  Richard (profile), 4 Jan 2018 @ 8:37am

                  Re: Re: Re: Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.

                  The papers say that "proof of concept" attacks have been constructed - which is some way short of actual practical attacks.

                  I also remember the 8087 evaluation stack cock-up - which persisted for many years. In fact it is still technically present in the instruction set to this day.

                  reply to this | link to this | view in chronology ]

        • identicon
          Anonymous Coward, 3 Jan 2018 @ 4:37pm

          Re: Re: Re: And I got AMD because they were cheaper for the speed.

          it may be an infoleak related to speculative execution

          ...and to speculate wildly myself, the CPU must be somehow speculating on secret data. Maybe the result then feeds into the cache or the branch predictor in some user-observable way. Here's a similar thing from last year, involving TSX.

          I might start by writing some code that jumps to a kernel address. Run it and handle the fault, or just make the CPU predict the jump will be taken. Then probe the cache or predictor state to get some data. Maybe using the address of a register-dependent jump instruction will make the CPU prefetch based on the (userspace-controlled) register value.

          reply to this | link to this | view in chronology ]

          • identicon
            Mikael, 5 Jan 2018 @ 4:06pm

            Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.

            There is a paper on the method. Modern CPU's can execute multiple instructions simultaneously. Speculative execution attempts to predict the future state of the CPU by assuming instructions will complete successfully. Because of this parallel nature, when a program attempts to read a value in kernel memory this triggers a whole cascade of events; Because loading data into cache is slow, this request is done first, Then a later check in the pipeline determines whether the memory read was an illegal address and rolls back the state of the CPU, but not the cache. Then the program can issue a flush-and-reload instruction to determine the state of the cache, and get the data that way. The data can be anything from passwords to usernames and account numbers.

            reply to this | link to this | view in chronology ]

        • identicon
          Anonymous Coward, 4 Jan 2018 @ 6:31am

          Re: Re: Re: And I got AMD because they were cheaper for the speed.

          Shite. Good to know, all the same.

          reply to this | link to this | view in chronology ]

      • identicon
        Anonymous Coward, 4 Jan 2018 @ 8:48am

        Re: Re: And I got AMD because they were cheaper for the speed.

        >Is this the "Intel Management Engine" issue? Where it was designed for someone on the outside to access the whole system remotely for (apparently) tech support purposes?

        No. Also, the word you're looking for is "ostensibly" rather than "apparently."

        reply to this | link to this | view in chronology ]

  • identicon
    Anonymous Coward, 3 Jan 2018 @ 12:29pm

    MacOS

    There are indications that Apple started patching this issue in High Sierra 10.13.2.

    reply to this | link to this | view in chronology ]

  • identicon
    Chuck, 3 Jan 2018 @ 12:30pm

    Yet another reason...

    I've noted for years that AMD offers motherboards with a full-speed FSB (that's a front-side bus, not the ruski's) while Intel continues to refuse to, and to refuse to allow their third-party board makers to either. This is a nasty trick they've been using since the late 90's.

    In short, they make a new CPU that actually is marginally faster than the last one AMD released. Then, they do a limited run of boards with full-speed FSBs and put them in the review units they send to various hardware reviewers. Then the rest of us, even the people who pay upwards of $600 for a motherboard, are stuck with lower-speed FSBs.

    The end result is that, even though Intel's CPUs are almost always the best, their actual systems are not overall faster than AMD's. They appear to be in most testing, but in practice they aren't.

    Then when enthusiasts who actually care about that last 5% of performance actually benchmark their systems, they're slower than they expected. So the cycle begins anew. The whole thing is a marketing gimmick that isn't even actually illegal because the speed of the FSBs is disclosed to the reviewers. It isn't pointed out that ONLY reviewers will EVER see this FSB speed, but then the law doesn't require that.

    Just yet another reason I prefer AMD systems. Their CPUs may be SLIGHTLY slower, but overall their systems are faster, because they're more interested in selling you a decent computer than in shoveling you into the most vicious upgrade cycle they can think of.

    reply to this | link to this | view in chronology ]

    • icon
      An Onymous Coward (profile), 3 Jan 2018 @ 12:41pm

      Re: Yet another reason...

      > In short, they make a new CPU that actually is marginally faster than the last one AMD released. Then, they do a limited run of boards with full-speed FSBs and put them in the review units they send to various hardware reviewers. Then the rest of us, even the people who pay upwards of $600 for a motherboard, are stuck with lower-speed FSBs.

      If there weren't end-user-driven stats sites out there to get the real performance data (ignore all those reviews sites) this might be a real concern. However, Intel is still the better buy, as long as you go with coffee lake. For now.

      Sooner or later I expect AMD will take the lead again but it has been a really long time since the last inversion.

      reply to this | link to this | view in chronology ]

    • identicon
      Anonymous Coward, 3 Jan 2018 @ 12:45pm

      Re: Yet another reason...

      Intel also disable ECC memory on most non-Xeon CPUs. (Some non-Xeons are rumoured to support it, but it's hard to find official details.) ECC may help prevent certain memory-corruption attacks like Rowhammer, which may or may not be related to this flaw.

      AMD's Ryzen processors all have ECC capability—though, sadly, details on mainboard/firmware support are hard to find.

      reply to this | link to this | view in chronology ]

    • identicon
      Anonymous Coward, 3 Jan 2018 @ 12:48pm

      Re: Yet another reason...

      "Intel's CPUs are almost always the best,"

      Based upon what criteria?
      Best at what?
      Seems to be a rather broad statement.

      reply to this | link to this | view in chronology ]

      • identicon
        Anonymous Coward, 3 Jan 2018 @ 12:56pm

        Re: Re: Yet another reason...

        They have the best fabrication technology, i.e., they're able to make chips smaller than any other commercial-scale fab. This helps with speed and power usage, generally.

        Until AMD released Ryzen, Intel got higher scores on most CPU performance benchmarks (but cost more, so "better" is subjective). It's been like that through most of their history, except in the Pentium 4 days when AMD got higher scores. And now with Ryzen, which is competitive too.

        reply to this | link to this | view in chronology ]

        • icon
          Richard (profile), 4 Jan 2018 @ 8:43am

          Re: Re: Re: Yet another reason...

          They have the best fabrication technology,

          But they are crap at designing processors and have a long litany of historical design cock-ups to show for it.

          In an ideal world AMD or ARM would design the chips nad Intel would make them

          reply to this | link to this | view in chronology ]

  • identicon
    Anonymous Coward, 3 Jan 2018 @ 12:49pm

    LWN link

    One of the linked articles links to a paywalled lwn.net article. Here's a non-paywalled link.

    reply to this | link to this | view in chronology ]

  • identicon
    Anonymous Coward, 3 Jan 2018 @ 12:51pm

    definition please.

    What exactly does an embargo on the security flaw mean? That they won't share with anyone besides the effected party?

    reply to this | link to this | view in chronology ]

    • identicon
      Anonymous Coward, 3 Jan 2018 @ 12:55pm

      Re: definition please.

      I know the definition of embargo itself but how is it applied in this context? Also who orders the embargo when potentially multiple countries are involved?

      reply to this | link to this | view in chronology ]

      • identicon
        Anonymous Coward, 3 Jan 2018 @ 1:02pm

        Re: Re: definition please.

        "Embargo" means the people involved have agreed not to release details right now... presumably until a certain date, or until a patch is available. Obviously, the people writing these patches must have more information than the rest of us.

        This would have been negotiated between the researchers and the affected companies/groups. In general nothing stops researches from publishing immediately. It seems they, Intel, AMD, Microsoft, and some Linux developers have the details, at least, and have agreed not to share them.

        ("Embargo" in this context is similar to the journalistic concept of an "embargoed" story.)

        reply to this | link to this | view in chronology ]

        • identicon
          Anonymous Coward, 3 Jan 2018 @ 5:20pm

          Re: Re: Re: definition please.

          This would have been negotiated between the researchers and the affected companies/groups.

          Intel's bug bounty program offers $30000 for a critical hardware bug, but participants "Must follow coordinated disclosure" to get paid.

          reply to this | link to this | view in chronology ]

  • identicon
    Anonymous Coward, 3 Jan 2018 @ 12:59pm

    dont worry about the slow down after any update patch has been applied, Intel will soon sell you a nice, new, faster chip at 3x the cost of the 'faulty' one!

    reply to this | link to this | view in chronology ]

    • identicon
      Anonymous Coward, 3 Jan 2018 @ 1:12pm

      Re:

      Sounds like Apple's business strategy.

      reply to this | link to this | view in chronology ]

    • icon
      An Onymous Coward (profile), 3 Jan 2018 @ 1:16pm

      Re:

      Anything still under warranty should be repaired or replaced. But outside the warranty is no different than anything else you might buy.

      If the engine in your 2012 Mazda dies you might be upset at Mazda for poor quality or upset at the universe for your bad luck but you have no recourse. Your options now are to buy another Mazda or some other brand. Or, I suppose, stop driving. This is no different.

      reply to this | link to this | view in chronology ]

      • identicon
        Anonymous Coward, 3 Jan 2018 @ 3:45pm

        Re: Re:

        But one would have discovered rather soon that their Mazda could not reach highway speeds and take it back to the dealer immediately.

        Oh yeah - car analogies are bad, all of them - this is no different.

        reply to this | link to this | view in chronology ]

        • identicon
          carlb, 4 Jan 2018 @ 6:42am

          car analogies?

          Actually, there is one very obvious motorcar analogy.

          Buy a VW Diesel on the presumption that it is efficient, powerful and clean... then get told later to "choose any two" after the vehicle fails a third-party emission road test and the proposed fixes cost efficiency, power or both.

          The product is still running; that doesn't mean something doesn't stink here.

          reply to this | link to this | view in chronology ]

      • icon
        orbitalinsertion (profile), 3 Jan 2018 @ 9:56pm

        Re: Re:

        Or your 2018 Mazda. Totes no difference.

        reply to this | link to this | view in chronology ]

  • identicon
    Anonymous Coward, 3 Jan 2018 @ 1:40pm

    Gosh, I wonder if Intel's CEO flushed a whole bunch of stock options recently...

    reply to this | link to this | view in chronology ]

  • identicon
    Anonymous Coward, 3 Jan 2018 @ 2:08pm

    And again. Backdoors make it into the wild every time. Everybody wave their hands in the air in pretend panic as the backdoor is closed, and a new backdoor is tunneled in to replace it.

    reply to this | link to this | view in chronology ]

    • identicon
      Anonymous Coward, 3 Jan 2018 @ 2:26pm

      Re:

      Uh, this wasn't a backdoor. It's just an undiscovered (until now) bug.

      It isn't even a write attack, it's read only. Meaning someone exploiting this could only get information from the PC, not make it do anything. Though one could make the argument that what is revealed in this exploit could be used to chain an additional attack that would lead to privilege escalation and an eventual write attack but this by itself, doesn't do that.

      reply to this | link to this | view in chronology ]

      • identicon
        Anonymous Coward, 3 Jan 2018 @ 3:09pm

        Re: Re:

        Uh, this wasn't a backdoor. It's just an undiscovered (until now) bug.

        What were you expecting, MSR_NSAKEY? If one wanted to design a backdoor, this would be pretty much perfect. (Or if an agency wanted to defend their country, it's exactly what they should be looking for: areas where a designer might fuck up. CPU design—including caching, speculative execution, and protection, and the interactions between them—is hard.)

        It isn't even a write attack, it's read only. Meaning someone exploiting this could only get information from the PC, not make it do anything.

        You may not have thought this through. If one can get information like passwords or encryption keys, one can use them to "do things" that shouldn't be allowed. This is why Heartbleed was considered so critical.

        reply to this | link to this | view in chronology ]

        • identicon
          Anonymous Coward, 3 Jan 2018 @ 3:47pm

          Re: Re: Re:

          "if an agency wanted to defend their country"

          They would look for these things in order to eradicate, not use.

          reply to this | link to this | view in chronology ]

          • identicon
            Anonymous Coward, 3 Jan 2018 @ 5:15pm

            Re: Re: Re: Re:

            Yes, of course! They have the expertise to find this, and they'd screw themselves by hoarding it; other agencies are depending on CPUs to be secure. Though really, CPU manufacturers should be releasing enough information so we don't have to rely on powerful agencies.

            reply to this | link to this | view in chronology ]

        • identicon
          Anonymous Coward, 3 Jan 2018 @ 9:57pm

          Re: Re: Re:

          Read my post a little more thoroughly please.

          I acknowledged that this could be used in combo with another attack to actually take control of or modify the computer in some way, but BY ITSELF can't do any of that.

          My point was more to address the OP's seeming assumption that this was a deliberate backdooring of hardware and that even if it is fixed, they will deliberately insert a new one. This is not that, it's a flaw, plain and simple.

          reply to this | link to this | view in chronology ]

          • identicon
            Anonymous Coward, 4 Jan 2018 @ 4:29am

            Re: Re: Re: Re:

            I acknowledged that this could be used in combo with another attack to actually take control of or modify the computer in some way, but BY ITSELF can't do any of that.

            Once you dump the password or key from memory, using it isn't much of an "attack". If attackers can't run code on the system, dumping kernel/hypervisor memory does require some preceding attack; but lots of systems do let people run code, and this is a serious vulnerability. Chaining isn't generally that hard anyway, and this can break a lot of attack mitigations.

            To say this is only an information leak is true but makes it sound much less serious than it is.

            My point was more to address the OP's seeming assumption that this was a deliberate backdooring of hardware and that even if it is fixed, they will deliberately insert a new one. This is not that, it's a flaw, plain and simple.

            Unless you were on the Intel engineering team that screwed up, you can't know that for sure. I suspect you're right, but (in hindsight) this would be an ideal backdoor because it can be written off as a complexity-induced bug. It sat around for decades before being noticed. And Intel's next CPU will be even more complex, meaning the next bug/backdoor can hide the same way.

            Any "sufficiently advanced bug", like this or the SetAbortProc WMF bug, is indistinguishable from a backdoor.

            reply to this | link to this | view in chronology ]

        • icon
          Richard (profile), 4 Jan 2018 @ 8:49am

          Re: Re: Re:

          . If one can get information like passwords or encryption keys, one can use them to "do things" that shouldn't be allowed.

          It doesn't seem that that kind of information would be accessible to these exploits without some other route in. It is only possible to determine the layout of the data in the kernel memory - not its contents.

          reply to this | link to this | view in chronology ]

      • identicon
        Anonymous Coward, 3 Jan 2018 @ 3:13pm

        Re: Re:

        Let's see now. At the very least, being able to just detect where some critical kernel pages are located neutralizes Kernel Address Space Layout Randomization, aka last ditch effort to keep buffer overflow attacks from working. Then, you have the row hammer exploit to elevate permissions. And guess what? In order for row hammer to work, you need to know where the addresses of critical kernel structures are. And the above 2 attacks don't even require you to actually know what is in those locations, merely need to know that it's in that location. And if the exploit actually allows you the ability to read kernel memory? At that point, you might as well give your computer to your enemy.

        reply to this | link to this | view in chronology ]

        • identicon
          Anonymous Coward, 3 Jan 2018 @ 10:00pm

          Re: Re: Re:

          Yeah, I acknowledged it could be used IN COMBINATION with another attack to actually create a backdoor into the system, but BY ITSELF this is not that.

          Though one could make the argument that what is revealed in this exploit could be used to chain an additional attack that would lead to privilege escalation and an eventual write attack but this by itself, doesn't do that.

          reply to this | link to this | view in chronology ]

      • identicon
        David Hess, 3 Jan 2018 @ 4:53pm

        Re: Re:

        This exploit allows reading of protected memory and could for instance be combined with a rowhammer attack to effect privilege escalation.

        reply to this | link to this | view in chronology ]

        • identicon
          Anonymous Coward, 3 Jan 2018 @ 10:02pm

          Re: Re: Re:

          Yep, it could be used in combination with another attack to get privilege escalation but as I stated in my original comment, by itself this only gives you info, not any kind of meaningful control or access.

          reply to this | link to this | view in chronology ]

        • icon
          Richard (profile), 4 Jan 2018 @ 8:53am

          Re: Re: Re:

          This exploit allows reading of protected memory

          No it doesn't - it allows the determination of which parts of protected memory are in use.

          reply to this | link to this | view in chronology ]

  • identicon
    Nice Thomas, 3 Jan 2018 @ 3:08pm

    Remember that time,

    when Intel DIDN'T have a maths co-processor problem on their 585.999938 CPU?

    reply to this | link to this | view in chronology ]

  • identicon
    Lawrence D’Oliveiro, 3 Jan 2018 @ 4:40pm

    Update

    Seems there are two different flaws, one of which affects a range of non-Intel CPUs.

    (h/t Michael Cree)

    reply to this | link to this | view in chronology ]

  • identicon
    Anonymous Coward, 3 Jan 2018 @ 5:16pm

    No wonder the tekkies are all leaving NSA...

    Most of their favorite exploits have been found, so it's no longer any fun...

    reply to this | link to this | view in chronology ]

  • identicon
    Anonymous Coward, 3 Jan 2018 @ 5:59pm

    If it's patched in the Linux kernel, then the bug is basically in the open already. People will reverse engineer the fix to find out what the cause is. They've done the same for security updates from vendors for years. So why still embargo it? Reveal the details of what's affected and the patches available, even if you don't release POC code. Hackers are going to work out an exploit anyway.

    reply to this | link to this | view in chronology ]

  • icon
    David (profile), 3 Jan 2018 @ 6:43pm

    Normal laptop and desktop users will notice little delta

    This is an optimization (cough,cough) that allowed a system to run faster. The fix is relatively simple; Separate kernel address from user address. That comes at a cost, but many user space applications will notice little to nothing at all.

    I shared the description with another software retiree and he laughed. Yes, this is something that any security person would jump on. Of course, software issues much less opinions of software or security people are commonly ignored.

    Because chip designers are godlike. Just ask them.

    reply to this | link to this | view in chronology ]

  • identicon
    9mm, 4 Jan 2018 @ 12:22pm

    And the white papers are out

    full details on the vulnerability are now out.

    https://meltdownattack.com

    reply to this | link to this | view in chronology ]

  • icon
    Seegras (profile), 5 Jan 2018 @ 7:05am

    Meltdown mitigated in Linux Kernel 4.14.11

    Which just has been released. Some distros did patch older kernels themselves.
    Actually, 4.14.12 is out as well, https://www.kernel.org/

    reply to this | link to this | view in chronology ]

  • identicon
    swaroop, 29 Jan 2018 @ 6:38am

    i5-7200U CPU @ 2.50GHz - Do i have to worry ..?

    My laptop has the following processor

    “model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz”

    do i have to worry about the above mentioned vulnerability issue ..?

    reply to this | link to this | view in chronology ]


Add Your Comment

Have a Techdirt Account? Sign in now. Want one? Register here
Get Techdirt’s Daily Email
Use markdown for basic formatting. HTML is no longer supported.
  Save me a cookie
Follow Techdirt
Special Affiliate Offer

Advertisement
Report this ad  |  Hide Techdirt ads
Essential Reading
Techdirt Deals
Report this ad  |  Hide Techdirt ads
Techdirt Insider Chat
Advertisement
Report this ad  |  Hide Techdirt ads
Recent Stories
Advertisement
Report this ad  |  Hide Techdirt ads

Close

Email This

This feature is only available to registered users. Register or sign in to use it.