No announcement yet.

Google Makes Disclosure About The CPU Vulnerability Affecting Intel / AMD / ARM

  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    I wonder if the BSD's are effected by this, I have seen Linux, Windows and OSX mentioned but nothing about BSD or Solaris or any other OS.

    And yes, I know OSX is based on BSD.


    • #22
      All this sounds to me that Intel invented Spectre of trolling, to diminish their Meltdown. Spectre as a trolling tool to save their asses as much as possible

      Let them be, at least it is not boring as from political side world is not black or white, nor perfect - "_ALL_" things could be like this like that
      Last edited by dungeon; 01-03-2018, 08:43 PM.


      • #23
        Originally posted by metalliax View Post
        Michael your posts are starting to seem suspicious. Google did not say AMD is affected by the same problem that the KPTI patch addresses. Your latest headlines over the past 8 hours are starting to read like a large entity is providing extra donations.

        I'm not accusing... this just doesn't pass the sniff test.
        It's because he jumped on it early before he had the full information. 80% of the info was speculation and rumors then. This attack publication came up to deal with the rumors, though release had been planned a week e̶a̶r̶l̶y̶ later. Don't be so paranoid.


        • #24
          Hmm... is the PTI change actually going to protect the Linux Kernel against Spector?

          Basically any syscall with the standard security check...

          if (x < array1_size)
          y = array2[array1[x] * 256];

          ...can leak state arbitrary memory space if array1[x] is read out-of-bounds speculatively into cache...

          The only fix seems to be to disable speculative cache fetches for untrusted data verification (TBH - I didn't think cache was fetched for that anyway ).


          • #25
            After actually reading both scientific papers completely, it seems pretty clear to me that:

            * "Meltdown" clearly affects only Intel CPUs, and allows writing trivial (as in "2-hours coding excercise") exploits where user space code can read arbitrary kernel space data. Expect exploits coming in quickly from every script kid and part time criminal on the Internet. There is good reason why Amazon and MicroSoft haste to force-patch-and-reboot all their "cloud" systems.

            * The performance-lowering KPTI work-around addresses "Meltdown", only

            * Performance penalty of KPTI largely depends on the number of context switches per second, the more, the worse.

            * "Spectre" theoretically affects any CPU that implements speculative execution, but exploits are hard to write, artificial examples have been demonstrated as carefully crafted binaries and JavaScript code, they require that the attacker has some interface to the vicitim that allows him to make the victim execute selected instruction sequences with input parameters controlled by the attacker (that is a given for JavaScript code in browsers and guest code in VMs.)

            * There is no other practical defense against "Spectre" than either not performing speculative execution at all, and since that is not practical with contemporary CPUs, you rather need to avoid running untrusted code on the same CPU core than trusted code posessing sensitive data - theoretically possible on multi-core CPUs, but would require massive OS and application support.

            Criminals will certainly attempt to exploit Spectre, and the most obvious attack vector is "stealing your browser's secret data via some advertisement-included JavaScript code".

            I'm looking forward to see what mitigation methods will be proposed for "Spectre", but given the large number of side-channels abusable, they will likely not be perfect.
            Last edited by dwagner; 01-03-2018, 09:01 PM.


            • #26
              As long as enterprise firms don’t care about doing firmware updates, which include security patches, caring so much about software patches is silly. Sysadmins go nuts when Windows releases a patch, but don’t give a rat’s ass when their edge devices, printers and NASes have security holes.
              Very few companies are even aware about the Intel ME hole, which all of their computers have.


              • #27
                dwagner basically lays it out correctly, imho.

                Meltdown is spec exec after a fault / trap / excp, an Intel special here. This is a special kind of stupid. No cpu should be behaving like that. Luckily, KPTI is an effective software work-around, since the exploit is trivial.

                Spectre is theoretical abuse of spec exec after a branch misprediction, which by definition, all high perf cpus do. This is going to take some wrangling to mitigate at the hardware level. I don't think there is any reasonable software solution. Luckily it seems that exploiting it is very hard, at least at the moment.
                Last edited by xorbe; 01-03-2018, 09:12 PM.


                • #28
                  I guess that as a short-term countermeasure to "Spectre", binding untrusted code to execution on a dedicated CPU core that has its caches carefully flushed before and after running the untrusted code (and syscalls from this code executed on a different core, with enough execution-time padding added in some wait-loop to render timing-based side channels impractical) could be a feasible approach.

                  On another topic: I think the Google Blog entry is woefully devoid of actual information, and the Intel statement is deliberately trying to blur the lines between the "Meltdown" and "Spectre" threats to deflect the well-deserved shaming for "Meltdown", which is totally an Intel thing.

                  Also, to understand why we see horrible bugs like "Meltdown" today, one should read: - here an excerpt:
                  As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.


                  Let me set the scene: It’s late in 2013. Intel is frantic about losing the mobile CPU wars to ARM. Meetings with all the validation groups. Head honcho in charge of Validation says something to the effect of: “We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times… we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our competition is moving much faster than we are” - I’m paraphrasing. Many of the engineers in the room could remember the FDIV bug and the ensuing problems caused for Intel 20 years prior. Many of us were aghast that someone highly placed would suggest we needed to cut corners in validation - that wasn’t explicitly said, of course, but that was the implicit message. That meeting there in late 2013 signaled a sea change at Intel to many of us who were there. And it didn’t seem like it was going to be a good kind of sea change. Some of us chose to get out while the getting was good. As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.


                  • #29
                    Originally posted by dwagner View Post
                    Also, to understand why we see horrible bugs like "Meltdown" today, one should read: - here an excerpt:
                    That might be a factor, but it's clearly not that simple, though, since Meltdown has been reproduced on Intel hardware dating to 2011, and is apparently theoretically applicable to almost all Intel processors in the past twenty years. This bug isn't a product of any *recent* corner-cutting...


                    • #30
                      Originally posted by Spooktra View Post

                      I love how the AMD apologists are starting to come out of the woodwork all over the 'net.

                      I'm not accusing...just saying it seems like some 3 letter entity that has trouble posting a profit for more than a quarter at a time may have some extra staff out there spreading FUD.
                      You're right. All some of these posts are showing that Michael is willing to lose credibilitiy as a journalist by posting misinformation without reading the articles he is referencing beforehand. I do appreciate 90% of what gets postd here and generally have a lot of respect for the site. I have been a paying member for 4 years now. The posts that have called out AMD as being potentially affected by Meltdown have been used as sources all over in other forums / social media posts.