linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Sami Tolvanen <samitolvanen@google.com>
To: Masahiro Yamada <masahiroy@kernel.org>, Will Deacon <will@kernel.org>
Cc: linux-arch@vger.kernel.org, x86@kernel.org,
	Kees Cook <keescook@chromium.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	kernel-hardening@lists.openwall.com,
	Peter Zijlstra <peterz@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kbuild@vger.kernel.org,
	Nick Desaulniers <ndesaulniers@google.com>,
	linux-kernel@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	clang-built-linux@googlegroups.com,
	Sami Tolvanen <samitolvanen@google.com>,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 01/30] lib/string.c: implement stpcpy
Date: Fri, 18 Sep 2020 13:14:07 -0700	[thread overview]
Message-ID: <20200918201436.2932360-2-samitolvanen@google.com> (raw)
In-Reply-To: <20200918201436.2932360-1-samitolvanen@google.com>

From: Nick Desaulniers <ndesaulniers@google.com>

LLVM implemented a recent "libcall optimization" that lowers calls to
`sprintf(dest, "%s", str)` where the return value is used to
`stpcpy(dest, str) - dest`. This generally avoids the machinery involved
in parsing format strings.  `stpcpy` is just like `strcpy` except it
returns the pointer to the new tail of `dest`.  This optimization was
introduced into clang-12.

Implement this so that we don't observe linkage failures due to missing
symbol definitions for `stpcpy`.

Similar to last year's fire drill with:
commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")

The kernel is somewhere between a "freestanding" environment (no full libc)
and "hosted" environment (many symbols from libc exist with the same
type, function signature, and semantics).

As H. Peter Anvin notes, there's not really a great way to inform the
compiler that you're targeting a freestanding environment but would like
to opt-in to some libcall optimizations (see pr/47280 below), rather than
opt-out.

Arvind notes, -fno-builtin-* behaves slightly differently between GCC
and Clang, and Clang is missing many __builtin_* definitions, which I
consider a bug in Clang and am working on fixing.

Masahiro summarizes the subtle distinction between compilers justly:
  To prevent transformation from foo() into bar(), there are two ways in
  Clang to do that; -fno-builtin-foo, and -fno-builtin-bar.  There is
  only one in GCC; -fno-buitin-foo.

(Any difference in that behavior in Clang is likely a bug from a missing
__builtin_* definition.)

Masahiro also notes:
  We want to disable optimization from foo() to bar(),
  but we may still benefit from the optimization from
  foo() into something else. If GCC implements the same transform, we
  would run into a problem because it is not -fno-builtin-bar, but
  -fno-builtin-foo that disables that optimization.

  In this regard, -fno-builtin-foo would be more future-proof than
  -fno-built-bar, but -fno-builtin-foo is still potentially overkill. We
  may want to prevent calls from foo() being optimized into calls to
  bar(), but we still may want other optimization on calls to foo().

It seems that compilers today don't quite provide the fine grain control
over which libcall optimizations pseudo-freestanding environments would
prefer.

Finally, Kees notes that this interface is unsafe, so we should not
encourage its use.  As such, I've removed the declaration from any
header, but it still needs to be exported to avoid linkage errors in
modules.

Reported-by: Sami Tolvanen <samitolvanen@google.com>
Suggested-by: Andy Lavr <andy.lavr@gmail.com>
Suggested-by: Arvind Sankar <nivedita@alum.mit.edu>
Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Kees Cook <keescook@chromium.org>
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: stable@vger.kernel.org
Link: https://bugs.llvm.org/show_bug.cgi?id=47162
Link: https://bugs.llvm.org/show_bug.cgi?id=47280
Link: https://github.com/ClangBuiltLinux/linux/issues/1126
Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html
Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html
Link: https://reviews.llvm.org/D85963
---
 lib/string.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/lib/string.c b/lib/string.c
index 6012c385fb31..4288e0158d47 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -272,6 +272,30 @@ ssize_t strscpy_pad(char *dest, const char *src, size_t count)
 }
 EXPORT_SYMBOL(strscpy_pad);
 
+/**
+ * stpcpy - copy a string from src to dest returning a pointer to the new end
+ *          of dest, including src's %NUL-terminator. May overrun dest.
+ * @dest: pointer to end of string being copied into. Must be large enough
+ *        to receive copy.
+ * @src: pointer to the beginning of string being copied from. Must not overlap
+ *       dest.
+ *
+ * stpcpy differs from strcpy in a key way: the return value is a pointer
+ * to the new %NUL-terminating character in @dest. (For strcpy, the return
+ * value is a pointer to the start of @dest). This interface is considered
+ * unsafe as it doesn't perform bounds checking of the inputs. As such it's
+ * not recommended for usage. Instead, its definition is provided in case
+ * the compiler lowers other libcalls to stpcpy.
+ */
+char *stpcpy(char *__restrict__ dest, const char *__restrict__ src);
+char *stpcpy(char *__restrict__ dest, const char *__restrict__ src)
+{
+	while ((*dest++ = *src++) != '\0')
+		/* nothing */;
+	return --dest;
+}
+EXPORT_SYMBOL(stpcpy);
+
 #ifndef __HAVE_ARCH_STRCAT
 /**
  * strcat - Append one %NUL-terminated string to another
-- 
2.28.0.681.g6f77f65b4e-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-09-18 20:18 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-18 20:14 [PATCH v3 00/30] Add support for Clang LTO Sami Tolvanen
2020-09-18 20:14 ` Sami Tolvanen [this message]
2020-09-18 20:14 ` [PATCH v3 02/30] RAS/CEC: Fix cec_init() prototype Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 03/30] x86/boot/compressed: Disable relocation relaxation Sami Tolvanen
2020-09-21 15:53   ` Nick Desaulniers
2020-09-18 20:14 ` [PATCH v3 04/30] x86/asm: Replace __force_order with memory clobber Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 05/30] kbuild: preprocess module linker script Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 06/30] objtool: Add a pass for generating __mcount_loc Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 07/30] objtool: Don't autodetect vmlinux.o Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 08/30] kbuild: add support for objtool mcount Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 09/30] x86, build: use " Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 10/30] treewide: remove DISABLE_LTO Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 11/30] kbuild: add support for Clang LTO Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 12/30] kbuild: lto: fix module versioning Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 13/30] kbuild: lto: postpone objtool Sami Tolvanen
2020-09-18 21:27   ` Kees Cook
2020-09-21 18:58     ` Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 14/30] kbuild: lto: limit inlining Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 15/30] kbuild: lto: merge module sections Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 16/30] kbuild: lto: remove duplicate dependencies from .mod files Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 17/30] init: lto: ensure initcall ordering Sami Tolvanen
2020-09-18 21:29   ` Kees Cook
2020-09-18 20:14 ` [PATCH v3 18/30] init: lto: fix PREL32 relocations Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 19/30] PCI: Fix PREL32 relocations for LTO Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 20/30] modpost: lto: strip .lto from module names Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 21/30] scripts/mod: disable LTO for empty.c Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 22/30] efi/libstub: disable LTO Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 23/30] drivers/misc/lkdtm: disable LTO for rodata.o Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 24/30] arm64: export CC_USING_PATCHABLE_FUNCTION_ENTRY Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 25/30] arm64: vdso: disable LTO Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 26/30] KVM: arm64: disable LTO for the nVHE directory Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 27/30] arm64: allow LTO_CLANG and THINLTO to be selected Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 28/30] x86, vdso: disable LTO only for vDSO Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 29/30] x86, cpu: disable LTO for cpu.c Sami Tolvanen
2020-09-18 20:14 ` [PATCH v3 30/30] x86, build: allow LTO_CLANG and THINLTO to be selected Sami Tolvanen
2020-09-18 20:22 ` [PATCH v3 00/30] Add support for Clang LTO Sedat Dilek
2020-09-18 20:50   ` Sami Tolvanen
2020-09-18 20:53     ` Nick Desaulniers

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=20200918201436.2932360-2-samitolvanen@google.com \
    --to=samitolvanen@google.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).