Ok, I had a look at the code. The problem seems to happen
in PBKDF2_performance_check. This seems to run PBKDF2
until 1 sec of CPU time has been consumed and then
terminates, reporting the iteration count.
One potential implementation error I see is that in line 204,
__PBKDF2_performance being non-zero is used as termination
criterium, which in turn is set in the signal handler.
This is at least conceptually wrong, as it assumes
__PBKDF2_global_j is non-zero at the time the signal handler
is called. But whether this is true depends entirely on the
timing of PBKDF2. This should be fixed to use a flag
telling BKPDF2 that the signal handler has been called.
Otherwise the 1 second of CPU time being reached before one
PBKDF2 iteration is complete, will result in the benchmark
running forever? At least the iteration count variable
is an unsigned int set to -1 ...
I do not see how this can cause a segmentation fault, though.
The signal handler does a straight assignment between
two static volatile uint64_t variables, no pointers involved
at all.
Maybe some obscure compiler or linker problem?
Incidentially, this code was not changed in 1.1.2...
Arno
On Wed, Jul 07, 2010 at 10:19:55PM +0200, Arno Wagner wrote:
> On Wed, Jul 07, 2010 at 07:49:04PM +0200, Sven Eschenberg wrote:
> > Hummm,
> >
> > should I consider this geek humor or are you serious, the CPU is rather
> > slow (imho)?
>
> Par humor, part serious. But if the CPU is rather slow, then
> this is somethin else, I guess.
>
> > Anyway, tweaking the iterationcount didn't chaneg a thing, messing with
> > the params did not help either.
>
> Hmm.
>
> > The Backtrace does not really help a lot, I guess:
> >
> > (gdb) bt
> > #0 0x000000000040d3fe in sigvtalarm ()
> > #1 0x0f0000000fc0c748 in ?? ()
> > #2 0x0000000000000000 in ?? ()
> >
> > Well at least we know the crash happens in sigvtalarm, which I assume is
> > a signal handler of some sort within cryptsetup.
>
> Looks like it. SIGVTALARM is what you get when you set
> the ITIMER_VIRTUAL interval timer and it expires. YThe
> virtual timer is decremented only when the process runns
> that set it. Hence it can be used to measure (userspace)
> CPU time of a process. My guess would be that it is
> not supposed to expire and handling the SIGVTALARM
> somehow fails.
>
> Arno
>
>
>
>
>
> > Regards
> >
> > -Sven
> >
> > On Wed, 2010-07-07 at 19:36 +0200, Arno Wagner wrote:
> > > Just a guess: Your CPU is too fast, the time
> > > measurement for the PKBF2 iterations did not
> > > expect that and does nonesense, resutling in
> > > the segfault.
> > >
> > > Tht would be a classic ;-)
> > >
> > > Arno
> > >
> > > On Wed, Jul 07, 2010 at 07:19:38PM +0200, Sven Eschenberg wrote:
> > > > Hi list,
> > > >
> > > > I was just trying to setup a new luks device, and for some reason (I
> > > > cannot determine yet) cryptsetup just segfaults (setting up the old
> > > > mappings works as usual).
> > > >
> > > > These are the last couple lines before cryptsetup dies:
> > > > 2370 read(4, "|\27\211<e\263\36\35j\201j\204e\326 \270\364\277\373
> > > > \300LY[\343d[\215\32\17\315N\333", 32) = 32
> > > > 2370 open("/dev/md125", O_RDONLY) = 5
> > > > 2370 ioctl(5, BLKIOMIN, 0x7fff561ea000) = 0
> > > > 2370 ioctl(5, BLKIOOPT, 0x7fff561e9ff8) = 0
> > > > 2370 ioctl(5, BLKALIGNOFF, 0x7fff561ea00c) = 0
> > > > 2370 close(5) = 0
> > > > 2370 read(4, "\242\270\205|\207@\253\227 \321)\f\r/\"R>EN(wo\224\205\7e
> > > > \36\313g\232\n\33", 32) = 32
> > > > 2370 rt_sigaction(SIGVTALRM, {0x40d3f0, [VTALRM], SA_RESTORER|
> > > > SA_RESTART, 0xf0000000fc0c748}, {SIG_DFL, [], 0}, 8) = 0
> > > > 2370 setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={1, 0}},
> > > > NULL) = 0
> > > > 2370 --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
> > > > 2370 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > > > 2370 +++ killed by SIGSEGV +++
> > > >
> > > > where /dev/md125 is the device I am trying to setup via luksFormat.
> > > >
> > > > Anyone with any suggestion what the problem can be?
> > > >
> > > > Oh I forgot:
> > > > cryptsetup --version
> > > > cryptsetup 1.1.2
> > > >
> > > > Regards
> > > >
> > > > -Sven
> > > >
> > > >
> > > > _______________________________________________
> > > > dm-crypt mailing list
> > > > dm-crypt@xxxxxxxx
> > > > http://www.saout.de/mailman/listinfo/dm-crypt
> > > >
> > >
> >
> >
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@xxxxxxxx
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
>
> --
> Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx
> GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
> ----
> Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
>
> If it's in the news, don't worry about it. The very definition of
> "news" is "something that hardly ever happens." -- Bruce Schneier
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt
>
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
