Announcement

Collapse
No announcement yet.

Oracle Linux Security Developer To AMD: "Smatch" Your Driver

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

  • Oracle Linux Security Developer To AMD: "Smatch" Your Driver

    Phoronix: Oracle Linux Security Developer To AMD: "Smatch" Your Driver

    Dan Carpenter of Oracle who is responsible for security audits of the Linux kernel is not happy with the current state of the AMDGPU DRM code-base...

    http://www.phoronix.com/scan.php?pag...MDGPU-Warnings

  • #2
    Originally posted by tildearrow
    Dang it. Does this mean no DC for Linux 4.15? (I'm not sad at all since I consider bugs)
    why would this affect dc? those are "bugs" in already landed code

    Comment


    • #3
      Originally posted by davidbepo View Post

      why would this affect dc? those are "bugs" in already landed code
      No, there are a bunch in */display/dc/* as far as i can tell.

      Comment


      • #4
        Given the number of lines of code involved, 108 _possible_ errors is not so bad; but it'd be a pain for us out here in TV land if their code was kept out of the mainline for another cycle because of it.

        AMD could even turn this into a positive by demonstrating a monster multi Ryzen build machine doing kernel compiles and static analysis runs side by side between keystrokes or something

        Comment


        • #5
          This seems like a non-issue. Things like overflow checks are typically pretty easy to add in once you find where they need to go, you just have to find someone motivated to do it. I bet somebody could fix all these in a day if they want to.

          Comment


          • #6
            If it weren't for WebGL, I'd shrug this off with a "meh."

            But now that websites could potentially "root" your machine through the GPU driver using WebGL... Eh, not so "meh" anymore.

            Comment


            • #7
              Originally posted by smitty3268 View Post
              This seems like a non-issue. Things like overflow checks are typically pretty easy to add in once you find where they need to go, you just have to find someone motivated to do it. I bet somebody could fix all these in a day if they want to.
              Uh huh - Heartbleed was pretty much an overflow bug - didn't check the actual length of the data that was sent - that simple bug sure caused a big ruckus.

              Comment


              • #8
                Originally posted by sandy8925 View Post

                Uh huh - Heartbleed was pretty much an overflow bug - didn't check the actual length of the data that was sent - that simple bug sure caused a big ruckus.
                Right, because no one knew it was there. I'm guessing it didn't take very many LOCs to fix it once it was found.

                Comment


                • #9
                  Originally posted by smitty3268 View Post
                  This seems like a non-issue. Things like overflow checks are typically pretty easy to add in once you find where they need to go, you just have to find someone motivated to do it. I bet somebody could fix all these in a day if they want to.
                  Not trolling, would Rust protect against these types of overflow?

                  Comment


                  • #10
                    Originally posted by smitty3268 View Post
                    This seems like a non-issue. Things like overflow checks are typically pretty easy to add in once you find where they need to go, you just have to find someone motivated to do it. I bet somebody could fix all these in a day if they want to.
                    It is best to fix these trivial bugs when the code is written in the first place. It is much harder to fix a bug that occur in production code, than during development. The cost of debugging is not trivial.

                    Of course, there are more non-trivial bugs that's let through to production, but trivial bugs should always be fixed when encountered. The root of an non-trivial bug can easily be several "trivial" bugs that should have been squashed when coding.

                    https://www.isixsigma.com/industries...ncing-quality/

                    Comment

                    Working...
                    X