[CAUTION: Non-UBC Email]
Send users mailing list submissions to
users@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@lists.genode.org
You can reach the person managing the list at
users-owner@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@genode-labs.com>
To: users@lists.genode.org
Subject: Re: Getting Started with Genode
Message-ID: <20210923080200.GB2343@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@genode-labs.com>
To: users@lists.genode.org
Subject: Re: CBE crypt interface
Message-ID: <7c847df2-79db-2075-9a77-8bf0cd94fde8@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@gapfruit.com>
To: users@lists.genode.org
Subject: Re: CBE crypt interface
Message-ID: <12c1ed72-7f40-14fc-ab46-2a88d3877930@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@lists.genode.org
https://lists.genode.org/listinfo/users
------------------------------
End of users Digest, Vol 41, Issue 9
************************************