Bug#247054: Crypto-root patch updated to initrd-tools 0.1.70
"Wesley W. Terpstra" <terpstra@gkec.tu-darmstadt.de> - Tue, Nov 30, 2004:
> I'm afraid you've misunderstood how this is supposed to work.
Wowow, I'm merely suggesting what I think needs changing regarding keys
restoration when ones suspend and reboots. I know this is not how it
works right now, and I explained why I think it's broken. As I said,
this is completely off-topic.
> There is no security risk if swap is not setup by mkinitrd as I proposed.
> Also, the current mkinitrd already does 'protect the reboot'.
I'm not wishing for encryped swap to be setup by mkinitrd, I'm merely
stating the obvious: I was asked for a password to decrypt my swap with
an initrd built with patched mkinitrd, and this should not happen. I'm
completely ok for having the swap setup later, from the real root.
> It is completely clear that you need encrypted swap if you are using
> encrypted root. However, there is no reason this needs to be configured
> before root is mounted. You are being prompted for a password because it is
> being configured by the initrd.
Yes, so my conclusion is "either the generated initrd is borken because
it asks for a password when it isn't needed or because it tries to
activate swap where it can't".
> There's no reason why encrypted swap can't be setup in the init.d/* scripts
> much later using a key stored on the root partition.
Yes, I agree with that.
> > Wouldn't it be a drawback for swsusp users if mkinitrd looses this?
> For 'swsusp' users, swap needs to be readable to restore the kernel's old
> state (root will not be mounted in this case). For this reason swap
> configuration was added to mkinitrd.
Yes, I understood that, and that's why I argued about removing swap
activation: it might break their setup. I'm not a swsusp user, but I
can imagine some people did rebuild their kernel with an initrd for
swsusp support (I personnally would take the Debian config as a start
for a new kernel with swsusp). If you remove support for swap in
initrd, I thought this could break their setup and require actions on
their side.
I do not say this should not be done, but I'm merely pointing the
obvious "please warn when breakin gthings" that needs to be told.
[ Please read on for further discussion. ]
> If a person builds their own kernel, they probabl won't need an initrd.
Sorry, I disagree here. I build all my kernels with initrd, there was
a time where indeed all modules I needed to reach root were hardcoded
in kernels I built, this isn't the case anymore.
> Furthermore, it is impossible to use swsusp + initrd with the stock kernels
> (without the obsolete debian patch) because the kernel does not have the
> opportunity to load the initrd prior to restoring it's state. (not modular)
So you're saying that, when resuming, the kernel never boots the
initrd, and as such must be able to access the resume partition
directly, without an initrd setup of swap? (Again, I'm not an
swsusp-user, I'm trying to understand the way it is supposed to work).
If it the case, then I agree swap support can be safely removed from
initrds even for swsusp user.
Can you confirm this is how things happen?
> > I don't see how your setup permits chaining, that is the ability to
> > cascade a RAID 1 mapped device, with a crypted device, but we're
> > off-topic again.
> Since I run crpto over LVM over RAID 1, it certainly does work.
Please don't take everything I say as an attack. I see no mention of
the LVM volumes or of "RAID 1" in the fstab you quotted, the logical
question is "where is that configured". Is it
autoconfigured/autodetected like LVM physical volumes?
Regards,
--
Loïc Minier <lool@dooz.org>
Reply to: