Re: [RFC PATCH v1 1/1] crypto: algif_compression - User-space interface for compression

From: Eric Biggers <ebiggers3@gmail.com>
To: Abed Kamaluddin <abedamu@gmail.com>
Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org,
	akamaluddin@cavium.com, pathreya@cavium.com, machalla@cavium.com
Subject: Re: [RFC PATCH v1 1/1] crypto: algif_compression - User-space interface for compression
Date: Sun, 16 Apr 2017 18:31:19 -0700	[thread overview]
Message-ID: <20170417013119.GA1910@zzz> (raw)
In-Reply-To: <1492108494-10694-2-git-send-email-akamaluddin@cavium.com>

On Fri, Apr 14, 2017 at 12:04:54AM +0530, Abed Kamaluddin wrote:
> crypto: algif_compression - User-space interface for compression
> 
> This patch adds af_alg plugin for compression algorithms of type scomp/acomp
> registered to the kernel crypto layer.
> 
> The user needs to set operation (compression/decompression) as a control
> message to sendmsg, identical to selecting the cipher operation type in case of
> ciphers. Once a sendmsg call occurs, no further writes can be made to the
> socket until all previous data has been processed and read. Therefore the
> interface only supports one request at a time.
> 
> The interface is completely synchronous; all operations are carried out in
> recvmsg and will complete prior to the system call returning.
> 
> The sendmsg and recvmsg interface supports directly reading/writing to 
> user-space without additional copying, i.e., the kernel crypto interface will
> receive the user-space address as its input/output SG list. The scomp interface
> or crypto drivers may copy the data as required.

Fun, so unprivileged users will be able to feed arbitrary data into the kernel's
zlib, LZ4, LZO, etc. compressors and decompressors.  Including zlib which is 12
years out of date from the upstream version.  Moreover, if anyone decides to
optimize these to directly support the new "acomp" (page-based) API, e.g. for
zlib by using its streaming API, then the algorithms will be passed the actual
userspace memory which can be modified by userspace concurrently.  When people
write compression algorithms usually it's assumed that's not possible.  At the
very least, it's unlikely to have been covered by fuzz testing that's been done
on the original userspace versions of these algorithms.  They might be safe by
chance, but I don't know.

Why does userspace need to be able to call the in-kernel zlib, LZ4, LZO, etc.
anyway?  At the very least, how about limiting the new attack surface by only
exposing algorithms provided by hardware drivers?

Eric