Announcement

Collapse
No announcement yet.

Stable Updates Back To Linux 4.9 Released For Intel MMIO Stale Data Vulnerabilities

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Stable Updates Back To Linux 4.9 Released For Intel MMIO Stale Data Vulnerabilities

    Phoronix: Stable Updates Back To Linux 4.9 Released For Intel MMIO Stale Data Vulnerabilities

    Disclosed on Tuesday was the set of Intel "MMIO Stale Data" vulnerabilities. Committed immediately at embargo lift was the mitigation patches for Linux 5.19 Git while the patches have now worked their way back to the maintained stable kernel series. Out this morning is a slew of stable kernel releases back to Linux 4.9 for patching the Intel MMIO Stale Data vulnerabilities that affect many generations of Intel CPUs from Rocket Lake and older...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Am I correct in reading that Alder Lake is not affected? As the article states it's from Rocket Lake and older?

    Comment


    • #3
      Originally posted by nvaert1986 View Post
      Am I correct in reading that Alder Lake is not affected? As the article states it's from Rocket Lake and older?
      Yes, Alder Lake is not affected by the MMIO vulnerabilities.

      Comment


      • #4
        Is this a vulnerability thats practicably exploitable? Does enabling the mitigation cause a significant performance decrease?

        Comment


        • #5
          Originally posted by alvinde View Post
          Is this a vulnerability thats practicably exploitable? Does enabling the mitigation cause a significant performance decrease?
          Today's impractical vulnerability is tomorrow's targeted attack, and next week's script kiddie toy. It is unsafe to assume a vulnerability is ever insignificant and will remain that way indefinitely, or that you're not significant enough to attack.

          Comment


          • #6
            Originally posted by stormcrow View Post

            Today's impractical vulnerability is tomorrow's targeted attack, and next week's script kiddie toy. It is unsafe to assume a vulnerability is ever insignificant and will remain that way indefinitely, or that you're not significant enough to attack.
            The only 100% safe thing is throwing away your computer. Everything else is varying degrees of "unsafe". Therefore, the only question worth asking is, how much is lost and how much is gained by each specific mitigation?

            Comment


            • #7
              Originally posted by stormcrow View Post

              Today's impractical vulnerability is tomorrow's targeted attack, and next week's script kiddie toy. It is unsafe to assume a vulnerability is ever insignificant and will remain that way indefinitely, or that you're not significant enough to attack.
              Here's some anecdotal evidence that can't be generalized:

              For about a year I've been running my Intel i5-3350P (Ivy Bridge) with mitigations=off, and that CPU is as vulnerable as it can get.
              In this time period I've conducted various critical business transactions on my Swiss-cheese machine, and my bank accounts haven't been raided, yet...

              Comment


              • #8
                Originally posted by Linuxxx View Post

                Here's some anecdotal evidence that can't be generalized:

                For about a year I've been running my Intel i5-3350P (Ivy Bridge) with mitigations=off, and that CPU is as vulnerable as it can get.
                In this time period I've conducted various critical business transactions on my Swiss-cheese machine, and my bank accounts haven't been raided, yet...
                I don't think these CPU exploits are a major concern for end users, using their computer at home to be honest. As it basically requires physical presences to take advantage of it, in the case of end users and what's the point of a CPU exploit if you already have access to the machine through a RAT or physical something similar, because you could already dump databases or access other data which you normally wouldn't be able to (unless permissions are set up correctly, there are no privilege escalation exploits and the system runs in roles with SELinux for example; but it's rare to find a server, where everything is configured correctly) ?

                A CPU exploit is a much greater threat for businesses and enterprises running virtual machines or docker containers, where if they hack a virtual machine or a docker container where they have shared resources, where they could decrypt / extract information from other virtual machines running on the same host. Technically this means you're breaking out of a virtual machine to the host, but this could also be done by taking advantages of vulnerabilities found in the processor to leak data which you could theoratically extract.

                EDIT: Note: I have my migitations on (default kernel settings), because I do care for a little extra security for a minor (negligible) performance sacrifice, but I don't think this is a strict requirement for home users.

                Comment


                • #9
                  Originally posted by intelfx View Post

                  The only 100% safe thing is throwing away your computer. Everything else is varying degrees of "unsafe". Therefore, the only question worth asking is, how much is lost and how much is gained by each specific mitigation?
                  That is not the point. Of course there are some bugs in the wild that some NSA or APT posses, but as long as they are not public they will not be used against me because i am too low priority target.

                  The issue is once security vulnerability details are public exploitation is also public. And even if the detail on attack is obfuscated, it is not hard to look at patch diffrences with bugfix and reverse engineer that into vulnerability.

                  Basicly it means you have to get protection against publicly disclosed vulnerabilities.

                  Comment

                  Working...
                  X