Re: [PATCH 08/10] crypto/NX: Add NX GZIP user space API
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2019-12-20 07:42:05
Also in:
linux-crypto
On Thu, Dec 19, 2019 at 12:49:44AM -0800, Haren Myneni wrote:
Virtual Accelerator Switchboard (VAS) can provide support different accelerators, Right now only NX is used, but possible to extend to others in future. Or different functionalities such as fast thread wakeup (VAS feature) with VAS windows. So looking common VAS API for any its accelerators. Need open a window / channel - open() and ioctl()) calls, and setup the communications with mapping address to NX (mmap()) and close the window. Then user space communicates to accelerator directly without kernel involvement. Specific drivers should set window attributes such as how many requests can be send at same time and etc. All other interfaces should be same for any accelerator. Also, since user space sends requests directly, should restrict malicious users to prevent overload NX (security issue). Allowing sysadmin to restrict /dev/crypto/nx-gzip usage.
If you are going to place your driver through the Crypto API then it needs to use the Crypto API interface for user-space access. That interface is af_alg. If this is not a good fit then I suggest that you move your API elsewhere, perhaps to the powerpc tree where the user-space API can then be properly reviewed. It is not feasible to review your driver's user-space API through the crypto tree.
As you suggested, SW crypto API (af_alg) can be used just for NX compression like using API based on the accelerator functionalities. It is socket based API with AF_ALG socket family. But is there a way for sysadmin to restrict usage from user space? Need just few functions in struct proto.
The af_alg interface does not operate in the manner that you describe. It is an interface that maps onto the underlying kernel Crypto API operations. We currently don't have an af_alg module for compression, but if we did we would be closely following the current kernel compression interface. One key feature of af_alg is that it normally is agnostic to the underlying implementation. That is, even when the hardware is absent it would seamlessly switch over to a software implementation. I say normally because there can be exceptions, e.g., with paes and hardware keys. Cheers, -- Email: Herbert Xu [off-list ref] Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt