1
0
mirror of https://github.com/systemd/systemd synced 2025-10-06 00:13:24 +02:00

4 Commits

Author SHA1 Message Date
Lennart Poettering
1c9500c2b7 units: explicitly reset TTY before running stuff on console
This adds TTYReset=yes to all units which run directly on the TTY. We
already had this in place for the gettys, but this adds it for the rest
that basically has StandardInput=tty + StandardOutput=tty set.

Originally, for these tools it wasn't necessary to reset the TTY,
because we after all already reset /dev/console very very early on once,
during PID1's early initialization, and hence there's no real reason to
do it again for these early boot services. But that's actually not
right, because since #36666 the TTY we reset from PID 1 is typically
/dev/console but the TTY those services are invoked on is typically the
resolved version of that, i.e. wherever that points. Now you might
think: if one is just an alias to the other, why does it matter to reset
this again? Well, because it's only a half-assed alias, and as it turns
out WIOCSWINSZ is not propagated from one to the other, i.e the terminal
dimesions we initialize for /dev/console don't propagate to whatever
that points to.

One option to address that would be to immediately propagate this down
ourselves (or to fix the kernel for it), but it felt safer to simply do
the reset again before the use, after all these one one-off services,
and there's no point in optimizing much here. Moreover, its probably
safer to give the guarantee that when the firstboot stuff (which after
all queries for pws to set) runs it definitely certainly guaranteed has
a properly reset terminal.
2025-09-18 21:30:31 +02:00
Lennart Poettering
b493502475 units: measure the fact we enter storage target mode into TPM
storagetm mode means we we are network accessible. let's lock down
access to TPM secrets in this case: let's measure a pcr "phase" string
into PCR 11.

This is good as it means that if we are exploited in this state FDE
secrets protected by TPM are likely to remain protected, since the PCR
values wouldn't allow access.
2025-02-27 13:20:23 +01:00
Lennart Poettering
4134f47de2 units: pull in plymouth when booting into storagetm mode 2023-11-13 15:45:16 +01:00
Lennart Poettering
1761066b13 storagetm: add new systemd-storagetm component
This implements a "storage target mode", similar to what MacOS provides
since a long time as "Target Disk Mode":

        https://en.wikipedia.org/wiki/Target_Disk_Mode

This implementation is relatively simple:

1. a new generic target "storage-target-mode.target" is added, which
   when booted into defines the target mode.

2. a small tool and service "systemd-storagetm.service" is added which
   exposes a specific device or all devices as NVMe-TCP devices over the
   network.  NVMe-TCP appears to be hot shit right now how to expose
   block devices over the network. And it's really simple to set up via
   configs, hence our code is relatively short and neat.

The idea is that systemd-storagetm.target can be extended sooner or
later, for example to expose block devices also as USB mass storage
devices and similar, in case the system has "dual mode" USB controller
that can also work as device, not just as host. (And people could also
plug in sharing as NBD, iSCSI, whatever they want.)

How to use this? Boot into your system with a kernel cmdline of
"rd.systemd.unit=storage-target-mode.target ip=link-local", and you'll see on
screen the precise "nvme connect" command line to make the relevant
block devices available locally on some other machine. This all requires
that the target mode stuff is included in the initrd of course. And the
system will the stay in the initrd forever.

Why bother? Primarily three use-cases:

1. Debug a broken system: with very few dependencies during boot get
   access to the raw block device of a broken machine.

2. Migrate from system to another system, by dd'ing the old to the new
   directly.

3. Installing an OS remotely on some device (for example via Thunderbolt
   networking)

(And there might be more, for example the ability to boot from a
laptop's disk on another system)

Limitations:

1. There's no authentication/encryption. Hence: use this on local links
   only.

2. NVMe target mode on Linux supports r/w operation only. Ideally, we'd
   have a read-only mode, for security reasons, and default to it.

Future love:

1. We should have another mode, where we simply expose the homed LUKS
   home dirs like that.

2. Some lightweight hookup with plymouth, to display a (shortened)
   version of the info we write to the console.

To test all this, just run:

    mkosi --kernel-command-line-extra="rd.systemd.unit=storage-target-mode.target" qemu
2023-11-02 14:19:32 +01:00