From: Sascha Hauer <s.hauer@pengutronix.de>
To: Bastian Krause <bst@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH v2 2/3] common: machine_id: introduce machine id generation and pass id on
Date: Mon, 5 Aug 2019 12:08:31 +0200 [thread overview]
Message-ID: <20190805100831.e6z4clrvhy2xzvo5@pengutronix.de> (raw)
In-Reply-To: <20190719105534.30276-2-bst@pengutronix.de>
On Fri, Jul 19, 2019 at 12:55:33PM +0200, Bastian Krause wrote:
> By default systemd generates a machine id on first boot and tries to
> persist it (see `man machine-id`). When the root file system is read-only
> systemd cannot persist the machine id. In case multiple redundant slots
> are used the machine id will vary. When not handled explicitly the
> machine id will also change during updates.
>
> It is possible to pass a machine id to the kernel which will be used by
> systemd (systemd.machine_id=).
>
> This adds functionality to pass device-specific information that will be
> hashed to generate a persistent unique machine id. The machine id will
> be finally added to the kernel parameters via the
> linux.bootargs.machine_id global variable.
>
> Note: if multiple sources provide hashable device-specific information
> (via machine_id_set_hashable()) the information provided by the last call
> prior to the late initcall set_machine_id() is used to generate the
> machine id from. Thus when updating barebox the machine id might change.
>
> Signed-off-by: Bastian Krause <bst@pengutronix.de>
> ---
> Changes since (implicit) v1:
> - depend on SHA1 instead of selecting DIGEST/DIGEST_SHA1_GENERIC
> - add note about multiple sources providing hashables to kconfig
> - add note about no hashable provided to kconfig
> - remove warning about "no hashable info provided" along with pr_fmt
> - make machine_id_set_hashable()'s hashable parameter const
> - make a copy of the hashable provided rather than storing the pointer
> - hash data instead of pointer address
> - use basprintf() and dedicated variables for hex machine id/machine id
> bootarg
> - add static inline wrapper if CONFIG_MACHINE_ID is disabled
> ---
> common/Kconfig | 18 +++++++++++++
> common/Makefile | 1 +
> common/machine_id.c | 63 ++++++++++++++++++++++++++++++++++++++++++++
> include/machine_id.h | 16 +++++++++++
> 4 files changed, 98 insertions(+)
> create mode 100644 common/machine_id.c
> create mode 100644 include/machine_id.h
>
> diff --git a/common/Kconfig b/common/Kconfig
> index 8aad5baecd..7be2487a20 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -982,6 +982,24 @@ config RESET_SOURCE
> of the reset and why the bootloader is currently running. It can be
> useful for any kind of system recovery or repair.
>
> +config MACHINE_ID
> + bool "pass machine-id to kernel"
> + depends on FLEXIBLE_BOOTARGS
> + depends on SHA1
> + help
> + Sets the linux.bootargs.machine_id global variable with a value of
> + systemd.machine_id=UID. The UID is a persistent device-specific
> + id. It is a hash over device-specific information provided by various
> + sources.
> +
> + Note: if multiple sources provide hashable device-specific information
> + (via machine_id_set_hashable()) the information provided by the last call
> + prior to the late initcall set_machine_id() is used to generate the
> + machine id from. Thus when updating barebox the machine id might change.
> +
> + Note: if no hashable information is available no machine id will be passed
> + to the kernel.
We'll need some additional runtime control knob whether this behaviour
should be used or not. Just enabling a Kconfig option shouldn't change the
behaviour of barebox. A boolean global.linux.provide_machine_id flag
should do it.
Also it would be nice to provide the machine-id to barebox aswell, maybe
in global.machine_id.
Overall we then get this:
- set global.machine_id during barebox startup (inicalls)
- User can overwrite it with nv.machine_id if necessary
- during booting of Linux global.linux.bootargs.machine_id is
initialized with the value of global.machine_id if desired (based on
global.linux.provide_machine_id)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2019-08-05 10:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 10:55 [PATCH v2 1/3] digest.h: needs errno definitions Bastian Krause
2019-07-19 10:55 ` [PATCH v2 2/3] common: machine_id: introduce machine id generation and pass id on Bastian Krause
2019-08-05 10:08 ` Sascha Hauer [this message]
2019-07-19 10:55 ` [PATCH v2 3/3] nvmem: ocotp: set unique id as machine-id hashable Bastian Krause
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=20190805100831.e6z4clrvhy2xzvo5@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=bst@pengutronix.de \
/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