Google Summer of Code 2012

Norman Feske norman.feske at ...1...
Thu Mar 1 09:58:13 CET 2012


> I also read again through and
> For me, one major goal appropriate
> to tackle during the summer is block-device encryption and I want to
> promote it hereby. To use Genode every day in Genode Labs it's crucial
> to protect the confidentiality of some information that's part of the
> Genode code base, e.g., emails and reports. There are several
> expansion stages imaginable to reach the goal and the basic building
> blocks (block-device interface, ATA/SATA driver for Qemu) are already
> in place.

I agree that this topic is nice because it is almost self-contained
(similar to the block cache topic suggested by Stefan). So it can be
tackled without knowing many architectural details or even seeing the
big picture.

That said, I am uncertain about the motivation you gave. From a
student's point of view, our needs at Genode Labs may not provide enough
incentive to go for it. If I were a student, I would prefer working on a
topic that is somehow related to my personal (or more general) needs.
One way of making this topic more convincing may be to take block-level
encryption just as a concrete example to work on, but define the topic
in a more general way. For example "cryptography on Genode". By framing
the topic this way, the student can explore many interesting
technologies (e.g., random-number generators, OpenSSL, GnuTLS, SSH,
GnuGPG) in the context of Genode. The implementation of the block
encryption component would be merely a side effect.

> BTW some of the challenges on our agenda (including iwlagn) depend on
> the availability of test hardware. What do you think, does this render
> these tasks inappropriate for GSoC?

I would not rule them out. If there is someone who is highly interested
in working on a sophisticated topic such as Intel Wireless support and
already has a track record in working on similar things, we should try
to accommodate him/her by providing test hardware. But for a student
without a clear skill set, I would propose a topic that does not involve
such additional expenses. I.e., a topic that can be carried out natively
on Linux or on Qemu.


More information about the users mailing list