When "loopback device support" and "Twofish encryption for loopback device" is compiled INTO the kernel, the "losetup -e twofish /dev/loop0 /encrypted-file" command fails with the error: "ioctl: LOOP_SET_STATUS: invalid argument"
If they are compiled as modules, everything works OK.
I have tred it with many versions of the SuSE kernels, and the result is always the same !.
Any suggestions on how to get it to work.
Yeah, I have my own kernel compiled with the various different algorithms built-in. There were 2 patches which I had to apply to the vanilla kernel. One was the patch-int-2.4.20.0 and the other was loop-jari-2.4.20.0.patch
So I will hazard a guess that you don't have the patched loop built into the kernel.
The files are at: http://ftp.linux.hr/pub/linux/kernel/crypto/v2.4/testing/
Yes but the strange thing is that it works when "Twofish encryption for loopback device" is compiled as a module, so it must be included in the source. I use SuSE kernels, the latest I have testet is 2.4.20-13.
Well SuSE is heavily patched and they do everything with modules, so maybe the loop module isn't getting loaded right when you build twofish into the kernel. Have you tried to manually load the loop module first, before any attempt to use the encryption?
I don't understand. What do you meen by "manually load the loop module" ?. No matter if "loopback device support" is compiled into the kernel or not, as long as "Twofish encryption for loopback device" is compiles as a module everything works OK. I have not tried compiling the "loopback device support" as a module and the "Twofish encryption for loopback device" INTO the kernel, if that's what you meen.
On Mon, 26 May 2003 01:16:23 +0200 "Bo Jacobsen" subs@systemhouse.dk wrote:
I don't understand. What do you meen by "manually load the loop module" ?. No matter if "loopback device support" is compiled into the kernel or not, as long as "Twofish encryption for loopback device" is compiles as a module everything works OK. I have not tried compiling the "loopback device support" as a module and the "Twofish encryption for loopback device" INTO the kernel, if that's what you meen.
When I build my vanilla kernels, I get an option to build loopback device into the kernel, as a module, or not. This is separate from the crypto selections under block devices. So what I'm suggestingis build loopback support INTO the kernel, not as a module. But maybe you can't do this with a suse patched kernel.
I havn't done what you are trying. You are asking why you can't use a suse kernel to build twofish encryption into the kernel. I am guessing at why you get "loop" errors.
I have stated that it can be done on vanilla kernels, if you build loop into the kernel, as well as the encryption patch. I have mine done like that.
I will say it again, the SuSE kernels are heavily patched, and biased toward using modules. So switch to a vanilla kernel to do what you want to do. If switching to a vanilla kernel is out of the question for you, then just live with twofish as a module. It is very hard to customize the patched SuSE kernels. Maybe some other patch has made it so the kernel expects the loop_fish2 code be a module, that seems to be happening. If you do build loopback into a suse patched kernel, and manage to get twofish to build into the kernel, it's highly likely you will get errors in another area of loopback; such is the nature of the suse patched kernel. It's getting more and more complex and intertwined as time moves forward.
Why do you care about twofish as a module, security reasons? I switched to the standard international patch to get AES encryption, as well as about 10 other algorithms.
I don't understand. What do you meen by "manually load the loop module" ?. No matter if "loopback device support" is compiled into the kernel or not, as long as "Twofish encryption for loopback device" is compiles as a module everything works OK. I have not tried compiling the "loopback device support" as a module and the "Twofish encryption for loopback device" INTO the kernel, if that's what you meen.
When I build my vanilla kernels, I get an option to build loopback device into the kernel, as a module, or not. This is separate from the crypto selections under block devices. So what I'm suggestingis build loopback support INTO the kernel, not as a module. But maybe you can't do this with a suse patched kernel.
I havn't done what you are trying. You are asking why you can't use a suse kernel to build twofish encryption into the kernel. I am guessing at why you get "loop" errors.
I have stated that it can be done on vanilla kernels, if you build loop into the kernel, as well as the encryption patch. I have mine done like that.
I will say it again, the SuSE kernels are heavily patched, and biased toward using modules. So switch to a vanilla kernel to do what you want to do. If switching to a vanilla kernel is out of the question for you, then just live with twofish as a module. It is very hard to customize the patched SuSE kernels. Maybe some other patch has made it so the kernel expects the loop_fish2 code be a module, that seems to be happening. If you do build loopback into a suse patched kernel, and manage to get twofish to build into the kernel, it's highly likely you will get errors in another area of loopback; such is the nature of the suse patched kernel. It's getting more and more complex and intertwined as time moves forward.
Why do you care about twofish as a module, security reasons? I switched to the standard international patch to get AES encryption, as well as about 10 other algorithms.
I think you are right about it being a specific SuSE problem, as the problem has persisted as least since version 7.1. It would just had been nice if someone had solved the problem. My problem is that I really need the facility now.
I care about twofish as a module because I need to run the kernels I use (on some hosts) to run without modules.
The reason for using the SuSE kernels, I think, is most a matter of convenience. Actually I don't think I ever have tried the vanilla kernels, but maybe this is the time.
Bo
I have just compiled the vanilla kernel 2.4.21 with the patches loop-jari-2.4.21.0 and patch-int-2.4.21.0 and it will still not run when Twofish is compiled as a module !?. Have you only tried it compiled as a module ?
Bo
----- Oprindelig meddelelse ----- Fra: "zentara" zentara@zentara.net Til: suse-linux-e@suse.com Sendt: 26. maj 2003 13:16 Emne: Re: [SLE] Why does loopback encryption only work when loopback is compiled as a module
On Mon, 26 May 2003 01:16:23 +0200 "Bo Jacobsen" subs@systemhouse.dk wrote:
I don't understand. What do you meen by "manually load the loop module" ?. No matter if "loopback device support" is compiled into the kernel or not, as long as "Twofish encryption for loopback device" is compiles as a module everything works OK. I have not tried compiling the "loopback device support" as a module and the "Twofish encryption for loopback device" INTO the kernel, if that's what you meen.
When I build my vanilla kernels, I get an option to build loopback device into the kernel, as a module, or not. This is separate from the crypto selections under block devices. So what I'm suggestingis build loopback support INTO the kernel, not as a module. But maybe you can't do this with a suse patched kernel.
I havn't done what you are trying. You are asking why you can't use a suse kernel to build twofish encryption into the kernel. I am guessing at why you get "loop" errors.
I have stated that it can be done on vanilla kernels, if you build loop into the kernel, as well as the encryption patch. I have mine done like that.
I will say it again, the SuSE kernels are heavily patched, and biased toward using modules. So switch to a vanilla kernel to do what you want to do. If switching to a vanilla kernel is out of the question for you, then just live with twofish as a module. It is very hard to customize the patched SuSE kernels. Maybe some other patch has made it so the kernel expects the loop_fish2 code be a module, that seems to be happening. If you do build loopback into a suse patched kernel, and manage to get twofish to build into the kernel, it's highly likely you will get errors in another area of loopback; such is the nature of the suse patched kernel. It's getting more and more complex and intertwined as time moves forward.
Why do you care about twofish as a module, security reasons? I switched to the standard international patch to get AES encryption, as well as about 10 other algorithms.
-- use Perl; #powerful programmable prestidigitation
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Mon, 23 Jun 2003 01:24:14 +0200 "Bo Jacobsen" subs@systemhouse.dk wrote:
I have just compiled the vanilla kernel 2.4.21 with the patches loop-jari-2.4.21.0 and patch-int-2.4.21.0 and it will still not run when Twofish is compiled as a module !?. Have you only tried it compiled as a module ?
I havn't tried 2.4.21 patches yet, and it says in the download announcement that these are beta releases, and to expect problems. It asks that you report any problems to them.
What do you mean "will not run when compiled as module?" SuSE's default kernel runs it fine as a module.
I seem to remember when this thread started, you wanted to build encryption into the kernel? So why is it changing to will not run as module?
You are just doing something wrong, or missing some step in the whole process. After you apply a patch, do you do a "find . *.rej" to see if any of the patch didn't take?
Also, read the help sections for each item in "make menuconfig", and make sure you enable other options as they may mandate.
On Mon, 23 Jun 2003 01:24:14 +0200 "Bo Jacobsen" subs@systemhouse.dk wrote:
I have just compiled the vanilla kernel 2.4.21 with the patches loop-jari-2.4.21.0 and patch-int-2.4.21.0 and it will still not run when Twofish is compiled as a module !?. Have you only tried it compiled as a module ?
I havn't tried 2.4.21 patches yet, and it says in the download announcement that these are beta releases, and to expect problems. It asks that you report any problems to them.
What do you mean "will not run when compiled as module?" SuSE's default kernel runs it fine as a module.
I seem to remember when this thread started, you wanted to build encryption into the kernel? So why is it changing to will not run as module?
You are just doing something wrong, or missing some step in the whole process. After you apply a patch, do you do a "find . *.rej" to see if any of the patch didn't take?
Also, read the help sections for each item in "make menuconfig", and make sure you enable other options as they may mandate.
Sorry for the confusing message. I't was pretty late, so I just wrote without thinking. Here is it, as it should had been:
I have just compiled the vanilla kernel 2.4.21 with the patches loop-jari-2.4.21.0 and patch-int-2.4.21.0, and it will still not run when Twofish is compiled into the kernel !?. Compiled as a module it works OK.
The error message is as always: "ioctl: LOOP_SET_STATUS: invalid argument"
Have you actually tried it, with Twofish compiled into the kernel ?
Bo
On Mon, 23 Jun 2003 22:42:34 +0200 "Bo Jacobsen" subs@systemhouse.dk wrote:
Sorry for the confusing message. I't was pretty late, so I just wrote without thinking. Here is it, as it should had been:
I have just compiled the vanilla kernel 2.4.21 with the patches loop-jari-2.4.21.0 and patch-int-2.4.21.0, and it will still not run when Twofish is compiled into the kernel !?. Compiled as a module it works OK.
The error message is as always: "ioctl: LOOP_SET_STATUS: invalid argument"
Have you actually tried it, with Twofish compiled into the kernel ?
I have aes and twofish compiled into the kernel on 2.4.20 and it works fine.
I am right in the process of compiling kernel 2.4.21. I'll let you know how it goes. So far everything looks good, the patches all went in cleanly.
From the error message, I have to ask, "did you compile loopback into the kernel too"
I think you may need to. There may be some glitch if you make loop a module but put encryption built-in. Just a guess. I'll be done testing by tommorrow.
In the mean time, you should read this to help you in testing. http://sdb.suse.de/en/sdb/html/jsj_crypto_filesystem_mini_howto.html
On Mon, 23 Jun 2003 22:42:34 +0200 "Bo Jacobsen" subs@systemhouse.dk wrote:
Sorry for the confusing message. I't was pretty late, so I just wrote without thinking. Here is it, as it should had been:
I have just compiled the vanilla kernel 2.4.21 with the patches loop-jari-2.4.21.0 and patch-int-2.4.21.0, and it will still not run when Twofish is compiled into the kernel !?. Compiled as a module it works OK.
The error message is as always: "ioctl: LOOP_SET_STATUS: invalid argument"
Have you actually tried it, with Twofish compiled into the kernel ?
I have aes and twofish compiled into the kernel on 2.4.20 and it works fine.
I am right in the process of compiling kernel 2.4.21. I'll let you know how it goes. So far everything looks good, the patches all went in cleanly.
From the error message, I have to ask, "did you compile loopback into the kernel too"
I think you may need to. There may be some glitch if you make loop a module but put encryption built-in. Just a guess. I'll be done testing by tommorrow.
Yes it's there. If not, I could not run losetup .. /dev/loop0 succesfully (with Twofish compiled as a module).
Bo
On Mon, 23 Jun 2003 23:28:45 +0200 "Bo Jacobsen" subs@systemhouse.dk wrote:
zentara wrote: I am right in the process of compiling kernel 2.4.21. I'll let you know how it goes. So far everything looks good, the patches all went in cleanly.
From the error message, I have to ask, "did you compile loopback into the kernel too"
I think you may need to. There may be some glitch if you make loop a module but put encryption built-in. Just a guess. I'll be done testing by tommorrow.
Yes it's there. If not, I could not run losetup .. /dev/loop0 succesfully (with Twofish compiled as a module). Bo
OK, I think I found the problem you are having. I had forgot I had a patched version of losetup. I put the utils-linux.rpm that comes with suse in, and I got your error.
If you read /usr/src/linux/Documentation/cryptoapi/cryptoloop.txt it tells you that you need a patched utils-linux from: http://www.kernel.org/pub/linux/kernel/people/hvr/util-linux-patch-int/
you should apply that patch to utils-linux package available in the utilities directory at http://kernel.org.
Warning:, the patch does not apply cleanly and you will have to manually apply the patches to losetup and mount in the mount subdir of utils-linux-2.11z When you first apply the patch, it will give you a couple of *.rej files in /mount, you need to manually copy them in to patch the files.
If you have trouble with the patching, I'll email you a copy of the patched files.
Once that is done, your error should go away.
zentara wrote: I am right in the process of compiling kernel 2.4.21. I'll let you know how it goes. So far everything looks good, the patches all went in cleanly.
From the error message, I have to ask, "did you compile loopback into the kernel too"
I think you may need to. There may be some glitch if you make loop a module but put encryption built-in. Just a guess. I'll be done testing by tommorrow.
Yes it's there. If not, I could not run losetup .. /dev/loop0 succesfully (with Twofish compiled as a module). Bo
OK, I think I found the problem you are having. I had forgot I had a patched version of losetup. I put the utils-linux.rpm that comes with suse in, and I got your error.
If you read /usr/src/linux/Documentation/cryptoapi/cryptoloop.txt it tells you that you need a patched utils-linux from: http://www.kernel.org/pub/linux/kernel/people/hvr/util-linux-patch-int/
you should apply that patch to utils-linux package available in the utilities directory at http://kernel.org.
Warning:, the patch does not apply cleanly and you will have to manually apply the patches to losetup and mount in the mount subdir of utils-linux-2.11z When you first apply the patch, it will give you a couple of *.rej files in /mount, you need to manually copy them in to patch the files.
If you have trouble with the patching, I'll email you a copy of the patched files.
Once that is done, your error should go away.
That really sounds encouraging. When I saw that you compiled the kernel and, just like that, had it working, I was beginning to wonder if maybe the problem originated outside the kernel. I'll try to look into the patching of losetup in the next couple of days.
Great, thanks Bo
-
Bo Jacobsen -
zentara