[PATCH 08/10] crypto/NX: Add NX GZIP user space API

[Herbert Xu]

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 <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt