[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#247054: Crypto-root patch updated to initrd-tools 0.1.70



On Mon, Nov 29, 2004 at 07:26:57PM +0100, Loïc Minier wrote:
> "Wesley W. Terpstra" <terpstra@gkec.tu-darmstadt.de> - Mon, Nov 29, 2004:
> > Ahhh, yes. This setting up of swap in mkinitrd should probably just be
> > turned off. It used to work with 'swsusp', but that is no longer in debian
> > kernels. So, why configure swap at all?
> 
>  It's not a point of using swsusp, I believe all dm keys should be saved
>  by the kernel in the swap area too -- it is kernel data after all --
>  and the reboot itself should be protected, either at the bootloader
>  level, at the initrd level (doesn't seem easy to me), or at the kernel
>  level (isn't easy either).

I'm afraid you've misunderstood how this is supposed to work.
There is no security risk if swap is not setup by mkinitrd as I proposed.
Also, the current mkinitrd already does 'protect the reboot'.

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. 

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.

>  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.

However, the kernels in debian no longer include this support.

If a person builds their own kernel, they probabl won't need an initrd.
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)

>  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.

-- 
Wesley W. Terpstra



Reply to: