[systemd-devel] How to show cylon animation on purpose?
Hi list, Is it possible to create a startup service which triggers cylon animation? I see that the animation is related to running jobs. Sometimes I see it when shutting down. I'm curious if it can be triggered on purpose. Thanks.
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi, On Tue, Feb 20, 2024 at 02:35:27PM +0100, Lennart Poettering wrote: > On Di, 20.02.24 10:24, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > > > Thanks, I will check this. It sounds like optee needs a similar dependency > > generator. > > > > I wonder how many kernel subsystems/drivers which need userspace daemons > > would need systemd side dependency generators. Is it only the ones inside > > initramfs and/or pre-rootfs mount which need special handling? > > Well, systemd to a large part is about getting deps in order, > i.e. start things in the right order but still as parallelized as > possible to make sure we can boot properly, fast. > > For regular (i.e. late boot) services things are easier, since we can > hide various deps via socket activation and services typically just > have fewer deps, but during early boot things always require careful > consideration on what you need to schedulen when. That's hardly > surprising, isn't it? > > TPM stuff in particular is stuff that we want to make use of super > early, because it's inherently part of the boot process to measure > progress and resources we are using. It's what "Measured Boot" after > all means. And that means you need to know what you do, and can't > really escape that. > > > In the end the logic is quite straight forward. If kernel side support is > > there, then a daemon needs to be started before user service start, but > > boot should continue without if kernel support is not detected. > > systemd generators are our way to allow dynamic extension of the > systemd unit dependency graph. It's the fact that you want things > dynamic (i.e. responsive to the fact whether your system has a > specific kind of tpm device/secure enclave) that means you have to do > with a generator. Thanks for the explanation. This issue is clearer now. I'll check into TPM2 generator backport and adding an optee generator. Got distracted by a regression in latest u-boot version (and/or tf-a) while debugging this... Cheers, -Mikko
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
On Di, 20.02.24 10:24, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > Thanks, I will check this. It sounds like optee needs a similar dependency > generator. > > I wonder how many kernel subsystems/drivers which need userspace daemons > would need systemd side dependency generators. Is it only the ones inside > initramfs and/or pre-rootfs mount which need special handling? Well, systemd to a large part is about getting deps in order, i.e. start things in the right order but still as parallelized as possible to make sure we can boot properly, fast. For regular (i.e. late boot) services things are easier, since we can hide various deps via socket activation and services typically just have fewer deps, but during early boot things always require careful consideration on what you need to schedulen when. That's hardly surprising, isn't it? TPM stuff in particular is stuff that we want to make use of super early, because it's inherently part of the boot process to measure progress and resources we are using. It's what "Measured Boot" after all means. And that means you need to know what you do, and can't really escape that. > In the end the logic is quite straight forward. If kernel side support is > there, then a daemon needs to be started before user service start, but > boot should continue without if kernel support is not detected. systemd generators are our way to allow dynamic extension of the systemd unit dependency graph. It's the fact that you want things dynamic (i.e. responsive to the fact whether your system has a specific kind of tpm device/secure enclave) that means you have to do with a generator. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi,
On Mon, Feb 19, 2024 at 01:54:02PM +0300, Andrei Borzenkov wrote:
> On Mon, Feb 19, 2024 at 11:37 AM Mikko Rapeli wrote:
> >
> > Hi,
> >
> > On Fri, Feb 16, 2024 at 11:28:31AM +0200, Mikko Rapeli wrote:
> > > Hi,
> > >
> > > Following up to my previous question which worked around with
> > > Wants: and After: to dev-tpmrm0.device and
> > > tee-supplicant@teepriv0.service,
> > > which don't seem to work fully.
> > >
> > > In short, I want to support devices with and without TPM. The TPM device
> > > can also be a firmware fTPM device which depends on tee-supplicant in
> > > userspace
> > > for RPMB storage.
> > >
> > > If TPM device is found, systemd repart in initramfs will create an
> > > encrypted rootfs
> > > and if not a plaintext ext4 partition.
> > >
> > > Support for TPM devices is ok and drivers are built into kernel. systemd
> > > repart config
> > > for rootfs is:
> > >
> > > [Partition]
> > > Type=root
> > > Weight=100
> > > Format=ext4
> > > Encrypt=tpm2
> > > FactoryReset=yes
> > > MakeDirectories=/boot /usr /home /home/root
> > > # copying etc from build time /usr image
> > > CopyFiles=/usr/etc:/etc
> > >
> > > /usr partition generated at build time is dm-verity protected and contains
> > > /etc which is copied over to newly created rootfs.
> > >
> > > Support for fTPM devices is problematic. First, the kernel support must
> > > be modules
> > > but loading needs to be specially handled after starting tee-supplicant.
> > > For normal
> > > boot udev handles optee detection and triggers
> > > tee-supplicant@teepriv0.service
> > > startup which unloads tpm_ftpm_tee kernel module, starts tee-supplicant
> > > and then
> > > loads the kernel module again. After this RPMB works. To do the same in
> > > initramfs, I added
> > > Wants: and After: dependencies from systemd-repart.service,
> > > systemd-cryptsetup@.service,
> > > systemd-pcrmachine.service and systemd-pcrphase-initrd.service:
> > >
> > > After=dev-tpmrm0.device tee-supplicant@teepriv0.service
> > > Wants=dev-tpmrm0.device tee-supplicant@teepriv0.service
> >
> > I think my problems come from:
> >
> > After=tee-supplicant@teepriv0.service
> > Wants=tee-supplicant@teepriv0.service
> >
> > Basically tee-supplicant should only be started if /dev/teepriv* device node
> > is available. Then in my case with fTPM devices, all TPM using and encrypted
> > rootfs creating services need to depend on the service which starts
> > tee-supplicant
> > but only if /dev/teepriv0 exists. If teepriv0 doesn't exist, then
> > tee-supplicant
> > should not be started and the dependencies to it should not exist either.
> >
>
> The standard way to start a unit when a device becomes available is to
> set SYSTEMD_WANTS udev property for this device.
Yes this is set, but only to:
KERNEL=="teepriv[0-9]*", MODE="0660", OWNER="root", GROUP="teeclnt", \
TAG+="systemd", ENV{SYSTEMD_WANTS}+="tee-supplicant@%k.service"
Can I change the Wants: and Before: rules from udev rules?
After backporting patches for tpm2.target, this service would need to run
before tpm2.target completes.
> > How should this dependency be expressed in systemd services?
> >
> > Can tee-supplicant@.service include:
> >
> > Before=systemd-pcrphase-initrd.service systemd-pcrphase.service
> > systemd-pcrmachine.service
> > WantedBy=systemd-pcrphase-initrd.service systemd-pcrphase.service
> > systemd-pcrmachine.service
> >
>
> If those service has to be started only if tee-supplicant is also
> started, this is backward. tee-supplicant@ needs to pull in these
> services, not another way round.
Yes, this is backwards because I'm trying to make optee support optional.
Lennart suggest using the dependency generators like for TPM2 devices.
Hardcoding the dependencies from systemd-pcrphase.service etc to
tee-supplicant@teepriv0.service currently works but only for devices
with optee.
Cheers,
-Mikko
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi, On Mon, Feb 19, 2024 at 11:53:14AM +0100, Lennart Poettering wrote: > On Mo, 19.02.24 10:36, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > > > > After=dev-tpmrm0.device tee-supplicant@teepriv0.service > > > Wants=dev-tpmrm0.device tee-supplicant@teepriv0.service > > > > I think my problems come from: > > > > After=tee-supplicant@teepriv0.service > > Wants=tee-supplicant@teepriv0.service > > > > Basically tee-supplicant should only be started if /dev/teepriv* device node > > is available. Then in my case with fTPM devices, all TPM using and encrypted > > rootfs creating services need to depend on the service which starts > > tee-supplicant > > but only if /dev/teepriv0 exists. If teepriv0 doesn't exist, then > > tee-supplicant > > should not be started and the dependencies to it should not exist > > either. > > Is /dev/teepriv* guaranteed to be available when userspace is invoked? > or is it something that itself requires some kmod loading to show up, > i.e. that "udevadm trigger" causes to load? At the moment yes, but I think supporting tee drivers as modules is also a good idea. > > How should this dependency be expressed in systemd services? > > > > Can tee-supplicant@.service include: > > > > Before=systemd-pcrphase-initrd.service systemd-pcrphase.service > > systemd-pcrmachine.service > > WantedBy=systemd-pcrphase-initrd.service systemd-pcrphase.service > > systemd-pcrmachine.service > > > > In my testing this does not seem to work inside initramfs. > > > > If systemd-pcrphase-initrd.service systemd-pcrphase.service and > > systemd-pcrmachine.service > > service have After= and Wants= to tee-supplicant@teepriv0.service then > > things work, > > except on boards which have no optee and no /dev/teepriv0 where > > tee-supplicant seems > > be started and fails due to missing optee which breaks the initramfs boot. > > For your usecase the new tpm2.target available in git main is what you > really should focus on: all TPM using services should order themselves > after that. All stuff needed to make a TPM device appear should be > placed before that. > > The systemd-tpm2-generator that now exists in git main analyzes the > uefi/acpi firmware situation and automatically adds a dev-tpm0.device > dependency on tpm2.target if it comes to the conclusion that such a > device will show up. This generator is not going to cover your > specific case, but I think it would be a good blueprint for you: > i.e. write a generator that checks if /dev/teepriv* exists. If not, > just exit. If yes, generate the required deps to pull in > tee-supplicatnt@.service, and add the dev-tpmrm0.device dep just like > systemd-tpm2-generator does. Thanks, I will check this. It sounds like optee needs a similar dependency generator. I wonder how many kernel subsystems/drivers which need userspace daemons would need systemd side dependency generators. Is it only the ones inside initramfs and/or pre-rootfs mount which need special handling? In the end the logic is quite straight forward. If kernel side support is there, then a daemon needs to be started before user service start, but boot should continue without if kernel support is not detected. Cheers, -Mikko
Re: [systemd-devel] EXT: Re: What creates a new machine-id ?
Hello, Thanks for pointing that. It highlighted some other aspect of the problem, especially for KVM. Best regards, Patrick Agrain -Message d'origine- De : Lennart Poettering Envoyé : jeudi 8 février 2024 11:57 À : Agrain Patrick Cc : systemd-devel@lists.freedesktop.org Objet : EXT: Re: [systemd-devel] What creates a new machine-id ? ** External email - Please consider with caution ** On Do, 08.02.24 09:35, Agrain Patrick (patrick.agr...@al-enterprise.com) wrote: > Hello, > > Our embedded system is based on a Rocky Linux 8 distribution which embeds > systemd-239. > > At first bootup, a machine-id is created and remains persistent over the > following reboots. > System upgrade sometimes creates a new machine-id, sometimes not. > By 'system upgrade', I mean either new linux kernel or upgraded Rocky > packages or both. > > Could you precise me what event(s) in the previous upgrade cases > trigger a new machine-id ? See: https://www.freedesktop.org/software/systemd/man/latest/machine-id.html#Initialization Or in other words: the machine ID is supposed to be persisted in /etc/. if your upgrade procedure somehow causes the machine ID to be invalidated somehow, then we'll assign a new one though. We basically make sure that whatever happens, on boot we initialize it. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi, On Mon, Feb 19, 2024 at 11:47:52AM +0100, Lennart Poettering wrote: > On Fr, 16.02.24 11:28, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > > > Support for fTPM devices is problematic. First, the kernel support must be > > modules > > but loading needs to be specially handled after starting tee-supplicant. > > For normal > > boot udev handles optee detection and triggers > > tee-supplicant@teepriv0.service > > startup which unloads tpm_ftpm_tee kernel module, starts tee-supplicant and > > then > > loads the kernel module again. After this RPMB works. To do the same in > > initramfs, I added > > Wants: and After: dependencies from systemd-repart.service, > > systemd-cryptsetup@.service, > > systemd-pcrmachine.service and systemd-pcrphase-initrd.service: > > Kernel module unloading is not supposed to happen in clean > codepaths. It's a debug/development feature, it's not safe to do as > part of regular boot. > > But why do you need an unload a kernel module at all? that smells... Yes, I agree that this smells bad but it's the current optee/ftpm/kernel implementation which requires tee-supplicant in userspace to be running at module load time for RPMB to work. AFAIK there is some work on going to fix this and support RPMB directly from optee kernel drivers. Cheers, -Mikko
Re: [systemd-devel] Handle device node timeout?
Hi, On Mon, Feb 19, 2024 at 11:18:13AM +0100, Lennart Poettering wrote: > On Di, 16.01.24 16:06, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > > > Hi, > > > > I have services which depend on a specific device node. How can I run > > some recovery actions when the default 90s timeout for finding this > > device is hit? > > > > OnFailure= doesn't work as the service is not even started. > > > > Specifically the case is about supporting TPM2 encrypted rootfs but falling > > back to plain-text rootfs generation if there is no TPM2 device. Currently > > my initramfs works with TPM2 but without it fails with: > > In git main there's new infra to deal with this case: > > https://github.com/systemd/systemd/pull/30194 > > That should hopefully solve this systematically and generically. Thanks, I will try to port these patches to our systemd 254.4. Cheers, -Mikko
