handling misbehaving filesystem drivers

[Nobody III]

After thinking and going through more code, it seems like it might be
better to update the vfs library and server to support reloading their
configuration cleanly. How feasible is this?
On May 13, 2016 3:41 AM, "Norman Feske" <norman.feske at ...1...>
wrote:

> 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/2210f98c/attachment.html>