VFS server hardening for the use as resource multiplexer

[nfeske]

The VFS server as added in issue #1648 allows us to export an arbitrary virtual file systems as a file-system service. In the future, it will eventually replace most of the other file-system services because their functionality can be easily emulated by the combination of the VFS with various VFS plugins.

However, this aspired future raises security concerns expressed in the discussion of #1648.

• The node cache as present in the original VFS implementation may be misused as denial-of-service vector or as a covert channel.
• The RAM consumption of the VFS must be subjected to a policy that ensures the robustness of the VFS in the presence of misbehaving clients.
• The use of env()->heap() for allocating VFS handles does not follow the heap partitioning scheme as advised in our book http://genode.org/documentation/genode-foundations-15-05.pdf in Section 3.3.3. This was acceptable as long as the VFS was solely used as a library but it is an unfortunate design choice in a resource multiplexer.

More elaborate descriptions of those problems are given in the comments of #1648.

[ehmry]

One of the reasons for the node cache was to propagate notification signals between sessions, something that should happen at the VFS anyway for the sake of consistency between the VFS and the File_system interfaces.

[ehmry]

I have rewritten most of the VFS server with the new Out_of_metadata exception in mind.

Each session uses its own ram session and heap to allocate handles, the node cache is gone. I also changed the behaviour for clients that do not match policy from explicit denial to read-only access at the root. This is because I think its better to deny clients before the request reaches the server, and an empty <policy/> node looks rather vague if you don't know why it is there.

The VFS server now uses more memory overall, but only needs a small initial donation from the parent. I fixed the dangling handle pointer issue in the ram file system and put in allocation guards to throw NO_SPACE, so memory exhaustion from the ram plugin shouldn't effect the reliability of the server.

I made some other trailing changes to the VFS, these I made while debugging the server.

A few of these commits overlap other issues, so I say cherry pick from my issue1751 branch, and let that close them.

[ehmry]

"lib/vfs: consistent device and inode enumeration" d974fb3 moved to #1929.

[nfeske]

That sounds fantastic!

[ehmry]

The next improvement on the VFS should be the fair processing of packets, right now a client can hog the server thread by submitting a constant stream of packets.

[chelmuth]

@ehmry I merged this great line of work, but have one remaining question you may help me to answer. In 784c7eb, you changed inode from unsigned long to unsigned in Vfs::Directory_service::Stat and I'm wondering what is your intention behind this change. Also in some places, the VFS code stores (addr_t)this in inode and device members, which is incompatible with unsigned integers on 64-bit.

[ehmry]

I bumped it down because ino_t is a uint32 in the libc, and I intended the addr_t inodes to get narrowed, I hoped as long as the low bits come through they should be unique.

[chelmuth]

I'd prefer to stay with unsigned long for both members. (At least my 64-bit) Ubuntu uses

sizeof(unsigned) = 4
sizeof(unsigned long) = 8
sizeof(ino_t) = 8
sizeof(dev_t) = 8

[cnuke]

Only for historical reasons FreeBSD uses (or maybe used by now) 32bit inode numbers. I would also vote for using unsigned long in the VFS.

[ehmry]

Ok, I can make a fixup commit now.

[chelmuth]

Great.

[ehmry]

I left device as it is, 32bits.

[ehmry]

Just ignore 32e0a62 and use e8bdf61.

[chelmuth]

Merged it just now. Thanks for addressing device too - I'll sleep better at night with the patch ;-)

[ehmry]

I have another small fixup, 31925b7. This one causes the server to exit if there is no <vfs/> configured.