linux-kernel - how to (really) cleanly shutdown the system when root is on multiple stacked block devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1277552682.29791.23.camel@fermat.scientia.net>
Date:	Sat, 26 Jun 2010 13:44:42 +0200
From:	Christoph Anton Mitterer <calestyo@...entia.net>
To:	linux-kernel@...r.kernel.org
Subject: how to (really) cleanly shutdown the system when root is on
 multiple stacked block devices

Hi.

I'm currently investigating in Debian's boot process with the goal to
allow having the root-fs on perhaps even multiple stacked block devices
(e.g. something like disk->md/raid->lvm2->dm-crypt->fs or
disk->md/raid->dm-crypt->lvm2->fs).

For booting this works in principle quite fine via initramfs images
(although it's currently yet very configurable and has a quite fixed
order of the block devices)..

I stumbled however across a problem for the shutdown/reboot:
What Debian does about is the following (via sysvinit 0 or 6):
1. cryptdisks stop
2. lvm2 stop
3. umountroot
4. halt/reboot

That 1 and 2 are before 3 is (I guess) because they simply don't expect
root-fs to be on the stacked block devices, and want to cleanly close
everything else, before umounting the root-fs

Step 3 is actually a remount,ro of / ... followed by the halt/reboot...
and I guess there is no other way to do this (e.g. doing a real umount).

I guess it's quite obvious, that if the root-fs is e.g. on top of lvm
and/or dm-crypt,... closing of some LV/VG/dm-crypt-devices will fail
(which is what I see and why I wrote here).

Now my question:
Is it strictly guaranteed, that when the mount -o remount,ro / in
umountroot returns,... everything that the filesystem flushed out,...
has already went down throught all the different block layers to the
disk?

I could imagine that future block layers to some caching, or that
encryption at dm-crypt takes some CPU time,... so if the mount would
return before everything gone through all layers,... the halt/reboot
would come "immediately" next... and the date would be gone without
being cleanly flushed.

Now I guess with a filesystem having barriers... it's secure, right? But
what about filesystem not having them?

So I think in the end my question is:
Is it by design secured, that I do _NOT_ cleanly disable any (possible
stacked block layers like lvm/md/dm-crypt/etc), when halting/rebooting
the system and when I do an remount,ro in the end.

Thanks,
Chris.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/