Thread (31 messages) 31 messages, 7 authors, 2021-03-26

Re: [PATCH v2 1/7] cmdline: Add generic function to build command line.

From: Will Deacon <will@kernel.org>
Date: 2021-03-03 20:58:17
Also in: linux-arch, linuxppc-dev, lkml

On Wed, Mar 03, 2021 at 06:57:09PM +0100, Christophe Leroy wrote:
Le 03/03/2021 à 18:46, Will Deacon a écrit :
quoted
On Wed, Mar 03, 2021 at 06:38:16PM +0100, Christophe Leroy wrote:
quoted
Le 03/03/2021 à 18:28, Will Deacon a écrit :
quoted
On Tue, Mar 02, 2021 at 05:25:17PM +0000, Christophe Leroy wrote:
quoted
This code provides architectures with a way to build command line
based on what is built in the kernel and what is handed over by the
bootloader, based on selected compile-time options.

Signed-off-by: Christophe Leroy <redacted>
---
   include/linux/cmdline.h | 62 +++++++++++++++++++++++++++++++++++++++++
   1 file changed, 62 insertions(+)
   create mode 100644 include/linux/cmdline.h
diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
new file mode 100644
index 000000000000..ae3610bb0ee2
--- /dev/null
+++ b/include/linux/cmdline.h
@@ -0,0 +1,62 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_CMDLINE_H
+#define _LINUX_CMDLINE_H
+
+static __always_inline size_t cmdline_strlen(const char *s)
+{
+	const char *sc;
+
+	for (sc = s; *sc != '\0'; ++sc)
+		; /* nothing */
+	return sc - s;
+}
+
+static __always_inline size_t cmdline_strlcat(char *dest, const char *src, size_t count)
+{
+	size_t dsize = cmdline_strlen(dest);
+	size_t len = cmdline_strlen(src);
+	size_t res = dsize + len;
+
+	/* This would be a bug */
+	if (dsize >= count)
+		return count;
+
+	dest += dsize;
+	count -= dsize;
+	if (len >= count)
+		len = count - 1;
+	memcpy(dest, src, len);
+	dest[len] = 0;
+	return res;
+}
Why are these needed instead of using strlen and strlcat directly?
Because on powerpc (at least), it will be used in prom_init, it is very
early in the boot and KASAN shadow memory is not set up yet so calling
generic string functions would crash the board.
Hmm. We deliberately setup a _really_ early shadow on arm64 for this, can
you not do something similar? Failing that, I think it would be better to
offer the option for an arch to implement cmdline_*, but have then point to
the normal library routines by default.
I don't think it is possible to setup an earlier early shadow.

At the point we are in prom_init, the code is not yet relocated at the
address it was linked for, and it is running with the MMU set by the
bootloader, I can't imagine being able to setup MMU entries for the early
shadow KASAN yet without breaking everything.
That's very similar to us; we're not relocated, although we are at least
in control of the MMU (which is using a temporary set of page-tables).
Is it really worth trying to point to the normal library routines by default
? It is really only a few lines of code hence only not many bytes, and
anyway they are in __init section so they get discarded at the end.
I would prefer to use the normal routines by default and allow architectures
to override them based on their needs, otherwise we'll end up trying to
maintain a "lowest-common-dominator" set of string routines that can be
safely run in whatever different constraints different architectures have.

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help