I see the algif_hash and algif_blkcipher implementations to allow
userspace AF_ALG socket access to kernel blkcipher and hash
algorithms, but has anyone done a algif_compression to allow userspace
access to compression algs? I'm asking specifically wrt the 842
crypto module, which uses the hardware compression coprocessors on
newer powerpc systems.
If not, is there any reason against adding a algif_compression to
provide the access?
Thanks!
Dan Streetman <[email protected]> wrote:
> I see the algif_hash and algif_blkcipher implementations to allow
> userspace AF_ALG socket access to kernel blkcipher and hash
> algorithms, but has anyone done a algif_compression to allow userspace
> access to compression algs? I'm asking specifically wrt the 842
> crypto module, which uses the hardware compression coprocessors on
> newer powerpc systems.
>
> If not, is there any reason against adding a algif_compression to
> provide the access?
For a start nx-842 isn't even hooked into the crypto layer so
there is no chance of exporting it through algif as is.
There is no reason why you couldn't add it of course but that'd
be a first step.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, Apr 3, 2014 at 8:41 AM, Herbert Xu <[email protected]> wrote:
> Dan Streetman <[email protected]> wrote:
>> I see the algif_hash and algif_blkcipher implementations to allow
>> userspace AF_ALG socket access to kernel blkcipher and hash
>> algorithms, but has anyone done a algif_compression to allow userspace
>> access to compression algs? I'm asking specifically wrt the 842
>> crypto module, which uses the hardware compression coprocessors on
>> newer powerpc systems.
>>
>> If not, is there any reason against adding a algif_compression to
>> provide the access?
>
> For a start nx-842 isn't even hooked into the crypto layer so
> there is no chance of exporting it through algif as is.
Wait, isn't it? The crypto/842.c driver connects right to it. Well,
it connects to the compression part of it, but that's the only part
I'm looking at exporting to userspace right now.
> There is no reason why you couldn't add it of course but that'd
> be a first step.
>
> Cheers,
> --
> Email: Herbert Xu <[email protected]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
>> I see the algif_hash and algif_blkcipher implementations to allow
>> userspace AF_ALG socket access to kernel blkcipher and hash
>> algorithms, but has anyone done a algif_compression to allow userspace
>> access to compression algs? I'm asking specifically wrt the 842
>> crypto module, which uses the hardware compression coprocessors on
>> newer powerpc systems.
>>
>> If not, is there any reason against adding a algif_compression to
>> provide the access?
>
> For a start nx-842 isn't even hooked into the crypto layer so
> there is no chance of exporting it through algif as is.
>
> There is no reason why you couldn't add it of course but that'd
> be a first step.
We are also looking for user-space access to the kernel crypto layer
compression algorithms. I have gone through AF_ALG but couldn’t find
support for compression ops through it. This is required for our
hardware zip engines whose driver hooks up to the crypto layer.
I was going through the lists and stumbled across this thread. Has
there been any updates or efforts put up in this direction since this
thread is a few years old. If not, are there any alternate
implementations that allow user-space access to compression? I have
gone through cryptodev and see the same limitation there.
Would appreciate any pointers in this regard.
Thanks,
Abed
(Cavium Inc)
abed mohammad kamaluddin <[email protected]> wrote:
>
> We are also looking for user-space access to the kernel crypto layer
> compression algorithms. I have gone through AF_ALG but couldn’t find
> support for compression ops through it. This is required for our
> hardware zip engines whose driver hooks up to the crypto layer.
>
> I was going through the lists and stumbled across this thread. Has
> there been any updates or efforts put up in this direction since this
> thread is a few years old. If not, are there any alternate
> implementations that allow user-space access to compression? I have
> gone through cryptodev and see the same limitation there.
>
> Would appreciate any pointers in this regard.
The compression interface is currently in a state of flux. We
should make it settle down first before exporting it to user-space.
For a start it would be good to actually switch IPsec/IPcomp over
to the new compression interface.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
> The compression interface is currently in a state of flux. We
> should make it settle down first before exporting it to user-space.
>
> For a start it would be good to actually switch IPsec/IPcomp over
> to the new compression interface.
Thanks Herbert. Are there timelines or ongoing efforts for moving
IPcomp/Ipsec to use acomp? Or any proposals that have been or need to
be taken up in this regard.
Thanks,
Abed
On Fri, Dec 16, 2016 at 07:41:23PM +0530, abed mohammad kamaluddin wrote:
>
> Thanks Herbert. Are there timelines or ongoing efforts for moving
> IPcomp/Ipsec to use acomp? Or any proposals that have been or need to
> be taken up in this regard.
Someone needs to write the patches :)
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert,
We have implemented algif acomp interface for user space applications
to utilize the kernel compression framework and the hardware drivers
using it and have been testing it using userspace zlib library.
However, what we find lacking in the existing acomp implementation is
the ability to pass context data between the applications and the
drivers using the acomp interface. Currently the interface only allows
src/dest data and a flag argument with each request. There are two
context pointers, one in acomp_req and another in crypto_tfm but they
are for internal use and not available to applications through the
api's. Would it be acceptable to add fields that need to be
communicated b/w the driver and applications like history,
csum/adler32, EOF, stream ctx to acomp_req.
Or is there any other way, which I may have missed, through which we
can pass ctx data between applications and drivers while using the
kernel compression framework?
Thanks,
Abed
(Cavium Inc)
On Sat, Dec 10, 2016 at 1:40 PM, Herbert Xu <[email protected]> wrote:
> abed mohammad kamaluddin <[email protected]> wrote:
>>
>> We are also looking for user-space access to the kernel crypto layer
>> compression algorithms. I have gone through AF_ALG but couldn’t find
>> support for compression ops through it. This is required for our
>> hardware zip engines whose driver hooks up to the crypto layer.
>>
>> I was going through the lists and stumbled across this thread. Has
>> there been any updates or efforts put up in this direction since this
>> thread is a few years old. If not, are there any alternate
>> implementations that allow user-space access to compression? I have
>> gone through cryptodev and see the same limitation there.
>>
>> Would appreciate any pointers in this regard.
>
> The compression interface is currently in a state of flux. We
> should make it settle down first before exporting it to user-space.
>
> For a start it would be good to actually switch IPsec/IPcomp over
> to the new compression interface.
>
> Cheers,
> --
> Email: Herbert Xu <[email protected]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Am Montag, 3. April 2017, 08:10:19 CEST schrieb abed mohammad kamaluddin:
Hi abed,
> Hi Herbert,
>
> We have implemented algif acomp interface for user space applications
> to utilize the kernel compression framework and the hardware drivers
> using it and have been testing it using userspace zlib library.
>
> However, what we find lacking in the existing acomp implementation is
> the ability to pass context data between the applications and the
> drivers using the acomp interface. Currently the interface only allows
> src/dest data and a flag argument with each request. There are two
> context pointers, one in acomp_req and another in crypto_tfm but they
> are for internal use and not available to applications through the
> api's. Would it be acceptable to add fields that need to be
> communicated b/w the driver and applications like history,
> csum/adler32, EOF, stream ctx to acomp_req.
>
> Or is there any other way, which I may have missed, through which we
> can pass ctx data between applications and drivers while using the
> kernel compression framework?
If you follow the AF_ALG implementations that are currently in the kernel, a
calling application receives two file descriptors. The first file descriptor
is the reference to a tfm, the second is the reference to a particular
request.
Wouldn't those file descriptors be the reference you are looking for?
Ciao
Stephan
Hi Stephen,
> If you follow the AF_ALG implementations that are currently in the kernel, a
> calling application receives two file descriptors. The first file descriptor
> is the reference to a tfm, the second is the reference to a particular
> request.
>
> Wouldn't those file descriptors be the reference you are looking for?
Those descriptors are sufficient to pass data from userspace
applications to the algif interface.
However the issue is passing those from the interface to the driver
using the current acomp API's.
This is the currently exposed interface to the comp framework. Am I
missing something here?
int (*compress)(struct acomp_req *req);
int (*decompress)(struct acomp_req *req);
struct acomp_req {
struct crypto_async_request base;
struct scatterlist *src;
struct scatterlist *dst;
unsigned int slen;
unsigned int dlen;
u32 flags;
void *__ctx[] CRYPTO_MINALIGN_ATTR;
};
Thanks
Abed
On Mon, Apr 3, 2017 at 12:56 PM, Stephan Müller <[email protected]> wrote:
> Am Montag, 3. April 2017, 08:10:19 CEST schrieb abed mohammad kamaluddin:
>
> Hi abed,
>
>> Hi Herbert,
>>
>> We have implemented algif acomp interface for user space applications
>> to utilize the kernel compression framework and the hardware drivers
>> using it and have been testing it using userspace zlib library.
>>
>> However, what we find lacking in the existing acomp implementation is
>> the ability to pass context data between the applications and the
>> drivers using the acomp interface. Currently the interface only allows
>> src/dest data and a flag argument with each request. There are two
>> context pointers, one in acomp_req and another in crypto_tfm but they
>> are for internal use and not available to applications through the
>> api's. Would it be acceptable to add fields that need to be
>> communicated b/w the driver and applications like history,
>> csum/adler32, EOF, stream ctx to acomp_req.
>>
>> Or is there any other way, which I may have missed, through which we
>> can pass ctx data between applications and drivers while using the
>> kernel compression framework?
>
> If you follow the AF_ALG implementations that are currently in the kernel, a
> calling application receives two file descriptors. The first file descriptor
> is the reference to a tfm, the second is the reference to a particular
> request.
>
> Wouldn't those file descriptors be the reference you are looking for?
>
> Ciao
> Stephan