From: Charles D. <cd...@sp...> - 2005-03-24 01:55:43
|
Using the luks-modified version of cryptsetup on coLinux 2.6.11-co-0.6.3-pre7 results in 14.5 minutes being spent for what should be a 1-second performance test. For the LUKS folks reading this message: Even though my belief is currently that this is a coLinux bug, it might be a useful feature to allow the user to specify number of iterations rather than amount of time spent hashing and be able to circumvent said testing altogether. An strace of the offending bits: --- from: strace -r cryptsetup --iter-time=10 luksInit /dev/cobd4 0.000242 rt_sigaction(SIGVTALRM, {0x40028460, [VTALRM], SA_RESTART}, {SIG_DFL}, 8) = 0 0.000190 setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={1, 0}}, NULL) = 0 870.138973 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- 0.000109 sigreturn() = ? (mask now []) ------ Spending 870 seconds (14'30") here strikes me as... well, broken, given that (as I read the code) the timer is being set to go off in 1 second. Using top, vmstat, etc. indicate that the CPU is spinning inside a syscall somewhere (the time is being allocated to sys, not usr). For the coLinux folks, the relevant code is quoted: --- from: cryptsetup-luks-0.993/luks/pbkdf.c static void sigvtalarm(int foo) { __PBKDF2_performance = ~(0U) - *__PBKDF2_global_j; *__PBKDF2_global_j = 0; } unsigned int PBKDF2_performance_check() { /* This code benchmarks PBKDF2 and returns iterations/second per SHA1_DIGEST_SIZE */ char buf; struct itimerval it; if(__PBKDF2_performance != 0) return __PBKDF2_performance; signal(SIGVTALRM,sigvtalarm); it.it_interval.tv_usec = 0; it.it_interval.tv_sec = 0; it.it_value.tv_usec = 0; it.it_value.tv_sec = 1; if (setitimer (ITIMER_VIRTUAL, &it, NULL) < 0) return 0; PBKDF2_HMAC_SHA1("foo", 3, "bar", 3, ~(0U), &buf, 1); return __PBKDF2_performance; } ------ coLinux folks: Any idea what might be going on here? LUKS folks: Any chance of a quick fix to circumvent the code in question? Thanks, all! |
From: Fruhwirth C. <cl...@en...> - 2005-03-24 09:52:48
|
On Wed, 2005-03-23 at 19:54 -0600, Charles Duffy wrote: > For the LUKS folks reading this message: Even though my belief is > currently that this is a coLinux bug, it might be a useful feature to > allow the user to specify number of iterations rather than amount of > time spent hashing and be able to circumvent said testing altogether. >=20 > An strace of the offending bits: >=20 > --- from: strace -r cryptsetup --iter-time=3D10 luksInit /dev/cobd4 > 0.000242 rt_sigaction(SIGVTALRM, {0x40028460, [VTALRM], SA_RESTART},= {SIG_DFL}, 8) =3D 0 > 0.000190 setitimer(ITIMER_VIRTUAL, {it_interval=3D{0, 0}, it_value= =3D{1, 0}}, NULL) =3D 0 > 870.138973 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- > 0.000109 sigreturn() =3D ? (mask now []) > ------ >=20 > Spending 870 seconds (14'30") here strikes me as... well, broken, given > that (as I read the code) the timer is being set to go off in 1 second. > Using top, vmstat, etc. indicate that the CPU is spinning inside a syscal= l > somewhere (the time is being allocated to sys, not usr). Can you attach gdb to the process, interrupt it, and issue a backtrace (bt) to show, what/where the process is doing? From the strace log, the process doesn't appear to be in a syscall.=20 > LUKS folks: Any chance of a quick fix to circumvent the code in question? I could add a marker to -i to distinguish between "seconds of iterations" and "number of iterations", but I'm not sure how the user is going to set the right magnitude for that value. Not even I know the performance of my box ..=20 I assume you can always dispatch the signal per hand.. but that's useless as the performance counters will be wrong.. --=20 Fruhwirth Clemens - http://clemens.endorphin.org=20 for robots: sp4...@en... |
From: Charles D. <cd...@sp...> - 2005-03-24 15:11:43
|
On Thu, 24 Mar 2005 10:51:59 +0100, Fruhwirth Clemens wrote: > Can you attach gdb to the process, interrupt it, and issue a backtrace > (bt) to show, what/where the process is doing? From the strace log, the > process doesn't appear to be in a syscall. This appears to be a heisenbug -- when started via gdb, the process finishes inside a few seconds. However, if I start it outside gdb and have gdb attach from a different window, I get the following on backtrace: PBKDF2_HMAC_SHA1 (password=0x804d2ac "<snipped>"PBKDsswordLen=32, salt=0xbfffecd8 "<snipped>", saltLen=32, iterations=5297336, dKey=0xbfffeae0 "<snipped>", dKeyLen=32) at XORblock.h:5 5 dst[j] = src1[j] ^ src2[j]; (gdb) bt #0 PBKDF2_HMAC_SHA1 (password=0x804d2ac "<snipped>", passwordLen=32, salt=0xbfffecd8, saltLen=32, iterations=5297336, dKey=0xbfffeae0 "<snipped>", dKeyLen=32) at XORblock.h:5 #1 0x40028ce0 in LUKS_set_key (device=0xbffff229 "/dev/cobd4", keyIndex=Variable "keyIndex" is not available. ) at keymanage.c:207 #2 0x400267aa in __crypt_luks_init (arg=0, backend=0x4002c018, options=Variable "options" is not available. ) at setup.c:503 #3 0x40025856 in crypt_job (job=Variable "job" is not available. ) at setup.c:636 #4 0x08049234 in action_luksInit (arg=0) at cryptsetup.c:185 #5 0x08049845 in main (argc=4, argv=0xbffff074) at cryptsetup.c:391 Dunno how interesting it is, but stepping up to frame #1, hdr->keyblock[0].passwordIterations = 5297337. I'd be curious to know whether this *is* the right order of magnitude for a 1-second operation vs a 15-minute one on the hardware in question. >> LUKS folks: Any chance of a quick fix to circumvent the code in question? > > I could add a marker to -i to distinguish between "seconds of > iterations" and "number of iterations", but I'm not sure how the user is > going to set the right magnitude for that value. Not even I know the > performance of my box .. I can experiment. Having a debug/verbose mode that prints out the results of the performance test (when it's run) might be useful, too. |
From: Nuno L. <li...@xp...> - 2005-03-30 00:26:20
|
I don't know what is happening here, but could this be related with using /dev/random instead of /dev/urandom ? Current colinux implementation doesn't have enough random events to continue to fill the kernel pool of random numbers (needed by /dev/random), so it blocks until it has enough random input (the user needs to keep typing something on the keyboard). A possible workaround (if not possible to use /dev/urandom instead) is to make /dev/random a symlink to /dev/urandom. The /dev/urandom random numbers generated are not so "random" as from /dev/random, but they are enough "random" for 99% of the cases - my made-up statistic, of course ;). Probably colinux will fix this by doing it anyway, so I don't think you will loose nothing (if security paranoia is your idea, then you shouldn't be using colinux anyway). A *NOT* tested fix to do it at kernel level could be by patching linux-2.6.11/drivers/char/random.c, line 1781, to something like this (hand-made patch, just for ilustration): <untested_hand_made_patch> --- drivers/char/random.c +++ drivers/char/random.c @@ -1779,7 +1779,7 @@ } struct file_operations random_fops = { - .read = random_read, + .read = urandom_read, .write = random_write, .poll = random_poll, .ioctl = random_ioctl, </untested_hand_made_patch> Hope it helps... Regards, ~Nuno Lucas Charles Duffy, dando pulos de alegria, escreveu : > On Thu, 24 Mar 2005 10:51:59 +0100, Fruhwirth Clemens wrote: > > >>Can you attach gdb to the process, interrupt it, and issue a backtrace >>(bt) to show, what/where the process is doing? From the strace log, the >>process doesn't appear to be in a syscall. > > > This appears to be a heisenbug -- when started via gdb, the process > finishes inside a few seconds. > > However, if I start it outside gdb and have gdb attach from a different > window, I get the following on backtrace: > > PBKDF2_HMAC_SHA1 (password=0x804d2ac "<snipped>"PBKDsswordLen=32, > salt=0xbfffecd8 "<snipped>", saltLen=32, iterations=5297336, > dKey=0xbfffeae0 "<snipped>", dKeyLen=32) > at XORblock.h:5 > 5 dst[j] = src1[j] ^ src2[j]; (gdb) bt #0 > PBKDF2_HMAC_SHA1 (password=0x804d2ac "<snipped>", passwordLen=32, > salt=0xbfffecd8, saltLen=32, iterations=5297336, dKey=0xbfffeae0 > "<snipped>", dKeyLen=32) > at XORblock.h:5 > #1 0x40028ce0 in LUKS_set_key (device=0xbffff229 "/dev/cobd4", > keyIndex=Variable "keyIndex" is not available. ) at keymanage.c:207 #2 > 0x400267aa in __crypt_luks_init (arg=0, backend=0x4002c018, > options=Variable "options" is not available. ) at setup.c:503 #3 > 0x40025856 in crypt_job (job=Variable "job" is not available. ) at > setup.c:636 > #4 0x08049234 in action_luksInit (arg=0) at cryptsetup.c:185 #5 > 0x08049845 in main (argc=4, argv=0xbffff074) at cryptsetup.c:391 > > Dunno how interesting it is, but stepping up to frame #1, > hdr->keyblock[0].passwordIterations = 5297337. I'd be curious to know > whether this *is* the right order of magnitude for a 1-second operation vs > a 15-minute one on the hardware in question. > > >>>LUKS folks: Any chance of a quick fix to circumvent the code in question? >> >>I could add a marker to -i to distinguish between "seconds of >>iterations" and "number of iterations", but I'm not sure how the user is >>going to set the right magnitude for that value. Not even I know the >>performance of my box .. > > > I can experiment. Having a debug/verbose mode that prints out the results > of the performance test (when it's run) might be useful, too. |