From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3231 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Sun, 28 Apr 2013 13:46:21 -0400 Message-ID: <20130428174621.GU20323@brightrain.aerifal.cx> References: <20130425041553.GA13951@brightrain.aerifal.cx> <20130425211914.2d98535d.idunham@lavabit.com> <517A79C0.50502@gmail.com> <20130426155305.GR20323@brightrain.aerifal.cx> <517CC778.3030402@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367171199 804 80.91.229.3 (28 Apr 2013 17:46:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Apr 2013 17:46:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3235-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 28 19:46:43 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UWVgL-0005qt-8Y for gllmg-musl@plane.gmane.org; Sun, 28 Apr 2013 19:46:37 +0200 Original-Received: (qmail 16288 invoked by uid 550); 28 Apr 2013 17:46:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16280 invoked from network); 28 Apr 2013 17:46:35 -0000 Content-Disposition: inline In-Reply-To: <517CC778.3030402@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3231 Archived-At: 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