Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #77712 > unrolled thread

Bug#778849: Support restoring initrd on shutdown and pivoting into it

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#778849: Support restoring initrd on shutdown and pivoting into it Gervase <gervase@group.force9.co.uk> - 2022-12-24 15:30 +0100
    Bug#778849: Support restoring initrd on shutdown and pivoting into it Gervase <gervase@group.force9.co.uk> - 2023-01-10 23:50 +0100
    Bug#778849: Support restoring initrd on shutdown and pivoting into it Gervase <gervase@group.force9.co.uk> - 2023-01-11 01:30 +0100
      Bug#778849: Support restoring initrd on shutdown and pivoting into it Gervase <gervase@group.force9.co.uk> - 2023-03-19 03:30 +0100
      Bug#778849: Support restoring initrd on shutdown and pivoting into it "Trent W. Buck" <trentbuck@gmail.com> - 2023-09-18 10:10 +0200

#77712 — Bug#778849: Support restoring initrd on shutdown and pivoting into it

Hi Joseph.

The last paragraph of this e-mail is specifically addressed to you, but
most of this e-mail is addressed generally.

Also, apologies if this message is a bit rushed.  I have a few things to
do today.

> I have yet to investigate intrigeri's suggestions from 2017,

I was planning to try out intrigeri's solution on a VM but have not had
the chance to do this.

> however I would suggest that this is something that needs to be
> upgraded from wishlist in 2022, and here's the reason simply enough:
> 
> root@aki:~# nvme smart-log /dev/nvme0
> Smart Log for NVME device:nvme0 namespace-id:ffffffff
> [..]
> unsafe_shutdowns			: 106
> [..]
> num_err_log_entries			: 284
> [..]
> root@aki:~# nvme smart-log /dev/nvme1
> Smart Log for NVME device:nvme1 namespace-id:ffffffff
> [..]
> unsafe_shutdowns			: 121
> [..]
> num_err_log_entries			: 291
> [..]

I agree that this should be higher than wishlist for the above reason
plus Lukas's ZFS shutdown problem mentioned in the initial
description/submission of this bug.

This really should be fixed for Bookworm.

Awhile back, I did have a look around the fix.  From what I remembered,
intrigeri's solution used a systemd shutdown 'script' to check for
devmaps or whatever of LVMs, ZFS partitions, etc... and runs specific
commands to umount the partitions.

However, I think my memory may be bad because I "now" don't see evidence
of such umounts in intrigeri's solution!

I would like to try things out today but maybe too rushed.

Jo, have you been able to try out intrigeri's solution (in GENERAL as
opposed to his specific patch/fix, which is mentioned in this bug report
and may have bits missing)?  The reason I say this is because you would
have the exact recreation steps and be able to do it easily.  For me, it
would be a shot in the dark or awkward for me to recreate.  I would only
be able to check that root LVM on LUKS would not cause any untoward
problems.

Thanks,
Gervase.

[toc] | [next] | [standalone]

#77880

Just in case it is not obvious (I did not see it until I toggled
"useless messages"!)...

This Bug#778849 (Severity: wishlist) blocks Bug#978642 [Wipe LUKS Disk
Encryption Key for Root Disk from RAM during Shutdown to defeat Cold
Boot Attacks from Initial Ramdisk (initramfs-tools or dracut)].

[toc] | [prev] | [next] | [standalone]

#77881

On Sat, 2022-12-24 at 14:16 +0000, Gervase wrote:
> Awhile back, I did have a look around the fix.  From what I
> remembered,
> intrigeri's solution used a systemd shutdown 'script' to check for
> devmaps or whatever of LVMs, ZFS partitions, etc... and runs specific
> commands to umount the partitions.

Apparently, I got confused.  What I saw is the script called 'shutdown'
from the mkinitcpio package used in Arch Linux (see 
https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/blob/master/shutdown
).

What it does is (1) recursively umount the devices, (2) detaches loop
back devices and then (3) disassembles stacked devices (i.e. encrypted
devices, lvm and raid).

In contrast, what intrigeri's solution SEEMS to do (I haven't done any
experimentation using the solution) is provide a way for Debian's initrd
process to "pivot" back to a systemd shutdown procedure within an
initramfs environment, as opposed to running the Arch Linux shutdown
script.  This shutdown procedure differs from Arch Linux's because its
initramfs infrastructure differs from Debian's, I assume?

As intrigeri wrote in his instructions, the relevant scripts would need
to be written for dismantling devices ('virtual' or physical) and placed
in /usr/share/initramfs-tools/hooks/* (if I understood things
correctly).  So, if ZFS was installed as root, there would need to be a
script for that and/or if LUKS was installed as root, there would need
to be a script for that, etc...

The way that intrigeri's solution sets up the shutdown executable by
just copying it to initramfs seems very clunky to me.  Shouldn't it be
in the initramfs image file already even before the system is switched
on/booted up!?

Anyway, the above is my understanding of the situation.  It may be
completely wrong because I barely understand the initrd process!

Thanks,
Gervase.

[toc] | [prev] | [next] | [standalone]

#78546

The following initrd info may or may not be pertinent to this bug in
respect to how initrds may be created in future versions of Debian...

>     To: debian-devel@lists.debian.org
>     Cc: debian-devel@lists.debian.org
>     Subject: Re: Unlock LUKS with login/password
>     From: Marco d'Itri <md@Linux.IT>
>     Date: Fri, 10 Mar 2023 17:57:40 +0100

> On Mar 10, Stephan Verbücheln <verbuecheln@posteo.de> wrote:
> 
> > On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote:
> > > In the future the initramfs will (usually) be static as well.
> > Can you provide more information on that?
> Due to multiple reasons, mostly related to secure boot and boot 
> attestation, there is significant interest by distributions in
> providing 
> static and signed initrds.
> BTW, I have been informed that "initramfs" is an obsolete term and
> that 
> we are back to "initrd" like in the '90s.
> 
> Some people in Debian are interested in working on 
> https://github.com/systemd/mkosi-initrd, which will provide a static 
> initrd built from system binaries and extensible using the 
> systemd-sysext and future systemd-sysconf mechanisms for things like 
> SAN boot or sshd in the initrd.
> Do not look too hard at it at this point: the upstream developers are 
> going to make soon a new release with significant changes.
> 
> I expect that people interested in working on initramfs-tools can 
> probably extend it with little work to generate static images
> suitable 
> for the most common deployments.
> People with uncommon ones will have to do without the modern boot 
> attestation features or else sign their own images (which will be
> very 
> easy once I, or somebody else, will have packaged sbctl).
> Obviously there are no new requirements for the systems without
> secure 
> boot.
> 
> -- 
> ciao,
> Marco
> 

[toc] | [prev] | [next] | [standalone]

#80473

On Wed 11 Jan 2023 00:17:44 +0000, Gervase wrote:
> On Sat, 2022-12-24 at 14:16 +0000, Gervase wrote:
> > Awhile back, I did have a look around the fix.  From what I
> > remembered,
> > intrigeri's solution used a systemd shutdown 'script' to check for
> > devmaps or whatever of LVMs, ZFS partitions, etc... and runs specific
> > commands to umount the partitions.
> 
> Apparently, I got confused.  What I saw is the script called 'shutdown'
> from the mkinitcpio package used in Arch Linux (see 
> https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/blob/master/shutdown
> ).
> 
> What it does is (1) recursively umount the devices, (2) detaches loop
> back devices and then (3) disassembles stacked devices (i.e. encrypted
> devices, lvm and raid).
> 
> In contrast, what intrigeri's solution SEEMS to do (I haven't done any
> experimentation using the solution) is provide a way for Debian's initrd
> process to "pivot" back to a systemd shutdown procedure within an
> initramfs environment, as opposed to running the Arch Linux shutdown
> script.  This shutdown procedure differs from Arch Linux's because its
> initramfs infrastructure differs from Debian's, I assume?

It does final umount/swapoff &c:

    https://github.com/systemd/systemd/blob/v252/src/shutdown/shutdown.c#L422

i.e. it's similar to arch's script, except it's 1) C code; 2) distro-agnostic; and 3) a bit feature-limited.

I think if you want it to run arbitrary other commands (e.g. "zpool export -a"), you would need more code.

I think for that you'd want systemdize /run/initramfs/shutdown
(i.e. be a copy of systemd's /bin/init), and then run some subset of
https://github.com/systemd/systemd/blob/v252/man/bootup.xml#L291-L330

Note that systemd can "be" the boot initrd, too, which is the previous flow chart:
https://github.com/systemd/systemd/blob/v252/man/bootup.xml#L236-L288

AFAIK Debian initramfs-tools doesn't support this at all.
AFAIK ArchLinux supports this, but it is opt in (off by default).

Last time I looked (around Debian 10),
Debian dracut theoretically supported putting systemd in charge of boot initrd (and shutdown initrd?), BUT
it also installed a zillion bits of coreutils that systemd itself doesn't use.
Since my goal was to REDUCE the attack surface of the boot initrd, I gave up on dracut at the time.

> As intrigeri wrote in his instructions, the relevant scripts would need
> to be written for dismantling devices ('virtual' or physical) and placed
> in /usr/share/initramfs-tools/hooks/* (if I understood things
> correctly).  So, if ZFS was installed as root, there would need to be a
> script for that and/or if LUKS was installed as root, there would need
> to be a script for that, etc...

I think it'd be better if /run/initramfs/shutdown used existing code -- either
/lib/systemd/systemd-shutdown/*.shutdown, or
maybe .service units, if that's appropriate.

But I confess I still do not understand how a "pure systemd" boot initrd + shutdown initrd would actually look.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web