general improvements for Sculpt

Norman Feske norman.feske at
Tue Feb 9 14:41:20 CET 2021

Hi Edoardo,

> 2) Norman, as already mentioned I wasn't able to build my microsed
> interpreter using Genode's libc,  as reference I'll attach a naive
> version of microsed, with few modifications from the original minised
> project, I am still trying to insert the exceptional "exec" keyword,
> which handles Genode's based System calls, Could I know if the Genode's
> libc version support the homonymun function exec?
> I haven't still tried it yet!
> Could I also have general feedback on this? persists still some bugs (as
> the -e flag which causes an instant core dump) but I am working for
> fixing those issues, The real power up is in the size and speed
> optimization.
> {
> SHA512 of microsed:
> 8b863900afe6f044cc6b33291fcf0630da444916104db24a97dc628dc687841b14fe1260813d7beb6dcd9da4dbfd9805a67764a67de6218ebf046c0a270c40a6
> }

I'm afraid that I am not able to help you out here. There seems to be no
way around manual instrumenting and debugging.

For getting feedback, you may consider linking to a publicly accessible
Git branch of your work, e.g., via GitHub. I think that I'm not alone
with my hesitation to dig into a zip file that comes attached to a
mailing-list posting. Providing a link to a branch is a great way to
avoid such friction.

> 3) Regarding to the last part of my first post, I want to explain again
> the idea of a new depot system, based on PANs which works as follow:
>   - 1] in this initial situation, consider 2 devices: A and B, in one of
> those there is installed the Genode os (Sculpt in our case, this is the
> device A) while the device B has installed a "server" application, so B
> can have linux/Windows/Macos ecc.. but with an official Genode server app.
>   - 2] Now let's figure out that B want to offer to A a customized
> package, the user of the device A can set up an automatic
>        live Depot search which involves the use of bluetooth (or any
> general near field communication structure) for scanning the nearest
>         depot servers (device B), now, if the device A choose the
> respective device B, it starts a key exchange communication where,
>         at the end, if the device B is authenticated, the device A can
> see and install the device's B packages through the normal Depot   system.
>   This idea could be great for portable and embedded devices but, as
> obvious, new vulnerability issues will be born.

Except for the bluetooth part, I somehow fail to see the difference from
the existing depot mechanism.

I wonder, what distinguishes e.g., the server that hosts from your device B?

The discovery part seems to be roughly covered by the index files, e.g.,, which are the basis for the
depot-selection menu structures of Sculpt OS.

Doesn't the remaining part of your picture comes down to tunneling
TCP/IP (for https) over a bluetooth connection or mesh network?
Admittedly, I'm not well versed in this area.

I think security is not an issue because the depot mechanism does not
trust the network infrastructure and the depot server infrastructure
anyway. The end-to-end integrity of depot content (including index
files) is verified via OpenPGP signatures.

In short, I encourage you to further experiment with the building blocks
that are already in place. In particular, if using wifi instead of
bluetooth, your idea is no far off at all.

> PS:
> İ've read some articles on your site, could I know if you already use a
> fuzzing system for verifying the presence of bugs in Sculpt os ?
> This can be an interesting topic for future articles, as soon I can I'll
> experiment something similar.

Is far as I know, there is no such activity. If you decide to
investigate, I'd be de1igthed to hear about your findings.


Dr.-Ing. Norman Feske
Genode Labs ·

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list