Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg and a thousand fixes

googleonlinesecurity.blogspot.com

Post reply on HN
Print view View original

61–70 of 150 posts

Re: FFmpeg and a thousand fixes

#61

Post by trobertson »

colanderman wrote: post #46
lmm wrote: post #27

Earlier quoted context omitted.

The only options I could think of that're mature enough are OCaml and Haskell. I'm aware of video transcoders in both, though nothing with anything like the format support of ffmpeg.

OCaml I know doesn't support SIMD acceleration. Not sure about Haskell. You need SIMD support to get anything decently fast in the field of video/audio manipulation.

Haskell's GHC is working on it [1]. It's not primetime (not even close, really), but it does work with modified libraries and compiling to llvm.

There is also Intel Lab's HRC (Haskell Research Compiler) that does have SIMD capabilities [2]. Unfortunately, there isn't a public release of HRC yet.

---

[1]: https://ghc.haskell.org/trac/ghc/wiki/SIMD

[2]: http://dorchard.wordpress.com/2013/10/14/automatic-simd-vect...

Re: FFmpeg and a thousand fixes

#62

Post by Crito »

Perseids wrote: post #59
StavrosK wrote: post #55

Earlier quoted context omitted.

The difference is that FFMpeg is very, very CPU-bound, taking four hours instead of two to encode a movie is a big hassle. On the other hand, not many people use a world-facing FFmpeg instance to submit jobs to. I don't see why security should trump speed here.

You mean, not many people use VLC? https://www.videolan.org/developers/vlc.html#thirdparty

For realtime playback locally sure. I don't think there are many/any public-facing systems backed by VLC. Presumably VLC prioritizes speed over security.

Re: FFmpeg and a thousand fixes

#63

Post by Crito »

gregcrv wrote: post #36
pjmlp wrote: post #22

The wonders of C: - NULL pointer dereferences, - Invalid pointer arithmetic leading to SIGSEGV due to unmapped memory access, - Out-of-bounds reads and writes to stack, heap and static-based arrays, - Invalid free() calls, - Double free() calls over the same pointer, - Division errors, - Assertion failures, - Use of uninitialized memory. But hey, any good programmer always writes perfect C code.

programmers are people

Programmers are people, but how many python programmers run into double-free bugs?

Language has a lot to do with what sort of issues programmers will have to tackle.

Re: FFmpeg and a thousand fixes

#64

Post by MBCook »

rip747 wrote: post #54
chadillac wrote: post #47

Earlier quoted context omitted.

I'm not proud of this legacy code, but... it exists because it was a real world issue that would cripple a conversion server in production envs when fed certain files with timing/syncing errors as part of an automated upload and conversion process. When it would crash it would consume 100% of the cores and eat up enough RAM to force swap. This cron has been keeping ffmpeg in check for over 4 years (not 6, whoopsie) i…

"I'm not proud of this legacy code," "This cron has been keeping ffmpeg in check for over 6+ years in a production environment at this point... it processes thousands of videos a day using a custom queuing and reviewing system." why do we programmers always feel we need to apologize for something that we did quickly, but has been running without incident for a number of years. take a bow my friend. that was an awesom…

> why do we programmers always feel we need to apologize for something that we did quickly, but has been running without incident for a number of years.

The script is only treating the symptom, not the problem.

It would be better to detect the files before they waste an hour of time, so you could tell the user instead of having them silently disappear. Maybe there is something you could do to fix the files. The programmer part of me says there is a real fix that needs writing.

It's obviously a great script if it's worked that long. Who knows how long it would take to track down and fix the bug(s) causing the issue. If they haven't needed to fix the bug in all these years just writing that script was obviously a good decision.

Re: FFmpeg and a thousand fixes

#65

Post by colanderman »

pjmlp wrote: post #51
colanderman wrote: post #46

Earlier quoted context omitted.

OCaml I know doesn't support SIMD acceleration. Not sure about Haskell. You need SIMD support to get anything decently fast in the field of video/audio manipulation.

That is a compiler issue, not language. ISO/ANSI C also don't support SIMD, you have to go down to Assembly when writing portable code across C compilers.

Ya, it's definitely a language issue; barring super-intelligent compilers that can vectorize things on their own (which GCC does for certain cases), you need a means to express vectorizable operations.

You don't need to work at the assembly level for this; you just need a language that can express vector operations in a way that doesn't require a compiler to solve the halting problem, and you need a compiler that knows how to compile such operations to SIMD.

Yes, ANSI C doesn't have such a construct, but GNU C (which I'd bet 95% of open-source code uses anyway) does.

Re: FFmpeg and a thousand fixes

#66

Post by haberman »

pjmlp wrote: post #22

The wonders of C: - NULL pointer dereferences, - Invalid pointer arithmetic leading to SIGSEGV due to unmapped memory access, - Out-of-bounds reads and writes to stack, heap and static-based arrays, - Invalid free() calls, - Double free() calls over the same pointer, - Division errors, - Assertion failures, - Use of uninitialized memory. But hey, any good programmer always writes perfect C code.

Yeah, and you know, the Rust guys are actually doing some great work on making a language that solves some of these problems without giving up the advantages that make C programmers choose C.

Meanwhile, you are just being snarky on a message board while using a whole stack of software that was built by the programmers whose work you are criticizing.

Re: FFmpeg and a thousand fixes

#67

Post by Crito »

Thaxll wrote: post #24
jbk wrote: post #10

Earlier quoted context omitted.

> I wonder how many of the bugs led to code execution? Quite a few. We're often affected with VLC, and code execution is easy to get to. But with VLC, you're "only" in userland.

I'm sure some people are running VLC under root, still in userland but can be very dangerous.

I'm sure there are some people using telnet and using "password" as their root password. At a certain point it becomes more than reasonable to say "Well don't do that."

Re: FFmpeg and a thousand fixes

#68

Post by vezzy-fnord »

pjmlp wrote: post #34
ID_HOME wrote: post #28

Earlier quoted context omitted.

I guess the correct solution is to use Java? Then we can bitch about run away garbage collection. How about Python then? It's really "fast". Or we can program it in snide remarks on forums, then we don't even have to write any working code to feel superior.

Modula-2, Ada just to cite two possible examples.

This is the first time I've ever seen anyone (seriously?) recommend Ada for a project like this.

Re: FFmpeg and a thousand fixes

#69

Post by vezzy-fnord »

Perseids wrote: post #48
vinkelhake wrote: post #25

Earlier quoted context omitted.

Really breaking new ground here. What should FFmpeg have been written in? I can think of a few candidates, but I think they share a number of those "wonders".

On the 30C3 there was a talk about a C Compiler (actually an llvm optimization plugin) that can eliminate nearly every memory management related vulnerability by adding memory checks. The penalty is only a 100% increase in runtime. > If you're a C programmer and somebody says like: I've that optimization that makes your program 3% faster you go: wow! Then you come and say: well, now I make it half as fast you go: w00…

There's also AT&T Labs' memory-safe dialect of C called Cyclone: http://cyclone.thelanguage.org/

It's been around since 2006, but I haven't really heard of anyone using it. I wonder why.

Re: FFmpeg and a thousand fixes

#70

Post by jbk »

fulafel wrote: post #21
jbk wrote: post #10

Earlier quoted context omitted.

> I wonder how many of the bugs led to code execution? Quite a few. We're often affected with VLC, and code execution is easy to get to. But with VLC, you're "only" in userland.

Chrome is also in userland - and it has a sandboxing system. Assuming they're sandboxing ffmpeg, these bugs are more risky for VLC users than Chrome users. Plus, Chrome is more diligent with security updates and the auto-update mechanism is fully automatic. A sandboxing system provided by either ffmpeg or VLC would be a very good idea, though it would be some work... encoded data in, decoded frames out via shared mem…

> Negligible performance impact.

Memcpying complete video frame in HD at 30 or 60 fps is not negligible performance impact. But I agree it would be a good idea.

Post reply on HN