[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130428174621.GU20323@brightrain.aerifal.cx>
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.
