On Thu, Sep 23, 2021 at 3:00 AM <[email protected]> wrote:
> [CAUTION: Non-UBC Email] > > Send users mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: [email protected] > Subject: Re: Getting Started with Genode > Message-ID: <[email protected]> > 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 <[email protected]> > To: [email protected] > Subject: Re: CBE crypt interface > Message-ID: <[email protected]> > 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 <[email protected]> > To: [email protected] > Subject: Re: CBE crypt interface > Message-ID: <[email protected]> > 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 > [email protected] > https://lists.genode.org/listinfo/users > > ------------------------------ > > End of users Digest, Vol 41, Issue 9 > ************************************ >
_______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
