hungryninja101 at ...9...
Tue Mar 13 12:14:30 CET 2018
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...>
> 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
> > ...
> 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
> 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users