Conversation

Notices

1. Embed this notice
   LisPi (lispi314@udongein.xyz)'s status on Sunday, 26-Oct-2025 07:17:38 JST LisPi

   Does ffmpeg support some manner of shared memory decoding that would make it usable with a subprocess with no IO capabilities/permissions but that which is passed directly by its parent?

   Or at least, does it allow for incremental decoding & writing individual frames and audio samples to arbitrary buffers?

   I'm essentially wondering how one would go about making a player that can be trusted with arbitrary third-party data that is explicitly untrustworthy (clearly hardware decoding would be disabled too).

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Sunday, 26-Oct-2025 07:17:35 JST Rich Felker

     in reply to

     @lispi314 There's no good excuse for needing memory safe languages for codecs. Memory safety matters when temporal safety is a hard problem, i.e. complex and unpredictable object lifetimes. A codec should have fixed size working buffers whose lifetimes are all the same (from open to close) and no safety concern but spatial.

   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Sunday, 26-Oct-2025 07:17:36 JST LisPi

     in reply to
     The idea of using a sound fully memory-safe implementation of various codecs did occur to me, however most such libraries have very limited coverage of available codecs, which means playing back third-party content would almost inevitably involve a prior conversion phase using an isolated ffmpeg instance.
     
     That is a viable option, but not exactly convenient from a user standpoint.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Sunday, 26-Oct-2025 08:21:02 JST Rich Felker

     in reply to

     @lispi314 Container demuxing is separate from codecs, and indeed formats are sometimes designed so that the "natural" demuxer implementation has bad temporal memory safety properties, but it's basically always possible to just use a sufficiently large fixed-lifetime working space instead of any dynamic lifetimes.

     You don't need any formal verification of temporal memory safety when the code simply has no malloc/free in it and no address-of-automatic. In practice you do have the latter, but simple static analysis tools can show it's safe; you don't need general-purpose formal verification tooling for this.

   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Sunday, 26-Oct-2025 08:21:03 JST LisPi

     in reply to

     • Rich Felker
     @dalias > There's no good excuse for needing memory safe languages for codecs. Memory safety matters when temporal safety is a hard problem, i.e. complex and unpredictable object lifetimes.
     
     Unless your codec implementation is fully formally verified, there very much is. (Though such verification should ideally always be done anyway.)
     
     > A codec should have fixed size working buffers whose lifetimes are all the same (from open to close) and no safety concern but spatial.
     
     Several container formats break those assumptions.
     
     You could say they're badly-designed formats (yet they seem to have valid use-cases, unless one argues the use-case in itself is not valid), sure, but they nevertheless exist.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Sunday, 26-Oct-2025 08:27:33 JST Rich Felker

     in reply to

     @lispi314 Oh, I'm sure it does. That's ffmpeg. 🙃

     What I'm saying is that neither of "RIIR" and "rewrite it in a way that temporal memory safety isn't even a concern" seem easier than the other. The "RI" part is the hard thing either way.

   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Sunday, 26-Oct-2025 08:27:34 JST LisPi

     in reply to

     • Rich Felker

     @dalias In any case, ffmpeg still routinely has bugs of the classes I am concerned about while providing no formal proof of impossibility of further events.

     Eliminating those by design without the overhead of full verification therefore is the main practical approach possible.

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Sunday, 26-Oct-2025 08:42:16 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @lispi314 Any reason to not just ~sandbox the whole player given you're already going the no-hwdec route anyway?
     
     Specially as if you have a somewhat complex player, it'll likely also do some parsing itself which can mean a lot of logic errors or somewhat questionable dependencies.
     Also if it's really untrustworthy data I'd consider the "play it in an air-gapped/firewalled single-board-computer" route.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Sunday, 26-Oct-2025 10:26:08 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @lispi314 Yeah but getting PCM and frames to kernel & hardware require 0 parsing of the data, the modes are setup with a different interface and if the data doesn't matches you'll get funny/painful signals not exploits.
   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Sunday, 26-Oct-2025 10:26:09 JST LisPi

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan > Any reason to not just ~sandbox the whole player given you're already going the no-hwdec route anyway?
     
     Mostly at some point the image/frame buffer has to make it to the display. Same for the PCM samples for the audio.
     
     Letting the player (or at least, the part that does the parsing & decoding) directly communicate with stuff & acquire the information of where to send those things is giving it too many permissions though.
     
     > Also if it's really untrustworthy data I'd consider the "play it in an air-gapped/firewalled single-board-computer" route.
     
     That has non-viable budget & hardware requirements.
     
     Validating RGB arrays and PCM samples as harmless for the computer (intrinsic cognitohazards remain fiction so far, conventionally at most it could be unpleasantly loud, bright or colored and little else) is relatively straightforward and the full set of valid input is very permissive.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Sunday, 26-Oct-2025 17:02:33 JST Haelwenn /элвэн/ :triskell:

     in reply to

     @lispi314 Yeah, doesn't really makes sense to isolate with threads, by definition they mean a lot of shared states (both memory wise and OS APIs wise, although Linux clone(2) offers some flexibility there but you'd probably still be playing with fire).

   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Sunday, 26-Oct-2025 17:02:35 JST LisPi

     in reply to

     • Haelwenn /элвэн/ :triskell:

     @lanodan Indeed, the last leg handover program doesn't need much smarts, it's purely there to isolate between the 3rd-party data parser & the rest of the system.

     The player itself could be that program if the parsing part happens in a subprogram. I don't think threads can be isolated that way so subprogram it'd be.

     In retrospect, yes I see what you mean, trying to shove invalid bytes in something that expects a sequence of arbitrary byte triples/quads can't really do much of anything. It'll just get displayed/played wrong/right. Validation doesn't make sense in this case.