[gentoo-user] Genkernel: non-standard crypto setup

[gentoo-user] Genkernel: non-standard crypto setup

[Jens Müller]

Hi,

how can I achieve the following with minimal manual intervention based
on genkernel's default linuxrc script?

1) Scan for physical volumes, setup volume groups (I guess that is what
"startVolumes" does).

2) Do (the equivalent of) cryptsetup luksOpen /dev/mapper/vg1-crypt
crypt_pv. First, with passphrase, later, key from USB would be nice.

3) Rescan for PVs (= recognize /dev/mapper/crypt_pv as a physical
volume), setup the new volume group contained therein.

4) Add rootfs and swap from /dev/mapper/vg2-root and /dev/mapper/vg2-swap

Thanks a lot & Bye,

Jens

Re: [gentoo-user] Genkernel: non-standard crypto setup

[Dirk Heinrichs]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

Am Freitag, 2. Januar 2009 18:50:09 schrieb Jens Müller:
> Hi,
>
> how can I achieve the following with minimal manual intervention based
> on genkernel's default linuxrc script?
>
> 1) Scan for physical volumes, setup volume groups (I guess that is what
> "startVolumes" does).
>
> 2) Do (the equivalent of) cryptsetup luksOpen /dev/mapper/vg1-crypt
> crypt_pv. First, with passphrase, later, key from USB would be nice.
>
> 3) Rescan for PVs (= recognize /dev/mapper/crypt_pv as a physical
> volume), setup the new volume group contained therein.
>
> 4) Add rootfs and swap from /dev/mapper/vg2-root and /dev/mapper/vg2-swap

Just to make sure I understand what you want to do: You have encrypted 
physical volumes which you want to combine into an LVM volume group and then 
put logical volumes into this VG?

Bye...

	Dirk

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: Genkernel: non-standard crypto setup

[Jens Müller]

Dirk Heinrichs schrieb:
> Just to make sure I understand what you want to do: You have encrypted 
> physical volumes which you want to combine into an LVM volume group and then 
> put logical volumes into this VG?

Raid part 1 \
Raid part 2 >- Raid5 -> /dev/md127 = PV1
Raid part 3 /

                      ...(possibly others)...
PV1 --LVM--> VG1 --->    LV1: \dev\mapper\vg1-crypt


LV1: \dev\mapper\vg1-crypt --cryptsetup--> \dev\mapper\crypt_pv

\dev\mapper\crypt_pv = PV2  --LVM--> VG1 ---> (all the partitions)

Basically, I have one encrypted "physical" volume, but I want to be
flexible ...

Re: [gentoo-user] Re: Genkernel: non-standard crypto setup

[Dirk Heinrichs]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

Am Freitag, 2. Januar 2009 19:36:28 schrieb Jens Müller:
> Dirk Heinrichs schrieb:
> > Just to make sure I understand what you want to do: You have encrypted
> > physical volumes which you want to combine into an LVM volume group and
> > then put logical volumes into this VG?
>
> Raid part 1 \
> Raid part 2 >- Raid5 -> /dev/md127 = PV1
> Raid part 3 /
>
>                       ...(possibly others)...
> PV1 --LVM--> VG1 --->    LV1: \dev\mapper\vg1-crypt
>
> LV1: \dev\mapper\vg1-crypt --cryptsetup--> \dev\mapper\crypt_pv
>
> \dev\mapper\crypt_pv = PV2  --LVM--> VG1 ---> (all the partitions)
>
> Basically, I have one encrypted "physical" volume, but I want to be
> flexible ...

If you have one encrypted PV from which you build a VG, then every LV inside 
it will automatically be encrypted. So where's the flexibility?

Means:

PV1 --cryptsetup--> PV1_crypt --vgcreate--> VG1 --lvcreate--> LVx

To be able to choose wether to encrypt each LV or not, you need to encrypt at 
LV level, like:

PV1 --vgcreate--> VG1 --lvcreate--> LVx --cryptsetup--> LVx_crypt

For the latter I have some scripts ready to create an initramfs which can be 
combined with the kernel (It's for EVMS, but it should be easy to adapt to 
LVM.

HTH...

	Dirk

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: Genkernel: non-standard crypto setup

[Jens Müller]

Dirk Heinrichs schrieb:
> Am Freitag, 2. Januar 2009 19:36:28 schrieb Jens Müller:
>> Dirk Heinrichs schrieb:
>>> Just to make sure I understand what you want to do: You have encrypted
>>> physical volumes which you want to combine into an LVM volume group and
>>> then put logical volumes into this VG?
>> Raid part 1 \
>> Raid part 2 >- Raid5 -> /dev/md127 = PV1
>> Raid part 3 /
>>
>>                       ...(possibly others)...
>> PV1 --LVM--> VG1 --->    LV1: \dev\mapper\vg1-crypt
>>
>> LV1: \dev\mapper\vg1-crypt --cryptsetup--> \dev\mapper\crypt_pv
>>
>> \dev\mapper\crypt_pv = PV2  --LVM--> VG1 ---> (all the partitions)
>>
>> Basically, I have one encrypted "physical" volume, but I want to be
>> flexible ...
> 
> If you have one encrypted PV from which you build a VG, then every LV inside 
> it will automatically be encrypted. So where's the flexibility?

I meant it's more flexible than encrypting /dev/md127 itself.

E.g., I can create a snapshot of an LV which is still encrypted.

> Means:
> 
> PV1 --cryptsetup--> PV1_crypt --vgcreate--> VG1 --lvcreate--> LVx
> 
> To be able to choose wether to encrypt each LV or not, you need to encrypt at 
> LV level, like:
> 
> PV1 --vgcreate--> VG1 --lvcreate--> LVx --cryptsetup--> LVx_crypt
> 
> For the latter I have some scripts ready to create an initramfs which can be 
> combined with the kernel (It's for EVMS, but it should be easy to adapt to 
> LVM.

Well, the genkernel default script can be given a "crypt_root", can load
the key from a USB device, etc. ...

Re: [gentoo-user] Re: Genkernel: non-standard crypto setup

[Daniel Troeder]

[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]

Am Freitag, den 02.01.2009, 20:03 +0100 schrieb Dirk Heinrichs:
> Am Freitag, 2. Januar 2009 19:36:28 schrieb Jens Müller:
> > Raid part 1 \
> > Raid part 2 >- Raid5 -> /dev/md127 = PV1
> > Raid part 3 /
> >
> >                       ...(possibly others)...
> > PV1 --LVM--> VG1 --->    LV1: \dev\mapper\vg1-crypt
> >
> > LV1: \dev\mapper\vg1-crypt --cryptsetup--> \dev\mapper\crypt_pv
> >
> > \dev\mapper\crypt_pv = PV2  --LVM--> VG1 ---> (all the partitions)
    ^^^^^^^^^^^^^^^^^ backslashes - hihi ;-)

> > Basically, I have one encrypted "physical" volume, but I want to be
> > flexible ...
> 
> If you have one encrypted PV from which you build a VG, then every LV inside 
> it will automatically be encrypted. So where's the flexibility?
I think it's a good idea. I have (nearly) my hole disk (except /boot and
1xNTFS) as a partition which is encrypted. Unencrypted it is a PV for a
VG in which all my Linux-partitions lives.
Nicely transparent setup for me, except for the fact, that now I cannot
install anything unencrypted anymore (for guests for example) or use a
different key for different LVs.
I don't know if the added LVM-layer costs notable CPU-time - but I'd be
easy for you to test :)

> For the latter I have some scripts ready to create an initramfs which can be 
> combined with the kernel (It's for EVMS, but it should be easy to adapt to 
> LVM.
I'm pretty sure genkernel can do it. I have observed that _before_ it
asks me for my crypt-password it does a lvm-scan, and also _after_. The
latter is the only one I need, but for Jens the first one will make your
LV for decryption accessible, and the latter will then reveal your LV
for your root.

BTW: I have compiled the modules I need for booting (incl. crypto-stuff)
into the kernel, so I can use this initrd with every new kernel. As it
now contains no modules, there is no need not to use genkernel anymore.

The genkernel-docs tell you to use on the kernel command line:
root=/dev/vg0/gentoo-root         (unencrypted dev - for /proc/cmdline)
real_root=/dev/vg0/gentoo-root    (unencrypted dev - for initrd-script)
crypt_root=/dev/sda2              (encrypted dev   - for initrd-script)
dolvm                             (do LVM scans    - for initrd-script)
keymap=de                         (if not US-kbd   - for initrd-script)

There is also "real_swap" and "real_resume" and other nice stuff :)

Bye,
Daniel

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]