handling misbehaving filesystem drivers

Nobody III hungryninja101 at ...9...
Fri May 13 17:08:36 CEST 2016

Okay, that makes sense. Thanks. And I'm looking forward to when we have
more failsafe components.
On May 13, 2016 3:41 AM, "Norman Feske" <norman.feske at ...1...>

> Hello Ben,
> On 13.05.2016 06:01, Nobody III wrote:
> > I'm planning on writing an fs_filter server for the desktop environment
> > I'm developing. The server will combine access to multiple filesystems,
> > much like the vfs server. I want to implement this feature in such a way
> > that a misbehaving filesystem driver can't make the server hang. How
> > should I do this?
> this question reminds me of the following issue, where I brought up the
> same problem for NIC drivers:
>   https://github.com/genodelabs/genode/issues/1592
> In short, rather than developing your fs_filter in a defensive way, I
> would recommend to develop it assuming that the used file-system servers
> are trusted. To still use a non-trustworthy file-system server, run it
> as a child of a dedicated fs_failsafe monitor. This is a runtime
> environment with the following functionality:
> * It runs the real file system as a child component.
> * It provides a file-system service to the outside. However, it does not
>   implement the file-system itself but rather forwards all requests to
>   its child. Because the fs_failsafe component is small and trusted, it
>   will never hang. So your fs_filter would be safe to use it at all
>   times.
> * It monitors the liveliness of the child. E.g., by using a watchdog
>   thread that looks at the duration of file-system requests. If it
>   detects that the child hangs, it can try to handle this situation
>   (I don't know it restarting a file-system is a reasonable idea or
>   not). In any case, it could still respond to client requests by
>   returning errors instead of hanging. It could also respond to a
>   session-close request by killing the child.
> Do you think this approach would work for you?
> Norman
> --
> Dr.-Ing. Norman Feske
> Genode Labs
> http://www.genode-labs.com · http://genode.org
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> 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/20160513/e08484dd/attachment.html>

More information about the users mailing list