All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Daniel Walker <danielwa@cisco.com>,
	linuxppc-dev@lists.ozlabs.org, x86@kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Cc: xe-linux-external@cisco.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] lib: early_string: allow early usage of some string functions
Date: Fri, 30 Apr 2021 10:47:39 +0200	[thread overview]
Message-ID: <dc26a67e-dba0-1b8c-3718-3c75415c61f1@csgroup.eu> (raw)
In-Reply-To: <20210430042217.1198052-1-danielwa@cisco.com>



Le 30/04/2021 à 06:22, Daniel Walker a écrit :
> This systems allows some string functions to be moved into
> lib/early_string.c and they will be prepended with "early_" and compiled
> without debugging like KASAN.
> 
> This is already done on x86 for,
> "AMD Secure Memory Encryption (SME) support"
> 
> and on powerpc prom_init.c , and EFI's libstub.
> 
> The AMD memory feature disabled KASAN for all string functions, and
> prom_init.c and efi libstub implement their own versions of the
> functions.
> 
> This implementation allows sharing of the string functions without
> removing the debugging features for the whole system.

This looks good. I prefer that rather than the way you proposed to do it two years ago.

Only one problem, see below.

> +size_t strlcat(char *dest, const char *src, size_t count)
> +{
> +	size_t dsize = strlen(dest);
> +	size_t len = strlen(src);
> +	size_t res = dsize + len;
> +
> +	/* This would be a bug */
> +	BUG_ON(dsize >= count);

powerpc is not ready to handle BUG_ON() in when in prom_init.

Can you do:

#ifndef __EARLY_STRING_ENABLED
	BUG_ON(dsize >= count);
#endif


> +
> +	dest += dsize;
> +	count -= dsize;
> +	if (len >= count)
> +		len = count-1;
> +	memcpy(dest, src, len);
> +	dest[len] = 0;
> +	return res;
> +}
> +EXPORT_SYMBOL(strlcat);
> +#endif
> +

WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Daniel Walker <danielwa@cisco.com>,
	linuxppc-dev@lists.ozlabs.org, x86@kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, xe-linux-external@cisco.com
Subject: Re: [PATCH 1/3] lib: early_string: allow early usage of some string functions
Date: Fri, 30 Apr 2021 10:47:39 +0200	[thread overview]
Message-ID: <dc26a67e-dba0-1b8c-3718-3c75415c61f1@csgroup.eu> (raw)
In-Reply-To: <20210430042217.1198052-1-danielwa@cisco.com>



Le 30/04/2021 à 06:22, Daniel Walker a écrit :
> This systems allows some string functions to be moved into
> lib/early_string.c and they will be prepended with "early_" and compiled
> without debugging like KASAN.
> 
> This is already done on x86 for,
> "AMD Secure Memory Encryption (SME) support"
> 
> and on powerpc prom_init.c , and EFI's libstub.
> 
> The AMD memory feature disabled KASAN for all string functions, and
> prom_init.c and efi libstub implement their own versions of the
> functions.
> 
> This implementation allows sharing of the string functions without
> removing the debugging features for the whole system.

This looks good. I prefer that rather than the way you proposed to do it two years ago.

Only one problem, see below.

> +size_t strlcat(char *dest, const char *src, size_t count)
> +{
> +	size_t dsize = strlen(dest);
> +	size_t len = strlen(src);
> +	size_t res = dsize + len;
> +
> +	/* This would be a bug */
> +	BUG_ON(dsize >= count);

powerpc is not ready to handle BUG_ON() in when in prom_init.

Can you do:

#ifndef __EARLY_STRING_ENABLED
	BUG_ON(dsize >= count);
#endif


> +
> +	dest += dsize;
> +	count -= dsize;
> +	if (len >= count)
> +		len = count-1;
> +	memcpy(dest, src, len);
> +	dest[len] = 0;
> +	return res;
> +}
> +EXPORT_SYMBOL(strlcat);
> +#endif
> +

  parent reply	other threads:[~2021-04-30  8:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30  4:22 [PATCH 1/3] lib: early_string: allow early usage of some string functions Daniel Walker
2021-04-30  4:22 ` Daniel Walker
2021-04-30  4:22 ` [PATCH 2/3] powerpc: prom_init: switch to early " Daniel Walker
2021-04-30  4:22   ` Daniel Walker
2021-04-30  8:51   ` Christophe Leroy
2021-04-30  8:51     ` Christophe Leroy
2021-04-30  4:22 ` [PATCH 3/3] x86: switch amd mem encrypt " Daniel Walker
2021-04-30  4:22   ` Daniel Walker
2021-04-30  8:47 ` Christophe Leroy [this message]
2021-04-30  8:47   ` [PATCH 1/3] lib: early_string: allow early usage of some " Christophe Leroy
2021-04-30  8:50   ` Christophe Leroy
2021-04-30  8:50     ` Christophe Leroy
2021-05-01  7:31     ` Christophe Leroy
2021-05-01  7:31       ` Christophe Leroy
2021-05-03 18:01       ` Daniel Walker
2021-05-03 18:01         ` Daniel Walker
2021-05-03 18:06         ` Daniel Walker
2021-05-03 18:06           ` Daniel Walker

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=dc26a67e-dba0-1b8c-3718-3c75415c61f1@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=akpm@linux-foundation.org \
    --cc=danielwa@cisco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=x86@kernel.org \
    --cc=xe-linux-external@cisco.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.