Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 28 Apr 2013 13:46:21 -0400
From: Rich Felker <>
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 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.


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.