Announcement

Collapse
No announcement yet.

Linux Kernel Hardens Sound Drivers Against Spectre V1 Vulnerability

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

  • Linux Kernel Hardens Sound Drivers Against Spectre V1 Vulnerability

    Phoronix: Linux Kernel Hardens Sound Drivers Against Spectre V1 Vulnerability

    As part of fixes landing for the Linux kernel sound drivers, several sound drivers were hardened against Spectre Variant One...

    http://www.phoronix.com/scan.php?pag...-Sound-Drivers

  • #2
    Typo:

    it has uncovered hundreds of potential areas where the kernel's C could could

    One could is sufficient.

    Comment


    • #3
      I do not understand why sound drivers need protecting against Spectre, etc. I do not think that sound drivers use passwords and I assume that this does not protect audio recordings made with the sound hardware. Could someone please say where the risk is with sound drivers?

      Comment


      • #4
        Originally posted by Ray54 View Post
        I do not understand why sound drivers need protecting against Spectre, etc. I do not think that sound drivers use passwords and I assume that this does not protect audio recordings made with the sound hardware. Could someone please say where the risk is with sound drivers?
        AFAIK, basically in these cases the arrays are being expanded from user-space data and thus with Spectre V1 if specially crafted code could theoretically leak some kernel memory to the rogue user-space code.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #5
          Because sound drivers, like any other kernel drivers, run in the ring 0 mode which has access to whole physical memory. And because input to the kernel comes from the untrusted user (who would like to read physical memory to which it does not have access), it is needed to protect a kernel code which is vulnerable to bounds check due to bugs in x86 processors (aka Spectre v1). So imagine that you could prepare special input for these drivers (e.g. some IOCTL or any other syscall) and thanks to Spectre v1 you would use timing attacks to read from unavailable memory.

          Comment


          • #6
            Originally posted by pali View Post
            due to bugs in x86 processors (aka Spectre v1)
            Spectre affects almost every modern processor architecture with speculative execution including newer IBM POWER and ARM.

            Comment


            • #7
              Originally posted by Ray54 View Post
              I do not understand why sound drivers need protecting against Spectre, etc. I do not think that sound drivers use passwords and I assume that this does not protect audio recordings made with the sound hardware. Could someone please say where the risk is with sound drivers?
              Spectre (and Meltdown) aren't about passwords, but about exposing memory to processes that should NOT have access to it.

              One of the things done by the kernel is segregating applications in RAM, denying them access to areas of RAM that is allocated by something else (or by the kernel for itself). The ability to break this segregation is bad.

              To exploit this you would need to craft malware that interacts with these drivers, as explained by pali above.

              Comment


              • #8
                I wonder if the kernel source code is now littered with code designed to mitigate these issues. I hope that they're making decent use of conditional macro code chunks so they can easily disable this stuff in the future. I hope they're commenting their changes well too.

                Comment


                • #9
                  It looks like the Spectre / Meltdown speculative execution flaw fun isn't over yet! 8 new security vulnerabilities found in Intel processors. Xorg server security is beginning to look like an armed fortress in comparison to CPUs.

                  https://www.neowin.net/news/more-flaws-discovered-in-intel-chips---some-serious-expect-patches-soon

                  Comment


                  • #10
                    Originally posted by cybertraveler View Post
                    I wonder if the kernel source code is now littered with code designed to mitigate these issues. I hope that they're making decent use of conditional macro code chunks so they can easily disable this stuff in the future. I hope they're commenting their changes well too.
                    Your lack of faith in kernel devs is disturbing. Repent asap or face the consequences of your sin.

                    The function used here for mitigating speculative vulnerabilities (Spectre) is into ifdefs (conditional macro code) and enabled/disabled with _LINUX_NOSPEC_H config. It's also sitting in its own file called "nospec.h", and there is a text file in the docs to explain what is this about https://github.com/torvalds/linux/bl...peculation.txt

                    Most other stuff about speculative vulnerability follows the same criteria, and it usually contains "nospec" in the name. https://github.com/torvalds/linux/se...q=nospec&type=

                    Note that commenting may not be very verbose as you can look up the git history of the file with all the commits to it and the descriptions from there.

                    Comment

                    Working...
                    X