Library Isolation

[Nobody III]

Okay, I suppose you're probably right. How do you recommend that I isolate
image rendering? My inclination is to create a custom RPC interface, but if
you have a better suggestion, I'd like to hear it.

On Tue, Mar 13, 2018 at 3:33 AM, Norman Feske <norman.feske at ...1...>
wrote:

> Hi Ben,
>
> On 11.03.2018 05:00, Nobody III wrote:
> > For method calls, one option would be to generate an RPC interface for
> > each library. This seems doable, but methods involving pointers to large
> > amounts of data may be an issue. I could wrap pointers in buffers, but
> > dynamic argument sizes and limits on RPC argument sizes could be an
> issue.
> > ...
>
> whereas I definitely see the appeal of sandboxing libraries, I think
> that the attempt to achieve it transparently is futile. There are many
> arguments against it. Just from the top of my head:
>
> * Since inter-component communication is expensive, RPC interfaces are
>   designed to decouple client and server as far as possible. This is
>   not the case for the design of library interfaces. A good library
>   interfaces does not make a good RPC interface.
>
> * When using a library, the control flow can go back-and-forth between
>   the library and the caller. Think about callback functions. This is
>   not (easily) possible with RPC.
>
> * Genode's RPC mechanism does only support POD types as arguments.
>   That means, a passed argument must not contain any pointer to another
>   object. Most libraries use opaque pointers to library-internal objects
>   as API arguments. This common pattern directly contradicts with
>   Genode's RPC mechanism.
>
> * The memory touched by a library is not disjoint from the memory used
>   by the library-using code. E.g., an inline function defined in a
>   library header becomes part of the calling program when compiled but
>   may operate on library data structures. Therefore, the line between
>   library-owned memory and caller-owned memory cannot be drawn in a
>   general way.
>
> * The magic needed to overcome these complicated problems is complex.
>   Even if succeeding, this complexity inflates the trusted computing
>   base of the library-using program.
>
> * We try to avoid the proliferation of RPC interfaces to foster the
>   composability of components. Your idea goes into the opposite
>   direction.
>
> In summary, I feel that this idea creates more problems than it solves.
> From my perspective it is more practical to manually wrap libraries into
> components - just as I did with libarchive (extract component) or GnuPG
> (verify) component.
>
> Btw, if you are interested in the isolation of libraries from an
> academic perspective, you may find it worthwhile to study tagged-memory
> CPU architecture like CHERI.
>
> Cheers
> Norman
>
> --
> Dr.-Ing. Norman Feske
> Genode Labs
>
> https://www.genode-labs.com · https://genode.org
>
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20180313/2c138e7a/attachment.html>