Re: Locking for HW crypto accelerators

On Thu, 30 Aug 2018 at 15:19, Stephan Mueller [off-list ref] wrote:

Am Donnerstag, 30. August 2018, 15:09:05 CEST schrieb Krzysztof Kozlowski:

Hi Krzysztof,

quoted

Thanks Stephan for hints. Let's assume the each of init, update and
final are atomic... but how about the relation between update and
final? I have two concurrent users in user-space but only one HW:

Process A:             Process B:
init() and set_key()
                       init() and different key
update(some_data)
                       update(different_data)
final()
                       final()

The final() from process A will now produce the result of hashing/CRC
of some_data and different_data (and even maybe mixed with init() for
different key). All because in the meantime process B added its own
data to the HW.

The question is where is the state of the cipher operation kept that is
produced with each of the init/update/final calls. Your answer implies that
this state is kept in hardware.

Yes, that's correct. The HW once initialized to specific CRC
parameters (size, polynomial, initial value), will operate on this
till another init happens.

But commonly the state is kept in software. Look at ahash_request for example,
the __ctx pointer is intended to point to the memory the driver needs to store
its state.

Pick a random driver implementation and search for ahash_request_ctx, for
example.

I see now some drivers are indeed saving and restoring state.

Thanks!

Best regards,
Krzysztof