linux-kernel - Re: [PATCH v2] utsname: contribute changes to RNG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202209270724.04D0A68@keescook>
Date:   Tue, 27 Sep 2022 07:25:26 -0700
From:   Kees Cook <keescook@...omium.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dominik Brodowski <linux@...inikbrodowski.net>
Subject: Re: [PATCH v2] utsname: contribute changes to RNG

On Tue, Sep 27, 2022 at 11:53:54AM +0200, Jason A. Donenfeld wrote:
> On some small machines with little entropy, a quasi-unique hostname is
> sometimes a relevant factor. I've seen, for example, 8 character
> alpha-numeric serial numbers. In addition, the time at which the hostname
> is set is usually a decent measurement of how long early boot took. So,
> call add_device_randomness() on new hostnames, which feeds its arguments
> to the RNG in addition to a fresh cycle counter.
> 
> Low cost hooks like this never hurt and can only ever help, and since
> this costs basically nothing for an operation that is never a fast path,
> this is an overall easy win.
> 
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Dominik Brodowski <linux@...inikbrodowski.net>
> Signed-off-by: Jason A. Donenfeld <Jason@...c4.com>
> ---
>  kernel/sys.c            | 2 ++
>  kernel/utsname_sysctl.c | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/kernel/sys.c b/kernel/sys.c
> index b911fa6d81ab..b4b40ccf0949 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -25,6 +25,7 @@
>  #include <linux/times.h>
>  #include <linux/posix-timers.h>
>  #include <linux/security.h>
> +#include <linux/random.h>
>  #include <linux/suspend.h>
>  #include <linux/tty.h>
>  #include <linux/signal.h>
> @@ -1366,6 +1367,7 @@ SYSCALL_DEFINE2(sethostname, char __user *, name, int, len)
>  	if (!copy_from_user(tmp, name, len)) {
>  		struct new_utsname *u;
>  
> +		add_device_randomness(tmp, len);
>  		down_write(&uts_sem);
>  		u = utsname();
>  		memcpy(u->nodename, tmp, len);
> diff --git a/kernel/utsname_sysctl.c b/kernel/utsname_sysctl.c
> index 4ca61d49885b..de16bcf14b03 100644
> --- a/kernel/utsname_sysctl.c
> +++ b/kernel/utsname_sysctl.c
> @@ -8,6 +8,7 @@
>  #include <linux/export.h>
>  #include <linux/uts.h>
>  #include <linux/utsname.h>
> +#include <linux/random.h>
>  #include <linux/sysctl.h>
>  #include <linux/wait.h>
>  #include <linux/rwsem.h>
> @@ -57,6 +58,7 @@ static int proc_do_uts_string(struct ctl_table *table, int write,
>  		 * theoretically be incorrect if there are two parallel writes
>  		 * at non-zero offsets to the same sysctl.
>  		 */
> +		add_device_randomness(tmp_data, sizeof(tmp_data));

Does this matter that we're dumping the same same trailing bytes into
the RNG? (i.e. only min(lenp, table->maxlen) has changed.)

If that's okay (and maybe a comment should be added):

Reviewed-by: Kees Cook <keescook@...omium.org>


>  		down_write(&uts_sem);
>  		memcpy(get_uts(table), tmp_data, sizeof(tmp_data));
>  		up_write(&uts_sem);
> -- 
> 2.37.3
> 

-- 
Kees Cook