Getting Started with Genode

Fri Sep 24 17:51:20 CEST 2021

On Thu, Sep 23, 2021 at 3:00 AM <users-request at lists.genode.org> wrote:

> [CAUTION: Non-UBC Email]
>
> Send users mailing list submissions to
>         users at lists.genode.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.genode.org/listinfo/users
> or, via email, send a message with subject or body 'help' to
>         users-request at lists.genode.org
>
> You can reach the person managing the list at
>         users-owner at lists.genode.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> Today's Topics:
>
>    1. Re: Getting Started with Genode (Christian Helmuth)
>    2. Re: CBE crypt interface (Norman Feske)
>    3. Re: CBE crypt interface (Stefan Thöni)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 23 Sep 2021 10:02:00 +0200
> From: Christian Helmuth <christian.helmuth at genode-labs.com>
> To: users at lists.genode.org
> Subject: Re: Getting Started with Genode
> Message-ID: <20210923080200.GB2343 at genode-labs.com>
> Content-Type: text/plain; charset=utf-8
>
> Hello Sid, welcome to the list!
>
> On Thu, Sep 23, 2021 at 01:04:28 CEST, Sid Agrawal wrote:
> >    - *Running the hello_tutorial*: the hello_tutorial job on qemu does
> not
> >    finish to completing and times out. Below are my steps on ubuntu
> 20.04.1. I
> >    am using the Genode development container
> >    <https://genodians.org/skalk/2020-09-29-docker-devel>, so the tools
> >    should not an issue. I also tried it outside the container.
> >
> > git clone git://github.com/genodelabs/genode.git
> > cd genode
> > tool/ports/prepare_port sel4
> > tool/ports/prepare_port grub2
> > tool/create_builddir x86_64
> >
> > cd x86_64/build/
> > # Change build/x86_64/etc/build.conf.
> > # Change kernel to sel4 and add hello_tutorial
> > diff etc/build.conf.old etc/build.conf
> >
> > 20c20
> > < #KERNEL ?= nova
> > ---
> > > KERNEL ?= sel4
> > 85a86
> > > REPOSITORIES += $(GENODE_DIR)/repos/hello_tutorial
> >
> > make
> > make hello
> > make run/hello # This times out as shown below.
> >
> > [init -> hello_server] creating root component [0m [0m
> > [init -> hello_client] upgrading quota donation for PD session (0
> > bytes, 4 caps)
> > [0m [0m
> > [init] child "hello_server" requests resources: cap_quota=3 [0m [0m
> > [init] child "hello_client" requests resources: ram_quota=0, cap_quota=4
> > [0m [0m
> > Error: Test execution timed out
> >
> > Any comments on what I am doing wrong would be very helpful. Secondly,
> what
> > would be the best way to go about debugging an issue like this.
>
> I suppose you succeded in running the scenario on Linux and NOVA like
> follows.
>
>    make run/hello KERNEL=linux BOARD=linux
>    make run/hello KERNEL=nova
>
> For seL4 I can reproduce what you pasted above, so the issue is
> related to the used platform. As the log output states "hello_server"
> is requesting more resources and requires cap_quota (capability quota)
> increased during an operation that requires 3 caps. A look into the
> init configuration (see hello.run) reveals the following.
>
>   <!-- all components get 50 capabilities per default -->
>   <default caps="50"/>
>
> Now you may grant the component some more caps to make it run
> successully by changing
>
>   <start name="hello_server" caps="54">
>
> to the hello_server start node and running
>
>   make run/hello KERNEL=sel4
>
> This results in additional resource requests
>
>   [init] child "hello_server" requests resources: ram_quota=0, cap_quota=4
>
> The reason is that the seL4 platforms works quite different from NOVA
> and expectedly Linux, which results in a higher capability consumption
> of the used software stack.
>
> The following start nodes render the scenario working again.
>
>   <start name="hello_server" caps="58">
>   ...
>   <start name="hello_client" caps="51">
>
> Thank you, Christian, for the resolution as well as the explanation.

> Please see Chapters "Resource trading" [1] and "Resource assignment"
> [2] in the Genode Foundations book for a thorough explanation.
>
> [1]
> https://genode.org/documentation/genode-foundations/21.05/architecture/Resource_trading.html
> [2]
> https://genode.org/documentation/genode-foundations/21.05/system_configuration/The_init_component.html#Resource_assignment
>
> Regards
> --
> Christian Helmuth
> Genode Labs
>
> https://www.genode-labs.com/ · https://genode.org/
> https://twitter.com/GenodeLabs · https://www.genodians.org/
>
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 23 Sep 2021 10:19:03 +0200
> From: Norman Feske <norman.feske at genode-labs.com>
> To: users at lists.genode.org
> Subject: Re: CBE crypt interface
> Message-ID: <7c847df2-79db-2075-9a77-8bf0cd94fde8 at genode-labs.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Stefan,
>
> > We are implementing hardware accelerated encryption for the CBE and have
> > a question pertaining to this:
>
> I wonder, is performance your primary motivation? If so, there might be
> other opportunities for optimization that are worth implementing first,
> before resorting to hardware acceleration. Should your primary
> motivation be the hiding of the keys from software, that's really cool!
>
> > How should the Cbe_crypto::Interface be implemented when the underlying
> > hardware is asynchronous, e.g. driven by interrupts?
> >
> > I think I understand the semantics of submit_encryption_request and
> > encryption_request_complete but this mechanism doesn't seem to help with
> > asynchronous completion. As far as I can tell, no signals are used with
> > the Cbe_crypto::Interface
> I cannot speak for the 'Cbe_crypto::Interface' specifically. But in
> general, a VFS plugin with outstanding requests is polled for the
> completion (request_complete) each time after I/O happened, i.e., after
> an I/O signal occurred.
>
> You may take a look at how the implementation of the VFS terminal plugin
> responds to incoming data for reading ('_read_avail_handler') [1]. The
> 'read_avail_sigh' corresponds to your interrupt.
>
> [2]
>
> https://github.com/genodelabs/genode/blob/master/repos/os/src/lib/vfs/terminal_file_system.h#L172
>
> To support batches of outstanding requests at the VFS (for hiding the
> latency of the crypto device), one may consider maintaining multiple
> file handles (at the client of the VFS plugin) where each file handle
> can have one request in flight. So the degree of parallelism can be
> tuned by the number of open file handles. Right now, I think that the
> CBE does not schedule more than one crypto request at a time though.
>
> 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
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: OpenPGP digital signature
> URL: <
> http://lists.genode.org/pipermail/users/attachments/20210923/e8a282c8/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 3
> Date: Thu, 23 Sep 2021 10:50:45 +0200
> From: Stefan Thöni <stefan.thoeni at gapfruit.com>
> To: users at lists.genode.org
> Subject: Re: CBE crypt interface
> Message-ID: <12c1ed72-7f40-14fc-ab46-2a88d3877930 at gapfruit.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Norman
>
> Thanks for your answer.
>
> > I wonder, is performance your primary motivation? If so, there might be
> > other opportunities for optimization that are worth implementing first,
> > before resorting to hardware acceleration. Should your primary
> > motivation be the hiding of the keys from software, that's really cool!
>
> Our primary motivation is indeed hiding the keys from the software and
> reducing the risk of side channel attacks via timing or power analysis.
> Offloading the computation from the CPU is a nice side benefit though.
>
> > I cannot speak for the 'Cbe_crypto::Interface' specifically. But in
> > general, a VFS plugin with outstanding requests is polled for the
> > completion (request_complete) each time after I/O happened, i.e., after
> > an I/O signal occurred.
>
> This mechanism doesn't seem to be integrated in the
> Cbe_crypto::Interface which is why we would like to the opinion of the
> original author of this interface before adapting it.
>
> > To support batches of outstanding requests at the VFS (for hiding the
> > latency of the crypto device), one may consider maintaining multiple
> > file handles (at the client of the VFS plugin) where each file handle
> > can have one request in flight. So the degree of parallelism can be
> > tuned by the number of open file handles. Right now, I think that the
> > CBE does not schedule more than one crypto request at a time though.
>
> For the moment I'm just trying to avoid polling and multi-threading
> although latency might be a concern later on.
>
> Best regards
> Stefan
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: OpenPGP_0x99A5F4B3D4E372A6.asc
> Type: application/pgp-keys
> Size: 1867 bytes
> Desc: OpenPGP public key
> URL: <
> http://lists.genode.org/pipermail/users/attachments/20210923/90b9abbf/attachment-0001.key
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: OpenPGP_signature
> Type: application/pgp-signature
> Size: 313 bytes
> Desc: OpenPGP digital signature
> URL: <
> http://lists.genode.org/pipermail/users/attachments/20210923/90b9abbf/attachment-0001.sig
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> users mailing list
> users at lists.genode.org
> https://lists.genode.org/listinfo/users
>
> ------------------------------
>
> End of users Digest, Vol 41, Issue 9
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20210924/a8119aa9/attachment.html>