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
