linux-kernel - Re: Query in Crypto framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 2 Oct 2018 10:42:02 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Kalyani Akula <kalyania@...inx.com>
Cc:     "davem@...emloft.net" <davem@...emloft.net>,
        "kstewart@...uxfoundation.org" <kstewart@...uxfoundation.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "pombredanne@...b.com" <pombredanne@...b.com>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Query in Crypto framework

On Mon, Oct 01, 2018 at 09:30:35AM +0000, Kalyani Akula wrote:
> Hi ,
> 
> We wrote a Xilinx specific AES driver in the crypto framework, while testing we have seen one issue.
> We are trying to send a input data of size 1MB using sendmsg system call from the application, and we could see it is hanging in the af_alg_sendmsg.
> Our analysis is, it is waiting for the availability of the writable memory inside af_alg_wait_for_wmem (entered into infinite loop).
> 
> Is there any limitation on the maximum data that can sent via AF_ALG socket ?

When you make a send(2) system call, you're essentially allocating
kernel memory.  For obvious reasons we don't allow unbounded
allocation of kernel memory from user-space.

In order to process a large amount of data, you should use chaining
for algorithms that support it.  So instead of writing everything
at once, write a certain multiple of blocks and then read the partial
result before writing more.

For AEAD algorithms which do not support chaining, you can work
around this by adjusting the appropriate socket buffer limits.

Note that if you increase the socket buffer limits too much you will
run into system-wide limits which can also be adjusted under /proc.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt