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 > +
next prev 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: linkBe 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.