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
OpenPGP_0x99A5F4B3D4E372A6.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
