Hi Edoardo,
- 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.
- 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 https://depot.genode.org from your device B?
The discovery part seems to be roughly covered by the index files, e.g., https://depot.genode.org/nfeske/index/, 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.
Cheers Norman