CBE crypt interface

[Norman Feske]

Hi Stefan,

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

even though I'm not the author for the 'Cbe_crypto' interface, let me
clarify how the control flow of asynchronous I/O works in the VFS in
general.

The control flow is always driven by the client of the VFS, e.g., the
libc or the VFS server. Whenever the client detects that I/O happened
(an I/O signal occurred), it checks each outstanding VFS request for
possible progress. In the case of the CBE, there is a chain. For
example, the CBE client requests the reading of a block. The CBE, in
turn, requests the 'Cbe_crypto' to decrypt data as a prerequisite of
finishing the block-read request.

Each time, some I/O happened, the client (e.g., the libc's 'read') asks
the VFS for possible progress of the read request (by calling
'complete_read'). This call eventually reaches the CBE. The CBE, in
turn, checks the progress of its outstanding crypto operation
('complete_read'). This is what I meant with polling. It is not busy
polling but checking for progress each time after I/O happened. This
checking is done transitively (libc checks the VFS, VFS checks the CBE,
CBE checks crypto).

For this to work, one has to make sure that the I/O backends of the VFS
plugins use 'Io_signal_handler' not mere 'Signal_handler' for the
reception of asynchronous events like your device interrupt. Otherwise
the VFS client won't notice that I/O happened. You may follow the use of
the 'Io_progress_handler' interface in base/entrypoint.h to connect the
dots.

Hence, there is no special feature in the 'Cbe_crypto::Interface' needed
to support asynchronous operation. The pair of 'request' (submit work)
and 'complete' (check the state of the submitted work) functions suffices.

However, as I said above, I've no experience with the 'Cbe_crypto'
interface specifically and hope that I'm not telling anything wrong.

Maybe Martin or Josef can chime in to substantiate?

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

Sorry for the confusion. I was not speaking of busy polling or
multi-threading at all. If the batching of crypto operations is not a
concern of you (right now), please better ignore this paragraph.

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/90d89125/attachment.sig>