general improvements for Sculpt
norman.feske at genode-labs.com
Tue Feb 9 14:41:20 CET 2021
> 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
> SHA512 of microsed:
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
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.
> İ'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
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
More information about the users