Hello Ross,
thanks for your nice wishes and for the very helpful suggestions!
I've been away from the computer for a while and am starting to get back into programming. I'm keen focus on a couple of small personal Genode projects I've wanted to do for a some time. I've a few questions and suggestions to help build the Genode community from the perspective of a hobby programmer like me:
- could you supply a logo to display on web-pages for linking back
to the Genode web-site.
Of course. I guess you are thinking about a small banner, e.g, sized at 160x60 pixels? We are currently reworking our website and will add such a logo to the new site.
- As-far-as I can see there is there no place on the Genode site for
listing 3rd party associated projects- do you plan in the future to offer something like this?
Currently this section is missing for the mere reason that we are not aware of such projects. Of course, we hope that this will change soon and will be more than happy to add such a section. BTW, if you have information to share about what you are doing, please don't hesitate to post it here.
- I would like to make a small donation to this project- could you
provide a bitcoin address? (It does give one a nice warm fuzzy feeling knowing that you've helped a project that you use)
Admittedly, we haven't though about this yet. Good idea.
- Is it planned for Genode support secure booting and attestation in
the future? Secure boot + local object-cap OS + web lends itself to many interesting project possibilies: eg- p2p social networking where the user has true control over their own personal info, or a fast and efficient p2p digital currency, etc. (I believe that there are drivers for the intel TPM chips in Linux--maybe these could help?)
I agree that the TPM driver itself should not be a big deal. But I think that combining Genode with authenticated booting is more far reaching than that:
For several years we are spinning some ideas in the back of our heads about this topic. Apparently, Genode's hierarchy of processes fits extremely well with authenticated booting (much better than current commodity OS architectures). In principle, we could enable each process to produce an attest of itself and its individual TCB by slightly enhancing the parent protocol. When called for an attest, the parent would produce an attest for itself (by calling its parent), the calling child, and eventually other children whose services are used by child. The attestation would work recursively down the tree until it ends at the root (of trust). Consequently the measured TCB is specific for each individual application. It comprises the set of processes involved in the chain of parents and those implementing the sessions used by the applications. By measuring the TCB this way (in contrast to tying the TCB to one particular version of a monolithic kernel), the attest would provide information that is actually meaningful to a remote party.
I think that this could make TPMs useful for general-purpose computing in positive ways (in contrast to their typically attributed purpose of locking down computers).
However, as I said, even though we have this idea in mind for a while now, we haven't had the time to put it into practice yet. If you are interested in working on it, I would be delighted to lend a helping hand.
Thanks again, and all the best for 2012!
Norman