From: Milan Broz <mbroz@redhat.com>
To: Sven Eschenberg <sven@whgl.uni-frankfurt.de>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] crypsetup segfaulting during luksFormat
Date: Thu, 08 Jul 2010 16:16:18 +0200 [thread overview]
Message-ID: <4C35DDB2.6010803@redhat.com> (raw)
In-Reply-To: <1278596268.3147.56.camel@Koma-Station.localdomain>
On 07/08/2010 03:37 PM, Sven Eschenberg wrote:
> Just for the record:
>
> The crash happens with other gcc versions as well. As the gentoo bug
> report suggests, it seems to be a problem when the executeable is linked
> statically on hardened profiles.
> And yes, in my case compiling it dynamically resolves the segfault
> aswell.
I am compiling static version quite often, so hardened profile probably uses
some not common compiled switch for static version.
> In the src the following variables are used in the handler:
>
> static volatile uint64_t __PBKDF2_global_j = 0;
> static volatile uint64_t __PBKDF2_performance = 0;
>
> Since they are used in the sighandler, they would better not just be
> volatile but sig_atomic_t, to avoid possible races.
yes
> But this should not have any influence on the segfault as far as I can
> tell.
>
> Oh, and better use sigaction() instead of signal().
why? should be no problem here. (that code is ugly anyway, I just polished
it some time ago when replacing pbkdf2 with gcrypt version...)
> I think I possibly found the problem:
>
> In static int pkcs5_pbkdf2() in pbkdf.c:
>
> size_t tmplen = Slen + 4;
> tmp = alloca(tmplen); // allocate Slen+4 bytes on the stack ...
so problem is implicit type cast? interesting...
seems to be some relict from former implementation, I am always
trying to avoid alloca() in code... :)
(wonder if valgrind find that)
Thanks!
Milan
next prev parent reply other threads:[~2010-07-08 14:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-07 17:19 [dm-crypt] crypsetup segfaulting during luksFormat Sven Eschenberg
2010-07-07 17:36 ` Arno Wagner
2010-07-07 17:49 ` Sven Eschenberg
2010-07-07 20:19 ` Arno Wagner
2010-07-07 20:44 ` Milan Broz
2010-07-07 20:58 ` Sven Eschenberg
2010-07-07 21:22 ` Milan Broz
2010-07-08 2:22 ` Sven Eschenberg
2010-07-08 9:30 ` Arno Wagner
2010-07-08 13:37 ` Sven Eschenberg
2010-07-08 14:16 ` Milan Broz [this message]
2010-07-08 14:29 ` Sven Eschenberg
2010-07-08 15:11 ` Milan Broz
2010-07-08 18:44 ` Sven Eschenberg
2010-07-09 7:22 ` Milan Broz
2010-07-09 12:18 ` Sven Eschenberg
2010-07-09 12:46 ` Milan Broz
2010-07-14 18:14 ` Christoph Anton Mitterer
2010-07-14 18:24 ` Milan Broz
2010-07-14 18:56 ` Sven Eschenberg
2010-07-07 21:40 ` Milan Broz
2010-07-07 22:00 ` Arno Wagner
2010-07-08 2:13 ` Sven Eschenberg
2010-07-07 20:51 ` Arno Wagner
2010-07-07 18:36 ` Milan Broz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C35DDB2.6010803@redhat.com \
--to=mbroz@redhat.com \
--cc=dm-crypt@saout.de \
--cc=sven@whgl.uni-frankfurt.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.