Date: Sun, 28 Apr 2013 13:46:21 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: High-priority library replacements? On Sun, Apr 28, 2013 at 02:53:44PM +0800, Muhammad Sumyandityo Noor wrote: > >Software-rendered GL is definitely not the solution, but I wonder if > >it would be reasonable to create a library that provides the OpenGL > >API with NO namespace pollution or introduction of dangerous code into > >the application's address space, by cooperating with a separate > >process via shared memory. On modern Linux, this separate process > >could use Linux namespaces to completely throw away all privileges > >except to the graphics device. Then the nasty legacy OpenGL code could > >run in a sandbox. > > Pardon for my limited understanding of this matter. But if you mean > replacing manufacturer-provided libEGL.so and libGLES**.so, then I > don't think it's possible, as many parts of it are hidden. And to Not replacing, wrapping. With the wrapped code being in another sandboxed process. > separate that to another process, I don't think OpenGL Context can > be shared to another process or created without referencing to > libEGL. Sure it can. This is always fundamentally possible. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.