From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] random: Expose boot ID to other subsystems
Date: Mon, 22 Jun 2026 13:52:20 +0900 [thread overview]
Message-ID: <20260622135220.6cdf5647df9540f95b5a5e9d@kernel.org> (raw)
In-Reply-To: <aiw8OIRYMjWZYhvV@zx2c4.com>
On Fri, 12 Jun 2026 19:04:56 +0200
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
> On Thu, May 21, 2026 at 11:57:09PM +0900, Masami Hiramatsu (Google) wrote:
> > From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> >
> > Add get_boot_id() to expose current boot ID to other kernel subsystems.
> > Note that since this is only meaningful if user can access it via sysctl,
> > it returns NULL if CONFIG_SYSCTL=n.
>
> Wouldn't this be nice to have even on !SYSCTL systems? Why disable it for this
> case?
Unless user reads and records the boot_id, it is just a random number.
Thus it must be exposed to user space.
Anyway, this does not work as I expected, because to generate really
useful random number, user needs to ensure that enough entropy is
collected. If any component uses this from early boot or boot time,
we will generate less unique number.
Thanks,
>
> > +/**
> > + * get_boot_id - return the boot ID UUID
> > + *
> > + * This function returns a pointer to the boot ID UUID, which is generated on
> > + * demand the first time this function is called. The boot ID is a UUID that
> > + * is unique to each boot of the system.
> > + */
> > +const u8 *get_boot_id(void)
> > +{
> > + static DEFINE_SPINLOCK(bootid_spinlock);
> > +
> > + spin_lock(&bootid_spinlock);
> > + if (!sysctl_bootid[8])
> > + generate_random_uuid(sysctl_bootid);
> > + spin_unlock(&bootid_spinlock);
> > +
> > + return sysctl_bootid;
> > +}
> > +
> > /*
> > * This function is used to return both the bootid UUID, and random
> > * UUID. The difference is in whether table->data is NULL; if it is,
> > @@ -1638,12 +1657,8 @@ static int proc_do_uuid(const struct ctl_table *table, int write, void *buf,
> > uuid = tmp_uuid;
> > generate_random_uuid(uuid);
> > } else {
> > - static DEFINE_SPINLOCK(bootid_spinlock);
> > -
> > - spin_lock(&bootid_spinlock);
> > - if (!uuid[8])
> > - generate_random_uuid(uuid);
> > - spin_unlock(&bootid_spinlock);
> > + /* Ensure that the boot ID is initialized. */
> > + get_boot_id();
>
> I find this a little odd, this implicit behavior now that sysctl_bootid ==
> uuid. But perhaps that's the cleanest approach there is?
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2026-06-22 4:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-21 14:56 [RFC PATCH 0/2] random: tracing: Expose last boot ID on persistent instance Masami Hiramatsu (Google)
2026-05-21 14:57 ` [RFC PATCH 1/2] random: Expose boot ID to other subsystems Masami Hiramatsu (Google)
2026-06-12 17:04 ` Jason A. Donenfeld
2026-06-22 4:52 ` Masami Hiramatsu [this message]
2026-05-21 14:57 ` [RFC PATCH 2/2] tracing: Record and show boot ID in last_boot_info Masami Hiramatsu (Google)
2026-05-21 15:16 ` Steven Rostedt
2026-05-24 1:44 ` Masami Hiramatsu
2026-05-28 20:36 ` Steven Rostedt
2026-06-01 4:38 ` Masami Hiramatsu
2026-05-21 14:59 ` [RFC PATCH 0/2] random: tracing: Expose last boot ID on persistent instance Mathieu Desnoyers
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=20260622135220.6cdf5647df9540f95b5a5e9d@kernel.org \
--to=mhiramat@kernel.org \
--cc=Jason@zx2c4.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=rostedt@goodmis.org \
--cc=tytso@mit.edu \
/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