All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Matteo Croce <mcroce@linux.microsoft.com>
Cc: Anton Vorontsov <anton@enomsg.org>,
	Colin Cross <ccross@android.com>, Tony Luck <tony.luck@intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pstore/platform: build fix when crypto API are disabled
Date: Mon, 6 Jul 2020 19:37:13 -0700	[thread overview]
Message-ID: <202007061852.5B9A0F9ED@keescook> (raw)
In-Reply-To: <20200706234045.9516-1-mcroce@linux.microsoft.com>

On Tue, Jul 07, 2020 at 01:40:45AM +0200, Matteo Croce wrote:
> From: Matteo Croce <mcroce@microsoft.com>
> 
> When building a kernel with CONFIG_PSTORE=y and CONFIG_CRYPTO not set,
> a build error happens:
> 
>     ld: fs/pstore/platform.o: in function `pstore_dump':
>     platform.c:(.text+0x3f9): undefined reference to `crypto_comp_compress'
>     ld: fs/pstore/platform.o: in function `pstore_get_backend_records':
>     platform.c:(.text+0x784): undefined reference to `crypto_comp_decompress'
> 
> This because some pstore code uses crypto_comp_(de)compress
> regardless of the CONFIG_CRYPTO status.
> Fix it by wrapping the (de)compress usage by IS_ENABLED(CONFIG_PSTORE_COMPRESS)

I'm surprised this hasn't come up before in a randconfig! But I guess
it'd require a very lucky config: picking CONFIG_PSTORE but not
CONFIG_CRYPTO _and_ 0 of the many compression options in pstore. :P

But yes, I can reproduce this with:

# CONFIG_CRYPTO is not set
CONFIG_PSTORE=y
# CONFIG_PSTORE_DEFLATE_COMPRESS is not set
# CONFIG_PSTORE_LZO_COMPRESS is not set
# CONFIG_PSTORE_LZ4_COMPRESS is not set
# CONFIG_PSTORE_LZ4HC_COMPRESS is not set
# CONFIG_PSTORE_842_COMPRESS is not set
# CONFIG_PSTORE_ZSTD_COMPRESS is not set

> 
> Signed-off-by: Matteo Croce <mcroce@microsoft.com>
> ---
>  fs/pstore/platform.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
> index a9e297eefdff..6022d8359f96 100644
> --- a/fs/pstore/platform.c
> +++ b/fs/pstore/platform.c
> @@ -436,7 +436,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
>  					  dst_size, &dump_size))
>  			break;
>  
> -		if (big_oops_buf) {
> +		if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && big_oops_buf) {
>  			zipped_len = pstore_compress(dst, psinfo->buf,
>  						header_size + dump_size,
>  						psinfo->bufsize);
> @@ -668,7 +668,7 @@ static void decompress_record(struct pstore_record *record)
>  	int unzipped_len;
>  	char *unzipped, *workspace;
>  
> -	if (!record->compressed)
> +	if (!IS_ENABLED(CONFIG_PSTORE_COMPRESS) || !record->compressed)
>  		return;
>  
>  	/* Only PSTORE_TYPE_DMESG support compression. */
> -- 
> 2.26.2

This report also reminds me that I want to stop hard-coding the possible
compressors[1].

Regardless, for now, I'd like a slightly different patch, which pokes
pstore_compress() instead of doing it inline in pstore_dump():


diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index a9e297eefdff..36714df37d5d 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -269,6 +269,9 @@ static int pstore_compress(const void *in, void *out,
 {
 	int ret;
 
+	if (!IS_ENABLED(CONFIG_PSTORE_COMPRESSION))
+		return -EINVAL;
+
 	ret = crypto_comp_compress(tfm, in, inlen, out, &outlen);
 	if (ret) {
 		pr_err("crypto_comp_compress failed, ret = %d!\n", ret);
@@ -668,7 +671,7 @@ static void decompress_record(struct pstore_record *record)
 	int unzipped_len;
 	char *unzipped, *workspace;
 
-	if (!record->compressed)
+	if (!IS_ENABLED(CONFIG_PSTORE_COMPRESSION) || !record->compressed)
 		return;
 
 	/* Only PSTORE_TYPE_DMESG support compression. */



Let me know if that works for you (it fixes it on my end).

Thanks!

-Kees

[1] https://lore.kernel.org/lkml/20180802215118.17752-1-keescook@chromium.org/

-- 
Kees Cook

  reply	other threads:[~2020-07-07  2:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-06 23:40 [PATCH] pstore/platform: build fix when crypto API are disabled Matteo Croce
2020-07-07  2:37 ` Kees Cook [this message]
2020-07-07 11:25   ` Matteo Croce

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202007061852.5B9A0F9ED@keescook \
    --to=keescook@chromium.org \
    --cc=anton@enomsg.org \
    --cc=ccross@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcroce@linux.microsoft.com \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.