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

[chithanh]

AMD and security is a bit of a sad story of incompetence and placating users with BS.
When asked to provide open source PSP code so people can trust it after public review, AMD just said they would instead give it to 3rd party auditors (I KID YOU NOT).
And their Windows RaidXpert driver package comes with outdated and vulnerable XAMPP stack, the Apache webserver configured to run as SYSTEM user.

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.

Not trolling, would Rust protect against these types of overflow?

Rust is a language that guarantees memory safety, so it can protect against certain types of buffer overflow vulnerabilities. In the Heartbleed case however, OpenSSL allocated a buffer out of which several requests were served and did not do proper bounds checking inside that buffer. Rust would not have helped here.

[starshipeleven]

AMD and security is a bit of a sad story of incompetence and placating users with BS.

Ah come on, stop trolling. They are focusing their efforts to get this code mainlined at all in a reasonable timescale, these bugs can be fixed later.

When asked to provide open source PSP code so people can trust it after public review, AMD just said they would instead give it to 3rd party auditors (I KID YOU NOT).

The only people that were seriously expecting them to opensource it are completely out of touch with reality.

And this answer is still better than Intel's (no answer).

[garegin]

Yes it would have.
it would have migitated the issue greatly

https://tonyarcieri.com/would-rust-have-prevented-heartbleed-another-look

[Azpegath]

Great, more static analysis tools should be used, hopefully in parallel with Valgrind and the new hype of fuzzers. For instance https://twitter.com/icculus/status/919237418032816128.
I, for one, welcome our Tool overlords.

He has valid critique of the code, and now it can be fixed. I don't see any reason for this to stop the merge for 4.15.

[kaprikawn]

Not trolling, would Rust protect against these types of overflow?

Yes.

There's ~1 million lines of code in the codebase in question. So if you start converting it to Rust now you should be done in a few decades.

[chithanh]

Ah come on, stop trolling. They are focusing their efforts to get this code mainlined at all in a reasonable timescale, these bugs can be fixed later.

I'm not trolling. Releasing the driver with a remark "this has known security problems" would have been fine if they want to get the code out of the door quickly.

The only people that were seriously expecting them to opensource it are completely out of touch with reality.

I'm not criticizing AMD for keeping the PSP code proprietary. I am criticizing them for placating customers with such egregious BS.

And this answer is still better than Intel's (no answer).

If AMD had stopped at saying "we won't release open source PSP" I agree it would have been at least as good as Intel's answer. Alas, they didn't.

[Marc Driftmeyer]

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.

Please list all those sites embracing WebGL.

[Marc Driftmeyer]

AMD and security is a bit of a sad story of incompetence and placating users with BS.
When asked to provide open source PSP code so people can trust it after public review, AMD just said they would instead give it to 3rd party auditors (I KID YOU NOT).
And their Windows RaidXpert driver package comes with outdated and vulnerable XAMPP stack, the Apache webserver configured to run as SYSTEM user.

Rust is a language that guarantees memory safety, so it can protect against certain types of buffer overflow vulnerabilities. In the Heartbleed case however, OpenSSL allocated a buffer out of which several requests were served and did not do proper bounds checking inside that buffer. Rust would not have helped here.

Rust is not a panacea. Bounds checking is a development design issue, not a language catcher. The fact this isn't standard practice [bounds checking] in 2017 is a black stain on the idiots developing the software, irregardless of the language used.

[schmidtbag]

I find this a little annoying. It's not that I don't believe Carpenter or Smatch, but he sounds like a door-to-door salesman trying to get you to buy a vacuum cleaner by showing you how terrible your current one is, when the reality is you just simply haven't cleaned in a while. AMDGPU has better things to focus on beyond his [mostly] petty findings. I'm not saying these warnings or errors shouldn't be addressed, but his approach sounds more like bragging and self-promotion.

I skimmed through some of the warnings and errors produced by Smatch, and frankly, a lot of it is pedantic. Like really, inconsistent indenting? Possible memory leak? Assumed 'hubp' could be null? If you look at things that are provably problems, this list would probably be cut in half, if not shorter.

Again: I'm not saying AMD should ignore these things, but saying stuff like "I'm a bit overwhelmed" and "please use Smatch" rubs me the wrong way.

[starshipeleven]

I'm not trolling. Releasing the driver with a remark "this has known security problems" would have been fine if they want to get the code out of the door quickly.

Yeah, kick the whole goddamn USB subsystem out too, while you're at it. https://www.phoronix.com/scan.php?pa...ulnerabilities

And don't force me to start digging the list of privilege escalation bugs the kernel still has because none can figure out how to fix some shit (I recall the latest systemd's "privilege escalation" bugs were actually a linux kernel issue, just mitigated by userspace keeping guard.

Really, you're blowing this out of proportion. Fuzzing stuff always reveals tons of crap.

I'm not criticizing AMD for keeping the PSP code proprietary. I am criticizing them for placating customers with such egregious BS.

Huh? third party audit is still better than no audit at all (Intel).