> it is necessarily something that would live in the filesystem, independent of the kernel.
Counterexample: struct utsname and the uname system call.
That's a good counterpoint.
It would still have to live somewhere in the filesystem, and have a userspace program load it in to the kernel, just as `utsname.nodename` is loaded from /etc/hostname.
Yes; that area of the filesystem can be readable only to root. It could also have other avenues of entry: it could come from the boot firmware via the kernel command line, or be in a device tree blob or whatever.
Because the machine-id is intended to be something that persists between reboots, it is necessarily something that would live in the filesystem, independent of the kernel.
Your described functionality could be accomplished with a FUSE filesystem, though.
However, that functionality would be problematic. Programs (like D-Bus) expect to be able to use it to identify whether 2 communicating processes are on the same host.
If it served different bullshit to each process, it would be entirely non-functional. (Sans returning the true ID to root, this is /proc/sys/kernel/random/uuid)
Perhaps instead, use a determined-at-boot value (as the machine-id(5) docs say is acceptable for stateless systems). If this is a kernel construct that isn't associated with a specific (PID?) namespace, then this would also be problematic, as different containers would be considered to be the same "host". (Sans returning the true ID to root, this is /proc/sys/kernel/random/boot_id)