linux-hardening - Re: [PATCH 2/2] pstore: Replace crypto API compression with zlib

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20230704183128.GD1851@sol.localdomain>
Date:   Tue, 4 Jul 2023 11:31:28 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     linux-hardening@...r.kernel.org, Kees Cook <keescook@...omium.org>,
        "Guilherme G. Piccoli" <gpiccoli@...lia.com>
Subject: Re: [PATCH 2/2] pstore: Replace crypto API compression with
 zlib_deflate library calls

On Tue, Jul 04, 2023 at 03:52:11PM +0200, Ard Biesheuvel wrote:
> Pstore supports compression using a variety of algorithms exposed by the
> crypto API. This uses the deprecated comp (as opposed to scomp/acomp)
> API, and so we should stop using that, and either move to the new API,
> or switch to a different approach entirely.
> 
> Given that we only compress ASCII text in pstore, and considering that
> this happens when the system is likely to be in a highly fragile state,
> the flexibility that the complex crypto API provides does not outweigh
> its impact on the risk that we might encounter additional problems when
> trying to commit the kernel log contents to the pstore backend.
> 
> So let's switch [back] to the zlib deflate library API, and remove all
> the complexity that really has no place in a low-level diagnostic
> facility. Note that, while more modern compression algorithms have been
> added to the kernel in recent years, the code size of zlib deflate is
> substantially smaller, while its performance in terms of compression
> ratio is perfectly acceptable, and speed is irrelevant in this context
> (unless panic() is a performance bottleneck in your workload).
> 
> Signed-off-by: Ard Biesheuvel <ardb@...nel.org>

Actually, LZ4 and LZO both have slightly smaller code size than zlib.

Though, they are really intended for use cases that need high performance, which
as you mention is not important for the pstore use case.

So I think zlib is still fine here.  Just the above argument is a bit
misleading.

In any case, can the rationale for the choice of compression algorithm and API
be documented in the source code itself?  Otherwise I worry that someone will
want to "improve" this code again.

> @@ -157,37 +152,46 @@ static bool pstore_cannot_block_path(enum kmsg_dump_reason reason)
>  static int pstore_compress(const void *in, void *out,
>  			   unsigned int inlen, unsigned int outlen)
>  {
> +	struct z_stream_s zstream = {
> +		.next_in	= in,
> +		.avail_in	= inlen,
> +		.next_out	= out,
> +		.avail_out	= outlen,
> +		.workspace	= compress_workspace,
> +	};
>  	int ret;
>  
>  	if (!IS_ENABLED(CONFIG_PSTORE_COMPRESS))
>  		return -EINVAL;
>  
> -	ret = crypto_comp_compress(tfm, in, inlen, out, &outlen);
> -	if (ret) {
> -		pr_err("crypto_comp_compress failed, ret = %d!\n", ret);
> -		return ret;
> -	}
> +	ret = zlib_deflateInit2(&zstream, Z_DEFAULT_COMPRESSION, Z_DEFLATED,
> +				-MAX_WBITS, DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY);
> +	if (ret != Z_OK)
> +		return -EINVAL;
>  
> -	return outlen;
> +	ret = zlib_deflate(&zstream, Z_FINISH);
> +	if (ret != Z_STREAM_END)
> +		return -EINVAL;
> +
> +	return zstream.total_out;
>  }

The above code looks weird to anyone familiar with the zlib API, since it is
missing the call to zlib_deflateEnd().  It looks like the in-kernel zlib doesn't
really need it, since the in-kernel zlib has been customized to manage memory
differently from the real zlib.  But I recommend including it.

> @@ -629,10 +640,17 @@ void pstore_get_backend_records(struct pstore_info *psi,
>  {
>  	int failed = 0;
>  	unsigned int stop_loop = 65536;
> +	struct z_stream_s zstream;
>  
>  	if (!psi || !root)
>  		return;
>  
> +	if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && compress) {
> +		zstream.workspace = kvmalloc(zlib_inflate_workspacesize(),
> +					     GFP_KERNEL);
> +		zlib_inflateInit2(&zstream, -DEF_WBITS);
> +	}
> +
>  	mutex_lock(&psi->read_mutex);
>  	if (psi->open && psi->open(psi))
>  		goto out;
> @@ -661,7 +679,7 @@ void pstore_get_backend_records(struct pstore_info *psi,
>  			break;
>  		}
>  
> -		decompress_record(record);
> +		decompress_record(record, &zstream);
>  		rc = pstore_mkfile(root, record);
>  		if (rc) {
>  			/* pstore_mkfile() did not take record, so free it. */
> @@ -676,6 +694,7 @@ void pstore_get_backend_records(struct pstore_info *psi,
>  		psi->close(psi);
>  out:
>  	mutex_unlock(&psi->read_mutex);
> +	kvfree(zstream.workspace);

Similarly above: zlib_inflateEnd() isn't being called.  It should happen
alongside freeing 'zstream.workspace'.

- Eric