GStreamer Making Progress On Vulkan Video Support

[phoronix]

Phoronix: GStreamer Making Progress On Vulkan Video Support

Back in April was the release of Vulkan Video extensions for GPU-accelerated video encode/decode using this cross-platform API. NVIDIA was quick to publish a beta driver with Vulkan Video support while adoption beyond that by drivers or multimedia software has been rather limited so far. Fortunately, the popular GStreamer multimedia framework for Linux users is working in the direction of supporting Vulkan Video...

https://www.phoronix.com/scan.php?page=news_item&px=Vulkan-Video-GStreamer-Igalia

[uid313]

But GStreamer is written in C so it is hard to write secure could, so a specially crafted video file could be used to exploit a vulnerability. It is hard to trust any decoder written in C when data is coming from arbitrary non-trusted sources. I think Rust is needed here.

[coder]

But GStreamer is written in C so it is hard to write secure could, so a specially crafted video file could be used to exploit a vulnerability. It is hard to trust any decoder written in C when data is coming from arbitrary non-trusted sources.

In this case, the GStreamer plugin is little more than a wrapper. It's probably not doing much with the data beyond passing it to the next layer.

And writing secure C isn't necessarily hard. Like everything in C, it just takes more work. C has a bad reputation because programmers tend to get lazy and use sloppy short cuts. These days, everyone is much more aware of the need to follow best practices.

I think Rust is needed here.

There's support for that, but it's still new and I think it's still early to use it for something like this.

https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs

It's weird that you'd single out this case as needing Rust. If you're that concerned, then probably just don't use GStreamer at all, because it consists of many millions of lines of C code, and that's not set to change in the foreseeable future.

Oh, and you'd better not use libav/ffmpeg either, because that was all C, last time I checked. And that does include full parsers and decoders!

[skeevy420]

But GStreamer is written in C so it is hard to write secure could, so a specially crafted video file could be used to exploit a vulnerability. It is hard to trust any decoder written in C when data is coming from arbitrary non-trusted sources. I think Rust is needed here.

Just think, I'll soon be able to post a cat clip that copies a person's credit card information so I can buy a Fender Tony Franklin Fretless P Bass, the blue one.....I mean .bashrc so I can get some startup script ideas

[skeevy420]

In this case, the GStreamer plugin is little more than a wrapper. It's probably not doing much with the data beyond passing it to the next layer.

And writing secure C isn't necessarily hard. Like everything in C, it just takes more work. C has a bad reputation because programmers tend to get lazy and use sloppy short cuts. These days, everyone is much more aware of the need to follow best practices.

Maybe so, but it doesn't help that iPhones were vulnerable to jpegs at one point in time.

We're in the age of hackers now. This is why:

[coder]

Maybe so, but it doesn't help that iPhones were vulnerable to jpegs at one point in time.

Yeah, but also libjpeg is a couple decades older than GStreamer and was written to work on DOS machines and microcontrollers. And it's a full-fledged decoder, whereas GStreamer itself (and its plugins) don't do much in the way of decoding compressed data.

Like I said, there's been no shortage of insecure C code out there. Is Rust better? Sure. But GStreamer and its main libs and plugins are in the MLOCs range and have been around for long enough to establish a decent track record. It's not as if every piece of C code is like a hand grenade with the pin half-pulled.

[skeevy420]

Yeah, but also libjpeg is a couple decades older than GStreamer and was written to work on DOS machines and microcontrollers. And it's a full-fledged decoder, whereas GStreamer itself (and its plugins) don't do much in the way of decoding compressed data.

Like I said, there's been no shortage of insecure C code out there. Is Rust better? Sure. But GStreamer and its main libs and plugins are in the MLOCs range and have been around for long enough to establish a decent track record. It's not as if every piece of C code is like a hand grenade with the pin half-pulled.

I'm not trying to disagree with you. Technically speaking, both of y'all are right.

[uid313]

In this case, the GStreamer plugin is little more than a wrapper. It's probably not doing much with the data beyond passing it to the next layer.

Even parsing just the headers can introduce vulnerabilities.

And writing secure C isn't necessarily hard. Like everything in C, it just takes more work. C has a bad reputation because programmers tend to get lazy and use sloppy short cuts. These days, everyone is much more aware of the need to follow best practices.

Yes, it is hard. I wouldn't be able to write secure C code. Microsoft is now using Rust in the Windows kernel, and Google is pushing for Rust in the Linux kernel, because writing secure C is hard.

There's support for that, but it's still new and I think it's still early to use it for something like this.

https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs

Oh, that's cool, I hope to see these plugins progress!

It's weird that you'd single out this case as needing Rust. If you're that concerned, then probably just don't use GStreamer at all, because it consists of many millions of lines of C code, and that's not set to change in the foreseeable future.

Oh, and you'd better not use libav/ffmpeg either, because that was all C, last time I checked. And that does include full parsers and decoders!

No, I am not only concerned about GStreamer, but also PDF parsing, and libavb/ffmpeg. Yeah, I better not use libav/ffmpeg either, these really ought to be replaced by something written in Rust.

[coder]

Even parsing just the headers can introduce vulnerabilities.

Knowing a fair amount about GStreamer, I doubt it's doing even that much. GStreamer separates that task into separate elements that would already exist for many years now, and probably just wrap libav, anyway.

Yeah, I better not use libav/ffmpeg either, these really ought to be replaced by something written in Rust.

Well, fire up your text editor and get to work!

[uid313]

Well, fire up your text editor and get to work!

I am a dumb ass high-school dropout who struggled in math, I know nothing about algorithms or math. I've tried Rust but I am pretty bad at it. Python is much easier.