Roadmap 2016

[Vladimir Lushnikov]

I am (as always) excited to see Genode progress in 2016. There have been made 
good points made already on this thread - hopefully I can add some more.

## Growth of the Genode community

One of the key things I would like to see this year is the growth of the 
community behind Genode. Genode is a great technical foundation upon which to 
build things, but not enough people know about it and what it can do. As well 
as the book, we need tutorials, screencasts and talks about it, not just 
necessarily targeted at the communities that are already interested in 
security + microkernels.

This touches a little bit I guess on Genode Labs providing a framework and 
not a solution, but I think by making Genode more accessible lots of 
interesting projects will arise.

Obviously the above is not an invitation to schedule more things into the 
Genode Labs diary about writing more tutorials, but rather to start a 
discussion about what people think needs to be done in this area and perhaps 
some volunteers can step up (I am certainly happy to write about my 
experiences with the USB Armory for example when I get the USB driver to 
finally work).

## Modelling with state machines

I like the direction being taken in 
https://github.com/genodelabs/genode/issues/1832 wrt. making the APIs simpler 
and more state-machine based.

Some DSL for modelling larger state machines is definitely going to prove 
useful, though whether one should be adopted as part of Genode is debatable 
(will servers really be that huge?). I have seen state machines with 10s of 
states and many hundreds of transitions and it does become difficult to 
reason about them purely because you cannot keep them all in your head. I 
personally would prefer a custom textual DSL which is easy to see and edit in 
vim, but there are obviously many approaches out there.

http://mbeddr.com looks interesting as another idea of how to approach this 
problem (have not used it)

## A shell

It would be really neat to have a small shell where you can change the system 
on the fly. I guess it would be similar to the graphical launcher in some 
respects, though I imagine some configuration could also be changed directly 
instead of having to fire up a text editor. Any scripting language would do, 
perhaps Python or Lua (so it would need a small binding and then creation of 
an API). Then it would be a good show-case of, say, configuring an IP address 
(and a new bit of hardware) in Genode vs. Linux. (Maybe, that's just the 
first idea that came to mind).

Maybe even generally it would be nice to have at least a scripting language 
that can be used to write servers in (for faster prototyping for example).


## Desktop + software porting

I think that having Genode on the Desktop is a good goal to have, and even 
having basic networking + a browser can get you very far (just look at 
ChromeOS). Personally I am not interested in x86 desktop cases (for all the 
reasons and more that were summarised in Joanna Rutkowska's talk recently: 
https://media.ccc.de/v/32c3-7352-towards_reasonably_trustworthy_x86_laptops). 
I don't have a Novena but other i.MX6 hardware - I haven't looked at running 
Genode + a GUI on it yet though. So maybe that's a good h/w target outside of 
the x86 world.

In terms of software I would like to see ported:

 * tor
 * rust language
 * pf (*sounds difficult)
 * zeromq
 * node

(I would like to take on Rust, as projects like 
https://github.com/redox-os/redox or the newly announced 
https://robigalia.org are surely going to get some following this year).

## Other points

 * I agree with Pontus' point about providing real code examples in the book 
- playing with code is usually how I learn best and a full-fledged example is 
not always the best place to start, not least because Genode has a lot of 
unique terminology
 * Disk encryption would be very useful in actually having a production-like 
desktop example! (Is the rump based cgd still working fine?)

Hopefully see you all at FOSDEM

Kind regards,
Vladimir

--
***Email confidentiality notice***
This message is private and confidential. Storage and automated scanning of 
this message for selectors and metadata is strictly prohibited.

Solid Ninja Ltd. is a limited company registered in England and Wales. 
Registration number 9622534. Registered office Unit 11, Hove Business Centre, 
East Sussex, BN3 6HA


6. Jan 2016 23:33 by ponast at ...9...:


> Hi,
>
> This is my first post on the list and I will try to substantiate some
> of my ideas/wishes regarding the future of Genode as requested by Norman.
>
> First, I must say that I still have some trouble understanding the use
> case for Genode as a desktop OS. Not that I don't like the idea but I
> think this is such an enormous undertaking that a believe might be
> like aiming too far or maybe like missing lower hanging fruit. It
> might be better to shorten the hops to the future in easier and faster
> achievable milestones. Genode then gets truly usable faster, albeit
> within a smaller community, but one that truly cares. It also gets
> tried in production sooner, which is very important to gain stability
> and real user feedback.
>
> One such step might be to make Genode a viable and usable platform for
> certain domains within embedded computing. This is a much easier
> undertaking as embedded systems not have the same requirements
> regarding ease of use and completeness regarding features. The GUI
> subsystem goes away and hardware support need not be as broad as for
> desktop OSes. I also think that Genode has several additional
> properties that are highly sought after in various embedded domains
> like responsiveness, stability and power efficiency. These
> characteristics should be exploited together with the main benefit of
> Genode as a secure and safe OS to gain maximum impact.
>
> I am glad to see that you have found the state machine being a usable
> pattern. I happen to believe that it would be very beneficial for
> Genode to mostly switch to a fully asynchronous communication paradigm
> based on independent cooperative state machines. Such a paradigm would
> maybe need some enhancements to the asynchronous communication
> protocol to be truly efficient. For instance I believe it might be
> beneficial if parameters could be added to signals in a similar
> fashion to that of RPCs. I have seen the motivation for not adding 
> parameters
> to signals, but I fail to see why the various components shouldn't be
> able to donate dataspace for such storage like they may donate dataspace
> for RPC call parameter storage.
>
> I checked the loopback example you provided regarding a server
> component written according to the state machine pattern. I find it
> somewhat rudimentary and full of if then statements. Now the task at
> hand is simple so a simple pattern makes sense. However for more
> complex components the illustrated approach doesn't scale. I believe
> that Genode would gain in efficiency and clarity by integrating a
> solid state machine framework supporting UML statecharts to some
> degree including hierarchical state machines, It turns out that it not
> is very complicated and quite efficient to integrate such a framework
> providing decent UML statecharts support. I wont go into details how
> it is done, you can check [1] for an elaborate discussion of an
> existing implementation of the state machine idiom. Basically a state
> machine framework consists of three parts:
>
> 1) Abstractions for describing state machines
> 2) Event buffers for storing queued events
> 3) Runner executing state machines and forwarding events to the
>    individual state machine event queues
>
> Neither of the parts is particularly difficult to design. Several
> descriptions exists for 1) [1, 2, 3, 7]. Points 2) and 3) are well
> described in [1] and should not be too difficult to
> implement. According to my own analysis the complete framework QP from
> [1] probably is quite easy to port to Genode. For third party
> developers like me it makes sense as both Genode and QP are provided
> under the same GPL license but possibly not for Genode Labs as they
> would have to license QP. QP provides for most stuff required to execute 
> UML
> statecharts. In addition one gets a) QSPY, a very
> elaborate debugging platform for inspecting system behavior (would
> definitely fit well with Guido Witmonds debugging request) and b) a
> graphical UML state machine designer which appeals to me as it makes
> third party certification much easier due to the higher abstraction
> level in a statechart compared to that of raw c++ code.
>
> My recommendation now is that Norman and the Genodians take a deeper
> look at the state of the art regarding state machine design and
> consider if there is some merit in making use of some existing
> frameworks or standards, most notably the UML statecharts standard. I
> can of course implement the required functionality myself but I
> believe that there is real benefit in having full integration into
> Genode to ease integration with built in components. Having experts
> taking a look at the various trade offs regarding state machine
> framework integration into Genode within the areas of signaling,
> execution, implementation patterns and so on also is of real benefit.
>
> Some changes have been initiated to make Genode more secure and less
> error prone. I think of the abolition of unnecessary pointers and the
> planned removal of global state. These are standard recommendations in
> a number of prominent style guides [4, 5]. I would like to see a more
> systematic approach to the improvement of Genode. As Bruce Schneier
> once stated; "Security is a process, not a product" [6]. With this I
> mean that objectives first should be decided. Is security and
> safety important? Is it important to gain the trust of people with
> little knowledge of Genode internals? If yes to both questions Misra C++
> compliance makes sense as it is the standard in the area. A subset of
> Misra C++ should then be selected for implementation over time. Rules
> not implemented should be motivated very well as to why they not pose
> a security threat. Then the rules should be ordered in a list and
> gradually implemented and thereafter checked for adherence by tools
> like Flexelint. This is the process that some day might lead to Misra
> C++ compliance. The same reasoning apply to the upcoming C++ core
> guidelines or anything else worth adhering to.
>
> Regarding the upcoming update of the book Genode Foundations. What I
> miss in the book is a connection the real code and examples. I believe
> that new readers much easier understand and remember how to use Genode
> if the connection to code and the inner workings are made
> clearer. Here I would take the opportunity to again recommend [1] as a
> book that makes this connection very clear. OK, it is easier to describe 
> state
> machines but I still believe that Norman could find some inspiration in 
> that
> book for the upcoming release of Genode Foundations.
>
>
> See you at FOSDEM,
>
> Pontus
>
>
> [1] Miro Samek, Practical UML Statecharts in C/C++, second ed., 2008
>     (google the title and you´ll find a pdf on the first search page)
> [2] > 
> http://www.drdobbs.com/hierarchical-state-machine-design-in-c/184402040
> [3] > http://accu.org/index.php/journals/252
> [4] > 
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
> [5] > http://www.misra-cpp.com
> [6] > 
> https://www.schneier.com/essays/archives/2000/04/the_process_of_secur.html
> [7] > http://www.boost.org/doc/libs/1_60_0/libs/statechart/doc/index.html
>
> On Tue, Dec 22, 2015 at 1:28 PM, Norman Feske
> <> norman.feske at ...1...> > wrote:
>> Hello,
>>
>> the end of the year 2015 is approaching. So it is time for planning our
>> activities for the upcoming year. I plan to finalize the roadmap until
>> mid of January. Hereby, I'd like to kick off the discussion. It goes
>> without saying that everyone of you is invited to join in!
>>
>> Before I come to my suggestions for 2016, let me briefly revisit the
>> outcome of the roadmap for the past year. One year ago, I suggested
>> three main topics to work on, namely the use of Genode as
>> general-purpose OS, the advancement of our custom base-hw kernel
>> platform, and the use of the seL4 kernel. In the discussions following
>> my posting, many further points were raised, most prominently the need
>> for through documentation, package management, and a sustainable quality
>> of the base system in terms of stability and performance. In top of
>> that, we received quite a few wishes of higher-level functionality such
>> as a modern web browser or other typical desktop-computing features. Of
>> course, we were not able to address all those topics but I am overly
>> happy that we reached the point where a hand full of us (including me)
>> are using Genode as their day-to-day OS. When I initially switched to
>> using the Turmvilla scenario [1] at the end of May, the experience was
>> admittedly a bit painful. But now, just a few months later, the beauty
>> of the system becomes apparent as all the pieces come so nicely
>> together. The performance, stability, and device-driver support have
>> reached a level that leaves people impressed every time I have the
>> chance to show off my system. Once people become interested, there is
>> now the book available, which provides a smooth introduction into
>> Genode. The feedback I receive about the book is overwhelmingly
>> positive. So we did something right in 2015. :-)
>>
>> After having passed the point where a few of us are able to use Genode
>> as day-to-day OS, we should put the emphasis of the upcoming year on
>> ways to make Genode accessible for a wider community. In a recent
>> posting [2], I identified two possible ways to do that. The first way
>> would be publishing a series of step-by-step guides that explain how to
>> put Genode components together in order to create custom system
>> scenarios. Those articles could be accompanied by screencasts or
>> live-system images. Example scenarios could be the Turmvilla scenario,
>> building a home-computer-like system for kids using the Raspberry Pi
>> (like the Genode system my kids are using), building a network appliance
>> like a data diode, tinkering with the USB Armory, etc. Those articles
>> should be inviting to people who enjoy the building of systems. The
>> second way would be to showcase a system with practical value to end
>> users. I am thinking along the lines of a disposable OS like Tails that
>> allows the user to browse the internet via the Tor network. But that is
>> just an idea.
>>
>> In this spirit, I propose the overall focus of 2016 to be: Let us make
>> Genode accessible to the world outside the inner circle of us enthusiasts.
>>
>> On a technical level, this motive implicates the following topics:
>>
>> * The deployment and management of Genode systems, i.e., by bringing
>>   forward Emery's work on the Nix package manager. This direction also
>>   reinforces the need to achieve binary compatibility between the
>>   various base platforms to make the distribution of binary packages,
>>   reproduceable builds, and continues test-and-integration scalable.
>>
>> * Supplementing Genode with user-friendly means to configure the
>>   system (e.g., wireless network, audio, display settings). Right now,
>>   I use Vim as configuration front end, which is cool, but also
>>   intimidating to less technical-minded users.
>>
>> * Accommodation of common desktop use cases like plugging in a USB
>>   stick to work with the files stored on it. Also disk encryption comes
>>   into mind.
>>
>> * Optimization of Genode for the use on a laptop, e.g., addressing
>>   fan control, power management, suspend/resume, and similar features.
>>
>> There are also other possible avenues to support the stated goal:
>>
>> * Identifying ways of how Genode could play a role in related projects
>>   like Qubes OS. For example, we could promote the use of Genode as a
>>   tool for building App VMs as Qubes subsystems. Granted, this scenario
>>   leaves the architectural benefits of Genode with respect to its small
>>   TCB complexity unused as Qubes still relies on Xen, and Linux as
>>   Dom0. But Genode would still (possibly) provide value to the Qubes
>>   project. Maybe, there would be the prospect to replace Dom0 with
>>   Genode in the longer term? However, to drive this direction of work,
>>   we would certainly need someone who is actually using Qubes and has
>>   the natural incentive to work on such an integration.
>>
>> * Making Genode-based systems easily deployable on Amazon's EC2. Similar
>>   to the previous point, it would be beneficial to have someone working
>>   on this topic who is naturally interested in cloud computing.
>>
>> * Foster the cross-pollination of the seL4 and Genode communities. I
>>   got enthusiastic responses about my seL4-related work. There is
>>   definitely a strong interest in this kernel and a growing
>>   anticipation for formally verified software. Today, seL4 lacks a
>>   scalable user-level architecture. This would be the perfect place
>>   where Genode could step in. Genode would ultimately allow the seL4
>>   community to move beyond static system scenarios.
>>
>> Assuming that we succeed in drawing the attention of a broader audience
>> to our project, we should make sure that Genode's API won't undergo
>> major changes soon after this point. Today, I still see a number of
>> deficiencies in the current API. In the past year, we successively moved
>> to a new model of the API (dubbed server API) that promotes the
>> construction of components as state machines rather than procedural
>> programs. All recent components are designed in this style to the great
>> benefit of their robustness. We should finally promote this style
>> towards the base API and get rid of some mistakes we made in the past,
>> in particular the reliance on side effects by using the globally visible
>> Genode::env. I think that we should finalize this API renovation until
>> the mid of 2016. This will also be right the time for updating the
>> Genode book.
>>
>> These are my thoughts about the upcoming year. Now I am curious about
>> yours! :-)
>>
>> Cheers
>> Norman
>>
>> [1] >> https://github.com/genodelabs/genode/issues/1552
>> [2] >> 
>> https://github.com/genodelabs/genode/issues/1000#issuecomment-161260312
>>
>> --
>> Dr.-Ing. Norman Feske
>> Genode Labs
>>
>> http://www.genode-labs.com>>  · >> http://genode.org
>>
>> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
>> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> genode-main mailing list
>> genode-main at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>
>
>
> --
> Hälsningar,
>
> Pontus
>
> ------------------------------------------------------------------------------
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20160107/59024ead/attachment.html>