Hi Stefan,
> Thanks for your answers, which work great for our hardware crypto backend.
it's good to know that it worked out so well for you. Thank you for the
positive feedback.
> However, I had to make a few changes to the CBE crypto interface to
> enable asynchronous backends:
> https://githu
> Gesendet: Mittwoch, 13. Oktober 2021 um 11:46 Uhr
> Von: "Stefan Thöni"
> An: users@lists.genode.org
> Betreff: Re: CBE crypt interface
>
> Hi Martin, hi Norman
>
> Thanks for your answers, which work great for our hardware crypto backend.
>
> However
Hi Martin, hi Norman
Thanks for your answers, which work great for our hardware crypto backend.
However, I had to make a few changes to the CBE crypto interface to
enable asynchronous backends:
https://github.com/throwException/genode/commit/52245b9df53d289e66b10b7fa56412fb4e649ca1
Do you think
Hi Martin, hi Norman,
Thanks for your answers, I we will try to implement as you suggest.
Best regards
Stefan
On 23.09.21 14:19, Martin Stein wrote:
> Hi Stefan,
>
> I'm sorry for the delayed response of mine, somehow I missed your
> initial mail.
>
> On 23.09.21 12:37, Norman Feske wrote:
>>
Hi Stefan,
I'm sorry for the delayed response of mine, somehow I missed your
initial mail.
On 23.09.21 12:37, Norman Feske wrote:
> 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 occurr
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 a
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 softwa
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 ac
Hello Genodians
We are implementing hardware accelerated encryption for the CBE and have
a question pertaining to this:
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_encryp
