The new versions does _not_ include the crypto-patch, this is an real showblocker (at least for me). So sad that this crypto-thing is not included in official kernel-tree, it is also missing in util-linux. So sad too, that there is also very rar support in gentoo. There where several gentoo-sources without the crypto-patch (beside the fact that gentoo-sorces is the only kernel suppoting it and is not at current date this time) and now it is also missing in util-linux... Reproducible: Always Steps to Reproduce: Actual Results: Not able to mount any crypto-filesystem, -k flag in losetup is missing... Expected Results: To mount my crypto-partitions etc. The epatch-Line for the crypto-Patch is commented out. The patch is from 2.11z (or earlier), does it work with 2.12?
Have you tested this with the version 2.12? It has theoretical crypto support. I cannot test this side, so if you don't mind, just have a look.
Sure, i've tested it and thatsway i've filed this bug. Crypto-support was included in prior versions but is missing in 2.12. Just check if your losetup-command supports encryption and the -k option, that should be a very simple test and does not depend on any crypto-filesystem (or whatever). I've downgraded to 2.11z-r7 and now it's working again.
I've reinstalled 2.12 just to prove it's not working. This is what i get: toral init.d # /sbin/losetup -e twofish -k 128 /dev/loop0 /dev/hda2 /sbin/losetup: invalid option -- k usage: /sbin/losetup loop_device # give info /sbin/losetup -d loop_device # delete /sbin/losetup [ -e encryption ] [ -o offset ] loop_device file # setup toral init.d # /sbin/losetup -e twofish /dev/loop0 /dev/hda2 Password: ioctl: LOOP_SET_STATUS: Invalid argument This is the output from loetup from 2.11z-r7 (which works fine): toral ebuilds # losetup usage: losetup loop_device # give info losetup -d loop_device # delete losetup [ options ] loop_device file # setup where options include --offset <num>, -o <num> start at offset <num> into file. --pass-fd <num>, -p <num> read passphrase from file descriptor <num> instead of the terminal. --encryption <cipher>, -e <cipher> encrypt with <cipher>. Check /proc/crypto/cipher for available ciphers. --keybits <num>, -k <num> specify number of bits in the hashed key given to the cipher. Some ciphers support several key sizes and might be more efficient with a smaller key size. Key sizes < 128 are generally not recommended --phash <hash>, -P <hash> specify <hash> to use for hashing the passphrase (supported: rmd160old, sha256, sha384, sha512)
Come on guys, i'm really disappointed. This is a real blocker but nothung changed for nearly days. There is even no assignment to some Responsible. As long as this problem is not solved, the current ebuild has to be masked (in my humble opinion). I've done some investigation, but was'nt able to find an crypto-patch for 2.12 (the one from 2.11z does'nt seem to work). It seems in current 2.5.x kernels is an new Crypto-API included, which prevents us from patching util-linux any longer, but as long gentoo-sources is 2.4.20 we still need this (gentoo-) crypto-Patch as included in 2.11*. I'll keep looking for an patch...
Just to support your case: I've had exactly the same experience. Since all my productive sources (that's what I earn my money with) are on an encrypted filesystem on a laptop, I _had_ to go back to version 2.11z-r7 for now.
Thats exactly my problem! I've no problems at my desktops at home, but my laptops uses crypto-fs of course (as everybody should). Still no action from the gentoo-guys. I thought gentoo is cool and secure...
To be fair the AES-loop project currently has no patch for util-linux-2.12 either, maybe they are having problems making it work? Tom
isn't this a reason for masking this ebuild?
Hey guys I just checked on this ebuild and its ~arch masked (as of July 29th) Now here is a tip, Try not to depend (for you jobs sake) on ebuilds that are ~arch masked. This means its in development and or is not stable for said arch yet.
Me too. I had to revert back to version 2.11z-r7. Can't mount any encrypted filesystems via the loopback device with 2.12.
Yes, this is why it is ~arch masked. We need testing of it, but until there is a new patch for the crypto stuff, or until somebody ports the patch ... I do not use crypto, and as it is a high risk patch, I'll rather not try to port it, as I could then be opening holes ...
Created attachment 16144 [details] failed patch output
i uncommented the crypto patch line in the 2.12 ebuild, which failed with the attached output
2.12 and on probably wont have crypto support from what I understand, as that version and on are somehow supposed to already tie into the crypto hooks of the 2.6 kernels.
I also had some problems recently with crypto support (running a 2.4.22-ac1 kernel and util-linux 2.12). But I just tried the 2.6.0-test5 kernel and now it works. Seams like the new util-linux is incompatible with 2.4 kernels. Let's hope the stable 2.6 comes soon...
Just to add my 2 cents and resume the situation: As of 2.4.22, they included cryptoapi with mainstream kernel. As far as I can see it's a backport from the 2.5/2.6 line and kerneli.org no longer provides a cryptoapi patch for .22 or later. However, vanilla .22 does not provide the cryptoloop functionality. kerneli.org still provide a patch for .22 to add cryptoloop support. Now, such a patched .22 kernel does NOT work correctly with util-linux-2.11z-r6, which is the current stable version in portage. However it seems to work fine with util-linux-2.12 (which is no big surprise as 2.12 specifically adds support for the 2.6 type cryptoapi stuff). However what they did not add in 2.12 is the -k flag to specify the keysize of the encryption key. Result: All existing encrypted partitions won't mount unless they were encrypted with whatever 2.12 uses as default keysize (which I think is only 32 bit if I read the source code correctly). Thus, what we need is a patch to add the -k flag functionality into util-linux 2.12, then make sure that 2.11z is used for pre .22 kernels and the patched 2.12 for post .22 kernels.
Created attachment 18674 [details, diff] -k support patch This patch adds -k support to losetup, note this is ONLY the short option. This patch works for _ME_ I must stress that it works for ME, in theory it should work for anyone using a 2.6 beta kernel with crypto api support configured, but I cannot / will not garuntee that. This patch is largely derived from re-coding parts of the 2.11y patch that is in portage, but with a few changes to accomodate the 2.6 crypto api etc.. 2.4 Kernel users sorry, but while running util-linux with this patch crypto filesystems didnt work for me, I didnt try too hard though so someone feel free to look at it. All in all, be careful when using this.
Just a thought: If the package does not have "crypt" support, I would remove the USE flag from IUSE, so that unsuspecting users (like me) aren't mislead to believe it _would_ have support for cryptoloop.
Does anybody know about an up-to-date 2.4-kernel-source which includes the crypto-api (incliding crypto-loop) which is inlcuded in the outdated gentoo-sources? The crypto-patch in ac-sources seems to incompatible with the old _and_the new version of util-linux!? Any help? If i use kernel-2.6 i've several problems to get my pcmcia-devices working (especialy ISDN), so in conclusion gentoo (at least an up to date gentoo) is not usable for laptops in the moment (no crypto-filesystem for 2.4-kernels which every laptop needs, limited pcmcia-supported when using 2.6-kernels which is needed by many/some laptops)... Again: Please mask util-linux-2.12 or introduce an special USE-Flag (or whatever) to filter it out...
Guys, i found an acceptable solution which may also work for you. Due to the fact, that the former/old crypto-api is incompatible with util-linux i decided to upgrade to kernel-2.6. Unfortunatly this is not an good idea for laptop-users, 'cause there are some essential things not working properly (f.i. PMCIA and special keys found on some laptops). But i created an new crypto-filesystem using the new crypto-api from kernel 2.6. Now that i've been forced to downgrade back to kernel-2.4 i found that in current releases the new crypto-api is also included (did'nt know about that fact before, 'cause gentoo-sources ist still hopeless outdated). The only thing you have to do, is to patch any vanilla-[prepatch-]sources with the cryptoloop-jari patch and VOILA, your problems are gone. Unfortunatly it will not work using the aa-sources - in that case you'll get some patching warnings and compilation-errors. The good thing is, you will also be fully compatible to kernel 2.6 in this point, where the cryptoloop seemsto be part of the official branch (in case anybody knows why, and why not in kernel-2.4 please let me know). To the gentoo guys: I'll leave this as a blocker, because there is no source-ebuild in gentoo for kernel-2.4 including cryptoloop along with the new crypto-api, so the current unmasked util-linux is still not usable. If you are interessted i'll take care of an source-ebuild based on vanilla-sources or better vanilla-prepatch-sources including the cryptoloop-patch. Also i've some ideas which other ebuilds could tolerate an update...
To be honest here this package just seems to be in state of transition and seems to be the only thing blocking unix-linux-2.12 from going stable as far as I can tell. As crypto support is considered more as fluff than apart of the core system I see no reason why it should no go stable anyway. (sorry crypto users) Also as azarah alone seems to maintains 90% of everything in "emerge system" he tends to find himself a very busy man, so I would assume that any patches are welcome.
What do you mean by "sorry crypto users"? Is gentoo just for non-laptop users? It's a fact that util-linux is incompatible to the ancient gentoo-sources (which is still the official kernel-source for gentoo) at least when it comes to crypto-filesystems (i also remember some words like "gentoo is secure"). What do you mean by "patches are welcome"? IMHO the best (only acceptable?) solution would be, to update gentoo-sources or at least to have an official supported patched kernel-source. As i wrote before, i'll be happy to provide you whith such an ebuild. I'll post it as an new ebuild this evening and link a dependency from this bug to the new ebuild. Does this make sense for you? If not please let me know, what other help i may provide. I'll also investigate, why cryptoloop is part of kernel 2.6 but not in current releases of 2.4 nor the official patch-sets. I guess this problem will go away in a while (but for now it still exist).
Just added the new ebuild for cryptoloop-sources as Bug 30984 and set a dependency to this one. This might fix this one (or at least remove the blocking-severity).
Well, I'm currently testing a 2.4.22 based gentoo-test-sources, it'll become gentoo-sources once all the bugs are worked out of it. Can you give it a try and let me know if it works for you. $ emerge gentoo-test-sources
First Impression: Looks quite good concerning the available options, but cryptoloop is still missing (this is what we talking about). Please apply patch-cryptoloop-jari-2.4.22.0 as well and all of us should be happy.
Applying the patch manually results in two warnings, but compiles fine. I remember to get a lot more problems when trying to patch aa-sources & Co. BTW: I would also recommend to apply a current prepatch, is it not included already. Is there a list, which patches you've included in this kernel?
For me worked (I use twofish): vanilla linux-2.4.22 + patch: http://www.kernel.org/pub/linux/kernel/people/hvr/testing/patch-cryptoloop-jari-2.4.22.0 util-linux-2.12 + patches (in order): http://www.stwing.org/~sluskyb/util-linux/losetup-variable-key-size-mk6.patch http://www.stwing.org/~sluskyb/util-linux/losetup-keygen-prog-mk7.patch and the program: http://www.stwing.org/~sluskyb/util-linux/hashalot-0.1.0.tar.gz Instead of: # losetup -e twofish -k 256 /dev/loop1 /dev/hda5 I use now: # insmod cryptoloop # insmod twofish # ./hashalot rmd160 | losetup -p0 -e twofish-256 /dev/loop1 /dev/hda5 Just my 2 cents. :)
*** Bug 32502 has been marked as a duplicate of this bug. ***
Cryptoloop WFM with patches from comment 28. Kernel 2.6.0-test10-mm1.
Sorry for spam. Comment 27 I meant. Stupid typo.
What is going here? Now, that _you_ _have_ _forced_ everyone to switch to the new crypt-api (coming with cryptoloop-jari) you include a patch for the cryptoapi in util-linux-2.12-r1 to get the old behavior (which results in losetep requestung the keysize again). Thats not fun anymore! Solution for anyone who might also affected: USE -crypto in my make.conf, hoping that this would not impact other things... Is the crypto Flag used in other ebuilds as well? If so, i would recommend a separate USE-fkag for the losetup-patch? I relly bet, this patch is also not compatible to kernel 2.6 (not tested so far)....
OK, it seems not that simple to just use USE=-crypt, because it is used in some other ebuilds as well (mozilla is one the more known of it). Also, in a bunch of kernel-sources it is used. So, it would a solution to split the single Flag crypt in two, lets say oldcryptoapi and the former crypt, which should not change...
I committed the util-linux-2.12-r1 ebuild with the patches from comment #27 http://bugs.gentoo.org/show_bug.cgi?id=25192#c27 before I had even seen this bug report. I did this to fulfill my own desire to get cryptoapi/cryptoloop with 2.6.0-testX kernels working, and it works quite well. If you all had reviewed the ChangeLog, you would have seen how to make it compatible via following the thread. http://www.kerneli.org/pipermail/cryptoapi-devel/2003-September/000642.html is the short listing of commands showing that it is compatible with old jari setups. In short, the keylength is passed via the encryption method now, e.g. -e aes-cbc-256 instead of passing a -k parameter. Also, losetup no longer has it's own internal hashing algorithms, so the 2.12-r1 release depends on hashalot which provides a few. Please refer to that mailing list post for more info. And yes, it does really work for 2.6.0 as well, I'm using it for my local CVS repository at work. Moving this bug away from blocker to normal.
*** Bug 34985 has been marked as a duplicate of this bug. ***
It now works for me. Thanks for the link to he mailing lists. That helped me know how to mount my loop again with the new utils.
New ebuild works as advertised. I have to mention that to use hashalot as user, you should set the suid bit on it. Else it won't lock the password in memory.
*** Bug 36882 has been marked as a duplicate of this bug. ***
To be honest, the current situation is somewhat unsatisfying. _Please_ could some official make an final decision what we'll do here now? This is a summary what happened (from my side of view): - in the past (prior util-linux-2.12) all of used one crypto api, lets called old (crypto api) - in order to use it you _had_ to patch util-linux (and also the kernel) - introduced in kernel-2.5/2.6 we've got a new api in mainstrem sources, lets call it new crypto api - =util-linux-2.12 just coverd the new one in - the prior patch was against util-linux was not available for a long time - to use the new crypto api and util-linux-2.12 you therefore had to use a (unpatched) kernel-2.5/2.6 or an 2.4 including a patch for getting support for the new crypto api (cryptoloop-jari or others) - this patch is not in gentoo-sources (please keep this in mind when making a decission!) - also, you had to rebuild your filesystem containing the crypto-fs - Use of the old crypto api and =util-linux-2.12 was just no possible - we had this state from July till Dezember last year and everybode who was affected solved it is own way (there was just no support from gentoo - some used <util-linux2.12, other patched 2.4, other might have switched to 2.5/2.6 - personaly i switched to the new crypto api, using vanilla 2.4 and cryptoloop-jari, see also Bug 30984) - sudenly, someone released a patch for the old crypto api which made his way into gentoo, not considering that this may cause again a lot of trouble - the patch is used when somene uses the very common USE flag crypt (remember: the patch is just needed if one is using the old cryptoapi - in _no_ other case!) - the patch is stated as compatible to both (the old and new) crypto-api, but this is not true (at least for me), see also http://www.kerneli.org/pipermail/cryptoapi-devel/2003-September/000634.html , where is stated that the patch may cause trouble - at least for me every update of util-linux ends in trouble so i had to reemerge using "-crypt" My recomodation is: lets introduce a new flag 'oldcryptoapi' and use it to decide if we need patching or not (most people don't need it, only some uses cryptoapi anyway and just of some them the old one). One can also think about having a flag 'newcryptoapi' to be "compatible" (to what? - it was broken anyway for half a year), but as long the new one would be default for future use use we should use the first one to know if someone wants this patch. I really recomend to decide how to go on and close this long during bug. I'm in the process to increase the priority back to something higher, but want to get some feedback before. Feedback welcome. Thx a lot!
Reporting failure with 2.6.1-mm1 (worked with 2.6.0-mm2) / util-linux-2.12-r4. Can't create any loop (LOOP_SET_FD)
Seem like kernel problem or api change, as even without crypt it doesn't work.
Astralstorm: Do you have an existing filesystem or want to use/create a new one? If you have a "old" one and want it to use with kernel 2.6 try the link Brad gave above (and in Changelog) and _please_ report back if it works for you. But to be safe for future use I'd recommend to switch to the new one, that means you don't have to patch your kernel 2.6 and you must'nt patch your util-linux (it ist consodered to work in some circumstances, but you just don't need it and it might cause trouble - like in my case). So do the follwing steps: 1. boot your old working system (kernel, maybe old util-linux etc.) and make a backup of your cryptofs (Assuming you have a old one) 2. do a 'USE="-crypt" emerge util-linux' 3. Build your new kernel 2.6 - make sure you have cryptoloop-support and your prefered cipher included 4. boot the new kernel 5. create a new cryptofs (drop the old one if applicable) 6. restore the content of your old cryptofs to the new one This should do the trick. HTH, Jan PS: I'll increase the priority of this one, there has to be a solution in the near future.
Astralstorm, one more question: Have you (re)emerged util-linux after the last working mount of your cryptofs? If so, please report the old and new version also (use 'genlop util-linux' to be sure).
there is a bug in the loop module, as stated in the changelog for linux-2.6.2rc1 located at: http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.2-rc1 the message is: <---- snip ----> We need to set the hardsect_size of the loop device to that of the real device. The loop device advertises a block size of 1024 even when configured over a cdrom. When burning a ext2 on a cd, and mounting it directly, I get: blocksize=2048; when I losetup /dev/loop0 /dev/cdrom, and then try to mount, I get: blocksize=1024; and then misaligned transfer; this results in not being able to read the superblock. The loop device should be changed to export the same blocksize of the underlying device <---- snip ----> ' think this is why you had to recreate your cryptodevices... andre
I just wanted to chime in and add what works for me: - vanilla kernel 2.6.3 - util-linux-2.12-r4 - rmd160 | losetup -p0 -e aes-cbc-128 /dev/loop0 /dev/hda1 I've tried emerging util-linux with USE="crypt" and USE="-crypt" and both work. I have not tested compatibility with any of the other cryptoloop systems. I'm also using lvm2 with multiple logical volumes (including swap) on top of my cryptoloop. Very cool. :-) This cryptoloop stuff is quite a mess for the 2.4 -> 2.6 transition, but the way of the future seems to be smooth for me.
Using X86: 1) util-linux-2.11z-01-nfsv4.dif is redundant as nfsv4 support is already present in 2.12. Note: no error reported during build unless performing 3) below. 2) rpm build fails with !!! ERROR: sys-apps/util-linux-2.12-r3 failed. !!! Function dyn_rpm, Line 873, Exitcode 1 !!! Failed to integrate rpm spec file 3) For crypto, propose to replace currently used util-linux-2.12-cryptoapi-losetup.patch.bz2 by util-linux-2.12.diff ex http://loop-aes.sourceforge.net/loop-AES/loop-AES-v2.0d.tar.bz2 merrits: Full functionality for mount, losetup and a nice manual update. Please have a look at this patch.
Mike Ossmann wrote: > I've tried emerging util-linux with USE="crypt" and USE="-crypt" and both work. Your lucky one :-). However: this prooves that the patch is not needed (for everone)! It still causes errors on some boxes...
1) util-linux-2.11z-01-nfsv4.dif is redundant as nfsv4 support is already present in 2.12 where do you see that fact ? the nfs4 patch applies cleanly and looking quickly at mount.c, i see no reference to 'nfs4' if we remove the patch
util-linux-2.12i now has the loop-aes patch
This bug has been open as almost long as I've been a dev. SpanKS for seeing a final resolution.
My final resolution is (for now): # cat /etc/portage/package.use sys-apps/util-linux -crypt
