...

So what is the proper way to do this?

A VFS plugin may only use very limited LibC functionality. In many aspects this constellation could be compared to the execution of an application program inside the kernel on Linux. So it's tricky to get right and stable. I suggest to look for other options if pthreads and/or blocking file-system operations come into play.

Beside that you may look into a prior discussion on this list [1] and the FUSE genode-world issue [2] (esp. Norman's reply [3]) for inspiration.

[1] https://lists.genode.org/pipermail/users/2021-November/007828.html [2] https://github.com/genodelabs/genode-world/issues/193 [3] https://github.com/genodelabs/genode-world/issues/193#issuecomment-985327 679

The wolftpm's page says their code is tuned for portability and has no external dependancy, so who knows, maybe could be feasible ? In case it is, thought I'd give additional inspiration about this:

In my specific case, I intended to make the ntfs-3g driver available in Genode ; in the end I realized it basically depends on open()/read()/write()/close() and the like, so that was feasible. What does it look like? Well it's not available from my repo yet, but cnuke was kind enough to make a backup copy of my code on github, look in particular for file "directfs_libc.cc" here:

https://github.com/genodelabs/genode-world/commit/b4c5ebea3ea8fa28243310854d...

I patched an existing Genode-labs file, added a big "extern C...." block (sans aliasing the function names for now). It's ugly as sin (I tend to go "field expedient" when in a major hurry), but might give an idea of how un-complicated the concept is, provided you have a back-end for your pseudo libc.

On a more general note...

Grep'ping through the genode and genode-world repos for re-implementations of strlen(), malloc(), or even open/read/close(), one finds quite a few hits (including the oldest one, from the original repo/demo folder! :-). Then there's my effort mentionned above. Then there will be (?) Stefan's new effort. That's a few instances of duplicated effort/wheel re-inventing.

So it might make sense to consolidate all of this a little bit in the future, i.e. Genode could provide not only their full-fledged LibC based on FreeBSD libc, but also a "micro-libc" for projects that are content with a small subset of libc features including a malloc()/free() pair based on a simple allocator, and so on. Such a 'mini-C' variant would probably require a bit more effort from the user (like "you need to call this initializer at such point from your code, you need to provide a back-end for read/write", etc), but they would be happy to at least have such a trade-off available, instead of facing a rewrite of their libC-using code to make it Genode-API-using code :-). Food for thought.

Cedric

Hello,

Nudged by your comment about the wolftpm sources, I had myself a look into the GitHub repository [1]. After browsing the code I got the impression that the TPM hardware use case (--enable-devtpm) is completely independent of LibC if the backend is reimplemented for Genode. The SWTPM (--enable-swtpm) naturally requires LibC and a network stack to my understanding. Note, I did not check transitive dependencies resulting in wolfcrypt.

Thanks to you observations, we succeeded in making wolftpm run without the libc mostly by using code from the mini C demo and disabling some features of wolfssl we don't care about.

So our proof of concept is now able to get some random from the TPM using wolftpm running inside a VFS plugin.

Have a nice weekend Stefan