[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Sep 2014 03:39:04 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: libhybris and musl?
On Thu, Sep 04, 2014 at 09:25:20AM +0200, u-igbb@...ey.se wrote:
> On Wed, Sep 03, 2014 at 06:59:17PM -0400, Rich Felker wrote:
> > way too much bad code to be safe to load into your program's address
> > space. Any process that's loaded them should be treated as potentially
> > crashing or aborting at any time, and possibly also has serious
> > namespace pollution from random libs getting pulled in.
> >
> > The way I'd like to see this solved for our "new platform vision" is
> > to move the actual GL implementation out of the address space of the
> > application using it, and instead provide a universal libGL for
> > applications to link (even statically, if desired) that marshals all
> > GL operations over shared-memory-based IPC to a separate process which
> > has loaded the actual driver for the target hardware you want to
> > render to.
>
> IMHO this is how the shared libs concept should have been implemented
> from the very beginning.
Not shared libs in general, but for "arbitrary pluggable modules to
inject into arbitrary programs to extend their functionality", yes.
Another clear example where this is needed is PAM. The idea of loading
random third-party code of dubious quality into every process that's
performing authentication/logins is an utterly irrational risk from a
security standpoint, but could be fixed by having the PAM core
communicate with modules over some form of IPC where the modules run
with strong isolation.
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.
