general improvements for Sculpt

[Norman Feske]

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
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

-- 
Dr.-Ing. Norman Feske
Genode Labs

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