[PATCH 0/1] Allow setting hostname before userspace starts

[PATCH 0/1] Allow setting hostname before userspace starts

[Dan Moulding]

Some userspace processes may rely on gethostname to always return the
correct machine name. However, the only way that the hostname may be
set is by some other userspace process calling sethostname
first. During boot, if a process that depends on gethostname runs
before sethostname has been called, then the process that called
gethostname is going to get an incorrect result.

A real-world case where this comes up is with mdadm, which if
gethostname returns the wrong name, can cause local md-raid arrays to
appear to be foreign arrays. This can alter how mdadm assembles the
array, or can even cause array assembly to fail. I imagine there are
probbaly other real-world cases where undesirable behavior results when
the hostname is not set early enough.

I'm proposing adding the option to set the hostname from a kernel
parameter, so that the correct host name can be guaranteed to be set
before any userspace process can call gethostname.

I can imagine an even better way to do this would be to have the
hostname written to some non-volatile storage (like a firmware NVRAM
variable or such), which the kernel could read out during early
boot. But, alas, such designs require hardware support, standards, and
cooperation. This proposal is an alternative that can provide a simple
and immediate solution.

I'm sending this to linux-kernel since I don't see any list that's a
better fit. If there is any other I should send to instead, please let
me know. (linux-doc also included since kernel-parameters.txt is
touched).

Thank you for consideration,

  -- Dan

Dan Moulding (1):
  init: Add "hostname" kernel parameter

 Documentation/admin-guide/kernel-parameters.txt | 13 +++++++++++++
 init/version.c                                  | 17 +++++++++++++++++
 2 files changed, 30 insertions(+)

-- 
2.35.1

[PATCH 1/1] init: Add "hostname" kernel parameter

[Dan Moulding]

The gethostname system call returns the hostname for the current
machine. However, the kernel has no mechanism to initially set the
current machine's name in such a way as to guarantee that the first
userspace process to call gethostname will receive a meaningful
result. It relies on some unspecified userspace process to first call
sethostname before gethostname can produce a meaningful name.

Traditionally the machine's hostname is set from userspace by the init
system. The init system, in turn, often relies on a configuration file
(say, /etc/hostname) to provide the value that it will supply in the
call to sethostname. Consequently, the file system containing
/etc/hostname usually must be available before the hostname will be
set. There may, however, be earlier userspace processes that could
call gethostname before the file system containing /etc/hostname is
mounted. Such a process will get some other, likely meaningless, name
from gethostname (such as "(none)", "localhost", or "darkstar").

A real-world example where this can happen, and lead to undesirable
results, is with mdadm. When assembling arrays, mdadm distinguishes
between "local" arrays and "foreign" arrays. A local array is one that
properly belongs to the current machine, and a foreign array is one
that is (possibly temporarily) attached to the current machine, but
properly belongs to some other machine. To determine if an array is
local or foreign, mdadm may compare the "homehost" recorded on the
array with the current hostname. If mdadm is run before the root file
system is mounted, perhaps because the root file system itself resides
on an md-raid array, then /etc/hostname isn't yet available and the
init system will not yet have called sethostname, causing mdadm to
incorrectly conclude that all of the local arrays are foreign.

Solving this problem *could* be delegated to the init system. It could
be left up to the init system (including any init system that starts
within an initramfs, if one is in use) to ensure that sethostname is
called before any other userspace process could possibly call
gethostname. However, it may not always be obvious which processes
could call gethostname (for example, udev itself might not call
gethostname, but it could via udev rules invoke processes that
do). Additionally, the init system has to ensure that the hostname
configuration value is stored in some place where it will be readily
accessible during early boot. Unfortunately, every init system will
attempt to (or has already attempted to) solve this problem in a
different, possibly incorrect, way. This makes getting consistently
working configurations harder for users.

I believe it is better for the kernel to provide the means by which
the hostname may be set early, rather than making this a problem for
the init system to solve. The option to set the hostname during early
startup, via a kernel parameter, provides a simple, reliable way to
solve this problem. It also could make system configuration easier for
some embedded systems.

Signed-off-by: Dan Moulding <dmoulding@me.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 13 +++++++++++++
 init/version.c                                  | 17 +++++++++++++++++
 2 files changed, 30 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 3f1cc5e317ed..873481d72e94 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1615,6 +1615,19 @@
 			Valid parameters: "on", "off"
 			Default: "on"
 
+	hostname=	[KNL] Set the hostname (aka UTS nodename).
+			Format: <string>
+			This allows setting the system's hostname during early
+			startup. This sets the name returned by gethostname.
+			Using this parameter to set the hostname makes it
+			possible to ensure the hostname is correctly set before
+			any userspace processes run, avoiding the possibility
+			that a process may call gethostname before the hostname
+			has been explicitly set, resulting in the calling
+			process getting an incorrect result. The string must
+			not exceed the maximum allowed hostname length (usually
+			64 characters) and will be truncated otherwise.
+
 	hlt		[BUGS=ARM,SH]
 
 	hpet=		[X86-32,HPET] option to control HPET usage
diff --git a/init/version.c b/init/version.c
index 1a356f5493e8..66d237d5629c 100644
--- a/init/version.c
+++ b/init/version.c
@@ -11,6 +11,8 @@
 #include <linux/build-salt.h>
 #include <linux/elfnote-lto.h>
 #include <linux/export.h>
+#include <linux/init.h>
+#include <linux/printk.h>
 #include <linux/uts.h>
 #include <linux/utsname.h>
 #include <generated/utsrelease.h>
@@ -35,6 +37,21 @@ struct uts_namespace init_uts_ns = {
 };
 EXPORT_SYMBOL_GPL(init_uts_ns);
 
+static int __init early_hostname(char *arg)
+{
+	size_t bufsize = sizeof(init_uts_ns.name.nodename);
+	size_t maxlen  = bufsize - 1;
+
+	strncpy(init_uts_ns.name.nodename, arg, bufsize);
+	if (strlen(arg) > maxlen) {
+		pr_warn("hostname parameter exceeds %zd characters and will be truncated",
+			maxlen);
+		init_uts_ns.name.nodename[maxlen] = '\0';
+	}
+	return 0;
+}
+early_param("hostname", early_hostname);
+
 /* FIXED STRINGS! Don't touch! */
 const char linux_banner[] =
 	"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
-- 
2.35.1

Re: [PATCH 1/1] init: Add "hostname" kernel parameter

[kernel test robot]

Hi Dan,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linux/master]
[also build test WARNING on hnaz-mm/master linus/master v5.18-rc5 next-20220505]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/intel-lab-lkp/linux/commits/Dan-Moulding/Allow-setting-hostname-before-userspace-starts/20220506-023146
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 107c948d1d3e61d10aee9d0f7c3d81bbee9842af
config: riscv-randconfig-r042-20220505 (https://download.01.org/0day-ci/archive/20220506/202205060821.6KCNxZBf-lkp@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/intel-lab-lkp/linux/commit/1071875b349d9b8307eb0f4d23dda06a2301fe03
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Dan-Moulding/Allow-setting-hostname-before-userspace-starts/20220506-023146
        git checkout 1071875b349d9b8307eb0f4d23dda06a2301fe03
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1 O=build_dir ARCH=riscv SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

   init/version.c: In function 'early_hostname':
>> init/version.c:45:9: warning: 'strncpy' specified bound 65 equals destination size [-Wstringop-truncation]
      45 |         strncpy(init_uts_ns.name.nodename, arg, bufsize);
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


vim +/strncpy +45 init/version.c

    39	
    40	static int __init early_hostname(char *arg)
    41	{
    42		size_t bufsize = sizeof(init_uts_ns.name.nodename);
    43		size_t maxlen  = bufsize - 1;
    44	
  > 45		strncpy(init_uts_ns.name.nodename, arg, bufsize);
    46		if (strlen(arg) > maxlen) {
    47			pr_warn("hostname parameter exceeds %zd characters and will be truncated",
    48				maxlen);
    49			init_uts_ns.name.nodename[maxlen] = '\0';
    50		}
    51		return 0;
    52	}
    53	early_param("hostname", early_hostname);
    54	

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp