CBE crypt interface

[Norman Feske]

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.sig>