In /etc/lilo.conf have a new "crypt_maps" parameter append = "dolvm real_root=/dev/mapper/root crypt_root=/dev/sda2 crypt_maps=nonroot:/dev/sda6,store:/dev/sda7" Reproducible: Always Steps to Reproduce: 1. encrypt volume groups with LUKS 2. store encryption keys into /boot 3. compile kernel and create initramfs with genkernel Actual Results: without "crypt_maps" parameter, VGs (except from "crypt_root" or "crypt_swap") fail to be openLUKS'ed, and LVs cannot be mounted after. Expected Results: openLUKS decrypted each pair name:path in the "crypt_maps" parameter's list, as the VG <name> lain on the device <path> /boot should contain, for each pair from "crypt_maps" name:path, the stored key for the volume group <name> as the file "<name>key"
Created attachment 308505 [details, diff] genkernel-3.4.29 kernel cmdline crypt_maps parameter list allows to decrypt VGs LUKS-encrypted, otherwise only for crypt_root or crypt_swap
Created attachment 308511 [details, diff] genkernel-3.4.29 kernel initramfs static lvm inside /sbin In /sbin all vg* and lv* commands are relative symlinks to "lvm", which must be "lvm.static" renamed and NOT moved in /bin (so symlinks' target is missing). This is "pkg-setup" of =sys-fs/lvm2-2.02.95-r1: pkg_setup() { # 1. Genkernel no longer copies /sbin/lvm blindly. # 2. There are no longer any linking deps in /usr. if use static; then elog "Warning, we no longer overwrite /sbin/lvm and;/sbin/dmsetup with" elog "their static versions. If you need the static binaries," elog "you must append .static to the filename!" fi } The test line /usr/share/genkernel/defaults/initrd.scripts:638 if [ -e '/bin/lvm' ] will use the dynamic version of "lvm", while the patch replaces it with if [ -e '/sbin/lvm' ] as surrounding, every such test is using '/sbin/*'. IF /usr/lib IS AN lvm MOUNT, THE DYNAMIC VERSION OF lvm WILL NOT RUN, SINCE IT NEEDS SHARED LIBRARIES FROM A PATH WHICH IT MUST MOUNT itself BEFORE IN ORDER TO RUN. Hence, only the static version will work with logical volume /usr/lib mounts. So, the 'lvm.static' is left in /sbin (where all vg*, lv*, symlinks are) and renamed to 'lvm', so the test in line #638 uses "/sbin/lvm".
Created attachment 309181 [details, diff] genkernel-3.4.30 kernel cmdline crypt_maps parameter list
Created attachment 309183 [details, diff] genkernel-3.4.30 kernel initramfs static lvm inside /sbin
Created attachment 313845 [details, diff] genkernel-3.4.33.1 kernel cmdline crypt_maps parameter list =sys-kernel/genkernel-3.4.33.1
Created attachment 313847 [details, diff] genkernel-3.4.30 kernel initramfs static lvm inside /sbin =sys-kernel/genkernel-3.4.33.1
Created attachment 313849 [details, diff] genkernel-3.4.33.1 kernel initramfs static lvm inside /sbin =sys-kernel/genkernel-3.4.33.1
Created attachment 314301 [details, diff] genkernel-3.4.34 kernel cmdline crypt_maps parameter list =sys-kernel/genkernel-3.4.34
Created attachment 314303 [details, diff] genkernel-3.4.34 kernel initramfs static lvm inside /sbin =sys-kernel/genkernel-3.4.34
Created attachment 315317 [details, diff] genkernel kernel cmdline crypt_maps parameter list =sys-kernel/genkernel-3.4.36
Created attachment 315319 [details, diff] genkernel kernel initramfs static lvm inside /sbin =sys-kernel/genkernel-3.4.36
Specifying the PATCH and Inclusion keywords is generally helpful to inform developers that there is content that needs to be reviewed. The genkernel team has a large backlog and it helps them to mark bugs with these keywords. I do not use LUKS on my systems, so I am not in a position to test them. I am going to ask that the hardened team review these patches.
Created attachment 319742 [details, diff] genkernel kernel cmdline crypt_maps parameter list genkernel kernel cmdline crypt_maps parameter list =sys-kernel/genkernel-3.4.40
Created attachment 319744 [details, diff] genkernel kernel initramfs static lvm inside /sbin genkernel kernel initramfs static lvm inside /sbin =sys-kernel/genkernel-3.4.40
Created attachment 319746 [details, diff] lvm2 initd service static lvm inside /sbin /etc/init.d/lvm service lvm inside /sbin =sys-fs/lvm2-2.02.95-r3
(In reply to comment #12) > Specifying the PATCH and Inclusion keywords is generally helpful to inform > developers that there is content that needs to be reviewed. The genkernel > team has a large backlog and it helps them to mark bugs with these keywords. Thanks, apart from the backlog thing, here is a great place to keep patches online. > > I do not use LUKS on my systems, so I am not in a position to test them. I > am going to ask that the hardened team review these patches. I use, but it becomes non benevolent to cast this, as far as a i know no one else does :(don't tell that to the reviewers:)
just to understand: does this patch allow to decrypt multiple devices (like /dev/sda2, /dev/sdb2) and use those in a mirrored zfs volume ?
Created attachment 351950 [details, diff] genkernel kernel cmdline crypt_maps parameter list genkernel kernel cmdline crypt_maps parameter list =sys-kernel/genkernel-3.4.47
Created attachment 351952 [details, diff] genkernel kernel initramfs static lvm inside /sbin genkernel kernel initramfs static lvm inside /sbin =sys-kernel/genkernel-3.4.47
(In reply to Simon Bühler from comment #17) > just to understand: does this patch allow to decrypt multiple devices (like > /dev/sda2, /dev/sdb2) and use those in a mirrored zfs volume ? The idea is the same as from `crypt_root' for "/root" in all other cases: "/home", "/usr"... What then? The patching is for a "two stages" encrypted storage setting: 1st stage: devices (crypt_maps=linux:/dev/sda2,home:/dev/sdb2) are `iterLUKS'ed and thus `cryptsetup luksOpen'-ed; and dm-entries are created: "/dev/linux", "/dev/mapper/home". 2nd stage: linux.scripts -> startLUKS -> "Rescan volumes" -> startVolumes is called second time 3rd stage: one VG is now to be found on /dev/linux. 4th stage: several LVs are found /dev/linux/usr, /dev/linux/usr/lib ... It is all conditioned from that also "/" must LUKS encrypted (no extra `if', without harm when there is no `crypt_maps' option). As I see it now in `linux.scripts:startVolumes', the test [ -n "${CRYPT_ROOT}" -o "${CRYPT_SWAP}" ] indicates that - on the second attempt to rescan volumes, after startLUKS - in the case of ZFS some "Reimporting" must be done. Is this what you mean? So, under this patching point of view, should there or should there be not some extra for `crypt_maps'? I haven't a clue about zpools: would the export/import zpools "trick" work generally, root/swap/maps? Thank s.
I use lvm inside a luks container, but I have no issues with the current location of the lvm binaries. Why is this an issue? We are not going to ship two copies of lvm{.static} in genkernel for fun...
(In reply to Rick Farina (Zero_Chaos) from comment #21) > I use lvm inside a luks container, but I have no issues with the current > location of the lvm binaries. Why is this an issue? We are not going to > ship two copies of lvm{.static} in genkernel for fun... Umm i see that genkernel is moving /sbin/lvm.static to /bin/lvm and i don't see a reason for this, please correct me if I am wrong as I have not used lvm in genkernel for years. From what i see they are just putting lvm.static back to it's original location of /sbin Also this + mv ${TEMP}/initramfs-lvm-temp/sbin/lvm{.static,} || in https://bugs.gentoo.org/attachment.cgi?id=351952 is going to fail as it should be + mv ${TEMP}/initramfs-lvm-temp/sbin/lvm{.static,} ${TEMP}/initramfs-lvm-temp/sbin/lvm || I wish i could test this patch myself as I once had something similar on my /init but time will not allow me to review this in action.
Really? How? (In reply to Rick Farina (Zero_Chaos) from comment #21) > I use lvm inside a luks container, but I have no issues with the current > location of the lvm binaries. Why is this an issue? We are not going to > ship two copies of lvm{.static} in genkernel for fun...
You'are both right. These days I use genkernel-next though. It has populated /lib [-> /lib64] with libraries/dependencies to dynamically linked /sbin/lvm. I remove initd patch. It remains to automatically assign and open keys to volumes. (In reply to Fernando V. (likewhoa) from comment #22) > (In reply to Rick Farina (Zero_Chaos) from comment #21) > > I use lvm inside a luks container, but I have no issues with the current > > location of the lvm binaries. Why is this an issue? We are not going to > > ship two copies of lvm{.static} in genkernel for fun... > > Umm i see that genkernel is moving /sbin/lvm.static to /bin/lvm and i don't > see a reason for this, please correct me if I am wrong as I have not used > lvm in genkernel for years. > > From what i see they are just putting lvm.static back to it's original > location of /sbin > > Also this > + mv ${TEMP}/initramfs-lvm-temp/sbin/lvm{.static,} || > > in https://bugs.gentoo.org/attachment.cgi?id=351952 is going to fail as it > should be > + mv ${TEMP}/initramfs-lvm-temp/sbin/lvm{.static,} > ${TEMP}/initramfs-lvm-temp/sbin/lvm || > > I wish i could test this patch myself as I once had something similar on my > /init but time will not allow me to review this in action.
COMMENT #2 NO LONGER APPLIES. (In reply to Sebastian Glita from comment #2) > Created attachment 308511 [details, diff] [details, diff] > genkernel-3.4.29 kernel initramfs static lvm inside /sbin > > In /sbin all vg* and lv* commands are relative symlinks to "lvm", which must > be "lvm.static" renamed and NOT moved in /bin (so symlinks' target is > missing). > > This is "pkg-setup" of =sys-fs/lvm2-2.02.95-r1: > > pkg_setup() { > # 1. Genkernel no longer copies /sbin/lvm blindly. > # 2. There are no longer any linking deps in /usr. > if use static; then > elog "Warning, we no longer overwrite /sbin/lvm and;/sbin/dmsetup with" > elog "their static versions. If you need the static binaries," > elog "you must append .static to the filename!" > fi > } > > The test line /usr/share/genkernel/defaults/initrd.scripts:638 > > if [ -e '/bin/lvm' ] > > will use the dynamic version of "lvm", while the patch replaces it with > > > if [ -e '/sbin/lvm' ] > > as surrounding, every such test is using '/sbin/*'. > > IF /usr/lib IS AN lvm MOUNT, THE DYNAMIC VERSION OF lvm WILL NOT RUN, SINCE > IT NEEDS SHARED LIBRARIES FROM A PATH WHICH IT MUST MOUNT itself BEFORE IN > ORDER TO RUN. > > Hence, only the static version will work with logical volume /usr/lib mounts. > So, the 'lvm.static' is left in /sbin (where all vg*, lv*, symlinks are) and > renamed to 'lvm', so the test in line #638 uses "/sbin/lvm".
Comment on attachment 319746 [details, diff] lvm2 initd service static lvm inside /sbin As conforming with Comment 21 , Comment 22 .
Comment on attachment 351952 [details, diff] genkernel kernel initramfs static lvm inside /sbin As conforming with Comment 21 , Comment 22 .
(In reply to Sebastian Glita (Soaron) from comment #27) > Comment on attachment 351952 [details, diff] [details, diff] > genkernel kernel initramfs static lvm inside /sbin > > As conforming with Comment 21 , Comment 22 . please try to specify if you are making patches for genkernel or genkernel-next next time around. Changing topic to reflect this.