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

[phoronix]

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?page=news_item&px=Smatch-AMDGPU-Warnings

[davidbepo]

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

[Masush5]

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.

[Happy Heyoka]

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

[smitty3268]

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.

[RealNC]

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.

[Guest]

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.

[smitty3268]

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.

[cl333r]

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?

[hjahre]

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/software-it/defect-prevention-reducing-costs-and-enhancing-quality/