From ametzler at downhill.at.eu.org  Sat Mar  8 09:48:18 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 8 Mar 2008 09:48:18 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87fxwe4d0g.fsf@wheatstone.g10code.de>
References: <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
Message-ID: <20080308084818.GC3091@downhill.g.la>

On 2008-01-31 Werner Koch <wk at gnupg.org> wrote:
> On Wed, 30 Jan 2008 19:20, ametzler at downhill.at.eu.org said:

>> Any obvious breakage? Exim does not use any threading. I have not
>> included an gcry_check_version(NULL) since I thought gcry_control()
>> would fail as reliably as gcry_check_version() would, if gcrypt was

> Better insert a gcry_check_version because this is the safe way to
> initialize gcrypt.  The initialization is also done with most other
> gcry_control calls but that is a failsafe feature.  Explicitly
> initialization is better (you don't need to check the return code, just
> call it.)

Hello,

we still seem have not been able to find a really working solution,
this patch <http://svn.debian.org/wsvn/pkg-exim4/exim/trunk/debian/patches/65_saverandomseed.dpatch?op=file&rev=0&sc=0>
causes crashes in exim.

Quoting Marc Haber in http://bugs.exim.org/show_bug.cgi?id=654
| However, the secondary MX (which delivers some spam to the primary MX) noted
| that the primary box had become unreliable in TLS:
| 2008-01-30 14:51:21 1JKDKT-0003ME-AG Remote host mailgate.zugschlus.de
| [85.214.68.41] closed connection in response to STARTTLS
| 
| When this happened (a couple of times per hour), I didn't get any
| atypical log entries on mailgate.
| 
| This was a repeating, but intermittent failure since mailgate
| continued to work normally, and STARTTLS was successful most of the
| time.
[...]
| Going back to the same exim sans the random-seed patch, entropy
| average went back to 200, but the STARTTLS failures vanished.

We have tried to isolate what actually breaks, by only applying parts
of the patch (e.g setting up dthe seed file, but not updating it.),
but it looks like the mere presence of
gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
causes the crashes.

I am really wondering whether using the experimental daemon might be
worthwile, there does not seem to be much cost involved, and
/dev/(u)random has not got any policy controls either.
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From simon at josefsson.org  Sat Mar  8 10:44:13 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 08 Mar 2008 10:44:13 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080308084818.GC3091@downhill.g.la> (Andreas Metzler's message
	of "Sat, 8 Mar 2008 09:48:18 +0100")
References: <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la>
Message-ID: <87k5kdblea.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2008-01-31 Werner Koch <wk at gnupg.org> wrote:
>> On Wed, 30 Jan 2008 19:20, ametzler at downhill.at.eu.org said:
>
>>> Any obvious breakage? Exim does not use any threading. I have not
>>> included an gcry_check_version(NULL) since I thought gcry_control()
>>> would fail as reliably as gcry_check_version() would, if gcrypt was
>
>> Better insert a gcry_check_version because this is the safe way to
>> initialize gcrypt.  The initialization is also done with most other
>> gcry_control calls but that is a failsafe feature.  Explicitly
>> initialization is better (you don't need to check the return code, just
>> call it.)
>
> Hello,
>
> we still seem have not been able to find a really working solution,
> this patch <http://svn.debian.org/wsvn/pkg-exim4/exim/trunk/debian/patches/65_saverandomseed.dpatch?op=file&rev=0&sc=0>
> causes crashes in exim.
>
> Quoting Marc Haber in http://bugs.exim.org/show_bug.cgi?id=654
> | However, the secondary MX (which delivers some spam to the primary MX) noted
> | that the primary box had become unreliable in TLS:
> | 2008-01-30 14:51:21 1JKDKT-0003ME-AG Remote host mailgate.zugschlus.de
> | [85.214.68.41] closed connection in response to STARTTLS
> | 
> | When this happened (a couple of times per hour), I didn't get any
> | atypical log entries on mailgate.
> | 
> | This was a repeating, but intermittent failure since mailgate
> | continued to work normally, and STARTTLS was successful most of the
> | time.
> [...]
> | Going back to the same exim sans the random-seed patch, entropy
> | average went back to 200, but the STARTTLS failures vanished.
>
> We have tried to isolate what actually breaks, by only applying parts
> of the patch (e.g setting up dthe seed file, but not updating it.),
> but it looks like the mere presence of
> gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
> causes the crashes.

Did you follow Werner's suggestion to the patch?  I.e., to call
gcry_check_version to initialize libgcrypt properly.

> I am really wondering whether using the experimental daemon might be
> worthwile, there does not seem to be much cost involved, and
> /dev/(u)random has not got any policy controls either.

I think doing whatever it takes to make libgcrypt return useful amounts
of entropy would be a good thing.  Forcing every application to set a
seed file is quite costly maintenance and documentation wise, so running
one libgcrypt-specific daemon may be simpler.

/Simon


From ametzler at downhill.at.eu.org  Sat Mar  8 11:11:51 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 8 Mar 2008 11:11:51 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87k5kdblea.fsf@mocca.josefsson.org>
References: <87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la>
	<87k5kdblea.fsf@mocca.josefsson.org>
Message-ID: <20080308101151.GD3091@downhill.g.la>

On 2008-03-08 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
[...]
> > We have tried to isolate what actually breaks, by only applying parts
> > of the patch (e.g setting up dthe seed file, but not updating it.),
> > but it looks like the mere presence of
> > gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
> > causes the crashes.

> Did you follow Werner's suggestion to the patch?  I.e., to call
> gcry_check_version to initialize libgcrypt properly.

Yes, we did.
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ametzler at downhill.at.eu.org  Mon Mar 10 19:24:52 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 10 Mar 2008 19:24:52 +0100
Subject: How experimental is --enable-random-daemon?
Message-ID: <k0bga5-2n3.ln1@argenau.downhill.at.eu.org>

Hello,

since using a random seed file for exim does not work reliably with
the (perhaps broken) patch 
<http://news.gmane.org/find-root.php?message_id=%3c20080308084818.GC3091%5f%5f12928.1525886201%241204966999%24gmane%24org%40downhill.g.la%3e>
I am considering the other easy way, using --enable-random-daemon.

However I am unsure on whether --enable-random-daemon will eat small
children or whether it simply is not built by default but should work
alright. Would you outright recommed against using it in production
environments?

Other stuff I have been wondering about:

- A pid file would be nice.
- Why isn't the daemon used by default if specified at compile time?
  Needing to patch every gcrypt using application (or at least
  libgnutls) to get best benefits seems to be suboptimal.
  gcry_control (GCRYCTL_USE_RANDOM_DAEMON, 1)

thanks, cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



From wk at gnupg.org  Tue Mar 11 17:01:03 2008
From: wk at gnupg.org (Werner Koch)
Date: Tue, 11 Mar 2008 17:01:03 +0100
Subject: How experimental is --enable-random-daemon?
In-Reply-To: <k0bga5-2n3.ln1@argenau.downhill.at.eu.org> (Andreas Metzler's
	message of "Mon, 10 Mar 2008 19:24:52 +0100")
References: <k0bga5-2n3.ln1@argenau.downhill.at.eu.org>
Message-ID: <87skyxi728.fsf@wheatstone.g10code.de>

On Mon, 10 Mar 2008 19:24, ametzler at downhill.at.eu.org said:

> alright. Would you outright recommed against using it in production
> environments?

I wrote it once but did not gave it proper testing.  In case it helps
with exim it should be better than nothing.

> - A pid file would be nice.

Noted.

> - Why isn't the daemon used by default if specified at compile time?
>   Needing to patch every gcrypt using application (or at least
>   libgnutls) to get best benefits seems to be suboptimal.
>   gcry_control (GCRYCTL_USE_RANDOM_DAEMON, 1)

It is not matured enough and it gives a new option to snoop on the
random numbers, namely the socket used for the connection.  I would not
use it for key generation or other critical appications.  For Exim use
it should be fine and you should enable this only within Exim.

However, I would prefer to see why the patch crashes Exim.  I have not
yet looked at it, though.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From wk at gnupg.org  Tue Mar 11 17:09:19 2008
From: wk at gnupg.org (Werner Koch)
Date: Tue, 11 Mar 2008 17:09:19 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080308084818.GC3091@downhill.g.la> (Andreas Metzler's message
	of "Sat, 8 Mar 2008 09:48:18 +0100")
References: <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la>
Message-ID: <87od9li6og.fsf@wheatstone.g10code.de>

On Sat,  8 Mar 2008 09:48, ametzler at downhill.at.eu.org said:

> but it looks like the mere presence of
> gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
> causes the crashes.

That should be easy to debug:

  void
  _gcry_set_random_seed_file( const char *name )
  {
    if (seed_file_name)
      BUG ();
    seed_file_name = gcry_xstrdup (name);
  }

I guess you are running the init code twice.  Isn't there any output to
stderr?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From ametzler at downhill.at.eu.org  Wed Mar 12 20:20:44 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 12 Mar 2008 20:20:44 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87od9li6og.fsf@wheatstone.g10code.de>
References: <87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la>
	<87od9li6og.fsf@wheatstone.g10code.de>
Message-ID: <20080312192044.GA3513@downhill.g.la>

On 2008-03-11 Werner Koch <wk at gnupg.org> wrote:
> On Sat,  8 Mar 2008 09:48, ametzler at downhill.at.eu.org said:

> > but it looks like the mere presence of
> > gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
> > causes the crashes.

> That should be easy to debug:

>   void
>   _gcry_set_random_seed_file( const char *name )
>   {
>     if (seed_file_name)
>       BUG ();
>     seed_file_name = gcry_xstrdup (name);
>   }

> I guess you are running the init code twice.  Isn't there any output to
> stderr?

Hello,
The exim daemon forks and closes stderr/out. Marc, can you try running
exim in the foreground and check whether gcrypt throws an error
(case GCRY_LOG_BUG:   fputs("Ohhhh jeeee: ", stderr); break;)?

thanks, cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From mh+debian-bugs at zugschlus.de  Wed Mar 12 21:16:30 2008
From: mh+debian-bugs at zugschlus.de (Marc Haber)
Date: Wed, 12 Mar 2008 21:16:30 +0100
Subject: [Pkg-gnutls-maint] Bug#448775: Uses too much entropy (Debian Bug
	#343085)
In-Reply-To: <20080312192044.GA3513@downhill.g.la>
References: <87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la>
	<87od9li6og.fsf@wheatstone.g10code.de>
	<20080312192044.GA3513@downhill.g.la>
Message-ID: <20080312201630.GE20186@torres.zugschlus.de>

On Wed, Mar 12, 2008 at 08:20:44PM +0100, Andreas Metzler wrote:
> The exim daemon forks and closes stderr/out. Marc, can you try running
> exim in the foreground and check whether gcrypt throws an error
> (case GCRY_LOG_BUG:   fputs("Ohhhh jeeee: ", stderr); break;)?

Yes, it does.

$ sudo exim -bdf -q30m -oX 587:465:25 -oP /var/run/exim4/exim.pid
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


From fweimer at bfk.de  Thu Mar 13 09:32:17 2008
From: fweimer at bfk.de (Florian Weimer)
Date: Thu, 13 Mar 2008 09:32:17 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080308084818.GC3091@downhill.g.la> (Andreas Metzler's message
	of "Sat, 8 Mar 2008 09:48:18 +0100")
References: <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la>
Message-ID: <82fxuvyqge.fsf@mid.bfk.de>

* Andreas Metzler:

> we still seem have not been able to find a really working solution,
> this patch <http://svn.debian.org/wsvn/pkg-exim4/exim/trunk/debian/patches/65_saverandomseed.dpatch?op=file&rev=0&sc=0>
> causes crashes in exim.

IIRC, I have already posted this, but perhaps my wording was a bit
unclear.

I don't think the seed file approach works for a forking daemon like
Exim because you cannot guaranteed an undisturbed read/modify/write
cycle on the seed file.  Locking is out of the question, too, because
it would bring the mail system to a standstill.  And it's arguably not
a good idea to reuse the same seed file in different forked children.

You need a separate daemon, or trust the kernel and read fewer bytes
from /dev/urandom.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From wk at gnupg.org  Thu Mar 13 13:55:47 2008
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Mar 2008 13:55:47 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <82fxuvyqge.fsf@mid.bfk.de> (Florian Weimer's message of "Thu, 13
	Mar 2008 09:32:17 +0100")
References: <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la> <82fxuvyqge.fsf@mid.bfk.de>
Message-ID: <871w6eg4vg.fsf@wheatstone.g10code.de>

On Thu, 13 Mar 2008 09:32, fweimer at bfk.de said:

> I don't think the seed file approach works for a forking daemon like
> Exim because you cannot guaranteed an undisturbed read/modify/write
> cycle on the seed file.  Locking is out of the question, too, because

It depends on how much entropy you want to have in the pool.  Even with
all processes using the same random seed, libgcrypt will add extra
random to each process (e.g. 16 bytes from /dev/urandom).  This turns it
into a PRNG which is not worse than using /dev/urandom directly.

The advantage reading a the seed file is that libgcrypt does not need to
initialize its own random pool.  You may view this initialization as
assuring that the random pool is not plain zeroed out.

If you don't like that approach you cat limit the reuse of the seed file
by using a seed file name depending on the pid, like
 asprintf ("/foo/bar/andom_seed.%d", ((int)getpid() % 5))


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From wk at gnupg.org  Mon Mar 17 19:23:28 2008
From: wk at gnupg.org (Werner Koch)
Date: Mon, 17 Mar 2008 19:23:28 +0100
Subject: Improved AES performance
Message-ID: <878x0h5hwf.fsf@wheatstone.g10code.de>

Hi!

I hacked libgcrypt a bit to see how to increase the symmetrical cipher
performance.  This should benefit all architecture except for Padlock,
which I have not yet changed.  

The current SVN has the changes for AES in CFB and CBC mode.  On my box
it gives about 25% speedup with the benchmark tool.  That tool has two
new options:

  --large-buffers 
                  passes larger blocks of data to the encryption function
                  and reduces the loop count instead.

  --cipher-repetitions N  
                  may be used to increase the loop count by a factor N.
                  This is gives more accurate timings on fas machines.

Example usage:

  tests/benchmark --cipher-repetition 10 cipher aes aes192 aes256


I did a real work test with gpg2 on a 2.9GB MPEG file.  First a plain
store operation to see the I/O overhead.

  $ time gpg2 --store -z0 -v --batch --passphrase 'test'\
            <video/Rockpalast-The_Who.mpg >/dev/null
  gpg: writing to stdout
  
  real    1m47.123s
  user    0m5.112s
  sys     0m5.232s

So this gives us a mere 5 seconds.  Now with AES-128 using a stock
libgcrypt 1.4.0:
  
  $ time gpg2 -c --cipher aes  -z0 -v --batch --passphrase 'test' \
            <video/Rockpalast-The_Who.mpg >/dev/null
  gpg: using cipher AES
  gpg: writing to stdout
  
  real    3m58.025s
  user    2m53.814s
  sys     0m5.968s
  
Yields 73 seconds.  Again with the latest libgcrypt:

  $ time gpg2 -c --cipher aes  -z0 -v --batch --passphrase 'test' \
            <video/Rockpalast-The_Who.mpg >/dev/null
  gpg: using cipher AES
  gpg: writing to stdout
  
  real    3m22.304s
  user    2m19.503s
  sys     0m5.852s

Yields 139 seconds.  Comparing the corrected user times

 173 - 5 = 168
 139 - 5 = 134 

shows that encryption is about 25% faster in CFB mode.
  


Salam-Shalom,

   Werner

  
-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From simon at josefsson.org  Mon Mar 17 23:50:54 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 17 Mar 2008 23:50:54 +0100
Subject: Improved AES performance
In-Reply-To: <878x0h5hwf.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Mon, 17 Mar 2008 19:23:28 +0100")
References: <878x0h5hwf.fsf@wheatstone.g10code.de>
Message-ID: <87abkxufqp.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> Hi!
>
> I hacked libgcrypt a bit to see how to increase the symmetrical cipher
> performance.  This should benefit all architecture except for Padlock,
> which I have not yet changed.  
>
> The current SVN has the changes for AES in CFB and CBC mode.  On my box
> it gives about 25% speedup with the benchmark tool.  That tool has two
> new options:
>
>   --large-buffers 
>                   passes larger blocks of data to the encryption function
>                   and reduces the loop count instead.
>
>   --cipher-repetitions N  
>                   may be used to increase the loop count by a factor N.
>                   This is gives more accurate timings on fas machines.

Does applications using libgcrypt (i.e., gnutls) need to do anything to
take advantage of this speedup?

I'll see if I can measure any difference in my gnutls benchmarks.

/Simon


From gcrypt at dstoecker.de  Wed Mar 19 12:58:39 2008
From: gcrypt at dstoecker.de (Dirk Stoecker)
Date: Wed, 19 Mar 2008 12:58:39 +0100 (CET)
Subject: A little cleanup for SVN 1283
Message-ID: <alpine.LNX.1.10.0803191219510.5926@mudge.stoecker.eu>

Hello,

I attached a little patch for libgcrypt SVN version 1283.

This patch fixes:

- #ifdef/#if Problems
- Missing free's
- include interlinking

The changes are pretty self-explaining and straightforward.

I hereby declare that this patch is Public Domain and may be used and 
relicensed by everybody in any form.

Do with it whatever you want.

P.S. Please surround all the "#include <config.h>" by
"#ifdef HAVE_CONFIG_H". This does no harm for autoconf version, but allows 
to use the files outside autoconf environment.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cleanup.patch
Type: text/x-patch
Size: 18360 bytes
Desc: 
URL: </pipermail/attachments/20080319/2008ecd0/attachment-0001.bin>

From wk at gnupg.org  Wed Mar 19 15:04:44 2008
From: wk at gnupg.org (Werner Koch)
Date: Wed, 19 Mar 2008 15:04:44 +0100
Subject: A little cleanup for SVN 1283
In-Reply-To: <alpine.LNX.1.10.0803191219510.5926@mudge.stoecker.eu> (Dirk
	Stoecker's message of "Wed, 19 Mar 2008 12:58:39 +0100 (CET)")
References: <alpine.LNX.1.10.0803191219510.5926@mudge.stoecker.eu>
Message-ID: <87myou24jn.fsf@wheatstone.g10code.de>

On Wed, 19 Mar 2008 12:58, gcrypt at dstoecker.de said:

> The changes are pretty self-explaining and straightforward.

Unfortunately this is not the case; please explain the the changes.

> I hereby declare that this patch is Public Domain and may be used and
> relicensed by everybody in any form.

For a GNU project this is not sufficient; we need to do do some paper
work.

> P.S. Please surround all the "#include <config.h>" by
> "#ifdef HAVE_CONFIG_H". This does no harm for autoconf version, but
> allows to use the files outside autoconf environment.

That is not a good idea.  To do this we would need to figure out what
macros are used by that file and clearly docuemntthis.  Without that the
code may or may not work.  In most cases config.h is an integral part of
the file.


Some notes or questions:

  --- mpi/Makefile.am	(Revision 1283)
  +++ mpi/Makefile.am	(Arbeitskopie)
  @@ -21,9 +21,7 @@
   # I was not able to build it with 64Megs - 1.6 fixes this.
   # not anymore required: AUTOMAKE_OPTIONS = 1.6
   
  -# Need to include ../src in addition to top_srcdir because gcrypt.h is
  -# a built header.
  -AM_CPPFLAGS = -I../src -I$(top_srcdir)/src
  +AM_CPPFLAGS = -I$(top_srcdir)/src -I$(top_srcdir)/mpi
   AM_CFLAGS = $(GPG_ERROR_CFLAGS)

As stated in the comment ../src is required.  Think of VPATH builds.

  --- src/gcrypt.h.in	(Revision 1283)
  +++ src/gcrypt.h.in	(Arbeitskopie)
  @@ -41,6 +41,8 @@
   
   #include <sys/time.h>
   
  +struct msghdr;

You can't do that.  If your system does not provide the declaration in a
system header as included by gcrypt.h, the correct solution is to do a
configure tests ala FALLBACK_SOCKLEN_T.

  --- src/g10lib.h	(Revision 1283)
  +++ src/g10lib.h	(Arbeitskopie)
  @@ -25,10 +25,6 @@
   #ifndef G10LIB_H
   #define G10LIB_H 1
   
  -#ifdef _GCRYPT_H
  -#error  gcrypt.h already included
  -#endif

Why?  This is on purpose.

  --- src/mpi.h	(Revision 1283)
  +++ src/mpi.h	(Arbeitskopie)
  @@ -28,11 +28,11 @@
   #ifndef G10_MPI_H
   #define G10_MPI_H
   
   #include <config.h>
   #include <stdio.h>
   #include "types.h"
   #include "memory.h"
  -#include "../mpi/mpi-asm-defs.h"
  +#include "mpi-asm-defs.h"

I can't see a reasosn for this change.
   
  --- src/Makefile.am	(Revision 1283)
  +++ src/Makefile.am	(Arbeitskopie)
  @@ -20,6 +20,7 @@
   
   ## Process this file with automake to produce Makefile.in
   
  +INCLUDES = -I$(top_srcdir)/mpi

Please explain the problem.

  --- tests/pubkey.c	(Revision 1283)
  +++ tests/pubkey.c	(Arbeitskopie)
  @@ -125,6 +125,7 @@
     /* Extract data from plaintext.  */
     l = gcry_sexp_find_token (plain0, "value", 0);
     x0 = gcry_sexp_nth_mpi (l, 1, GCRYMPI_FMT_USG);
  +  gcry_sexp_release (l);

Well, yes we could do that.  Howerver this regression test is not here
to tests allocatins ;-).  For the other test it is a bit too hard to see
from the diffs what you are going to change.  Anyway, these are
regression tests and thus we can't change an existing test because that
one tests existing behaviour.  Always add new tests if you want to test
more.

  --- tests/ac-schemes.c (Revision 1283)
  +++ tests/ac-schemes.c	(Arbeitskopie)
  @@ -320,6 +320,14 @@
         es_checks (handle, key_public, key_secret);
         ssa_checks (handle, key_public, key_secret);
       }
  +
  +  if(handle)
  +    gcry_ac_close (handle);
  +
  +  if(key_secret)
  +    gcry_ac_key_destroy (key_secret);
  +  if(key_public)
  +    gcry_ac_key_destroy (key_public);
 
Alright, you figured one spot.  However there is bunch of more problems
in the ac fucntions and worst of all no clear concept of ownership.  I
once started to fix that but gave up and it is likely that the ac stuff
will eventually be removed.  See the manual:

  @strong{This interface has a few known problems; most noteworthy an
  inherent tendency to leak memory.  It might not be available in
  forthcoming versions Libgcrypt.}

  --- doc/Makefile.am	(Revision 1283)
  +++ doc/Makefile.am	(Arbeitskopie)
  @@ -33,3 +33,7 @@
   	  $${user}@cvs.gnupg.org:$${dir} ); \
           rsync -v gcrypt.pdf gcrypt.info $${user}@cvs.gnupg.org:$${dir}
   
  +gcrypt.info: version.texi
  +
  +version.texi: stamp-vti
  +

Automake already handles this.  No need to add it to Makefile.am

  -#ifdef USE_ELGAMAL
  +#if USE_ELGAMAL

Why? It is either defined or not.  Autoconf also make sure that it is
never defined to 0 thus it is only a matter of style what to use.

  --- cipher/cipher.c	(Revision 1283)
  +++ cipher/cipher.c	(Arbeitskopie)
  @@ -747,6 +749,7 @@
   	  h->mode = mode;
   	  h->flags = flags;
   
  +#if USE_AES
             /* Setup bulk encryption routines.  */
             switch (algo)
               {
  @@ -762,6 +765,7 @@
               default:
                 break;
               }
  +#endif /* USE_AES */

Good catch.

  --- cipher/rndegd.c	(Revision 1283)
  +++ cipher/rndegd.c	(Arbeitskopie)
  @@ -27,8 +29,8 @@
   #include <string.h>
   #include <unistd.h>
   #include <sys/types.h>
  -#include <sys/socket.h>
  -#include <sys/un.h>
  +/*#include <sys/un.h>*/
  +#include "gcrypt.h"

Why?


         /* Store named MPI in data_set_new.  */
  -      err = gcry_ac_data_set (data_set_new, GCRY_AC_FLAG_DEALLOC, string, mpi);
  +      err = gcry_ac_data_set (data_set_new, GCRY_AC_FLAG_COPY |
  +                              GCRY_AC_FLAG_DEALLOC, string, mpi);

I appreciate the work you did to fix the ac problems.  However I doubt
that it will eventually succeeed. See above.




Salam-Shalom,

   Werner
   
  


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From gcrypt at dstoecker.de  Wed Mar 19 16:05:34 2008
From: gcrypt at dstoecker.de (Dirk Stoecker)
Date: Wed, 19 Mar 2008 16:05:34 +0100 (CET)
Subject: A little cleanup for SVN 1283
In-Reply-To: <87myou24jn.fsf@wheatstone.g10code.de>
References: <alpine.LNX.1.10.0803191219510.5926@mudge.stoecker.eu>
	<87myou24jn.fsf@wheatstone.g10code.de>
Message-ID: <alpine.LNX.1.10.0803191530420.3919@mudge.stoecker.eu>

Hello,

>> P.S. Please surround all the "#include <config.h>" by
>> "#ifdef HAVE_CONFIG_H". This does no harm for autoconf version, but
>> allows to use the files outside autoconf environment.
>
> That is not a good idea.  To do this we would need to figure out what
> macros are used by that file and clearly docuemntthis.  Without that the
> code may or may not work.  In most cases config.h is an integral part of
> the file.

No. Why do you want care for any other macro?

HAVE_CONFIG_H only means, that a file config.h can be included or not. In 
case HAVE_CONFIG_H is not set, the configuration must be supplied using 
other means (e.g. defines in project configuration settings).

Not using HAVE_CONFIG_H prevents these other means and restricts the whole 
system to a config.h. Actually this is exactly what I do under Windows. I 
have the definitions in the project configuration.

> Some notes or questions:
>
>  --- mpi/Makefile.am	(Revision 1283)
>  +++ mpi/Makefile.am	(Arbeitskopie)
>  @@ -21,9 +21,7 @@
>   # I was not able to build it with 64Megs - 1.6 fixes this.
>   # not anymore required: AUTOMAKE_OPTIONS = 1.6
>
>  -# Need to include ../src in addition to top_srcdir because gcrypt.h is
>  -# a built header.
>  -AM_CPPFLAGS = -I../src -I$(top_srcdir)/src
>  +AM_CPPFLAGS = -I$(top_srcdir)/src -I$(top_srcdir)/mpi
>   AM_CFLAGS = $(GPG_ERROR_CFLAGS)
>
> As stated in the comment ../src is required.  Think of VPATH builds.

All this goes together with the Makefile.am changes.
The "-I$(top_srcdir)/mpi" allows including mpi-files. This goes together 
with the removal of "../mpi/" below.
The part ../src is obsolete. This is and must be equal to "$(top_srcdir)", 
as ".." is what $(top_srcdir) is. And this is included.

>  --- src/gcrypt.h.in	(Revision 1283)
>  +++ src/gcrypt.h.in	(Arbeitskopie)
>  @@ -41,6 +41,8 @@
>
>   #include <sys/time.h>
>
>  +struct msghdr;
>
> You can't do that.  If your system does not provide the declaration in a
> system header as included by gcrypt.h, the correct solution is to do a
> configure tests ala FALLBACK_SOCKLEN_T.

This is a normal C forward declaration, which is perfectly valid. Don't 
know the reason, where I required this. Probably Windows again. Maybe the 
reason is gone already.

>  --- src/g10lib.h	(Revision 1283)
>  +++ src/g10lib.h	(Arbeitskopie)
>  @@ -25,10 +25,6 @@
>   #ifndef G10LIB_H
>   #define G10LIB_H 1
>
>  -#ifdef _GCRYPT_H
>  -#error  gcrypt.h already included
>  -#endif
>
> Why?  This is on purpose.

It was. This is a legacy test. gcrypt.h and g10lib.h have no longer 
conflicts.

>  --- src/mpi.h	(Revision 1283)
>  +++ src/mpi.h	(Arbeitskopie)
>  @@ -28,11 +28,11 @@
>   #ifndef G10_MPI_H
>   #define G10_MPI_H
>
>   #include <config.h>
>   #include <stdio.h>
>   #include "types.h"
>   #include "memory.h"
>  -#include "../mpi/mpi-asm-defs.h"
>  +#include "mpi-asm-defs.h"
>
> I can't see a reasosn for this change.

See above. No absolute path, but instead of this proper include 
definitions. This ../mpi/ is an ugly fix for the fact, that mpi was not 
included in the include parts of Makefile.am.

>  --- src/Makefile.am	(Revision 1283)
>  +++ src/Makefile.am	(Arbeitskopie)
>  @@ -20,6 +20,7 @@
>
>   ## Process this file with automake to produce Makefile.in
>
>  +INCLUDES = -I$(top_srcdir)/mpi
>
> Please explain the problem.

Again the same. All of the makefile.am changes cleanup the build to use 
proper definitions. There is no longer any need for "../" paths, which 
makes different building easier.

>  --- tests/pubkey.c	(Revision 1283)
>  +++ tests/pubkey.c	(Arbeitskopie)
>  @@ -125,6 +125,7 @@
>     /* Extract data from plaintext.  */
>     l = gcry_sexp_find_token (plain0, "value", 0);
>     x0 = gcry_sexp_nth_mpi (l, 1, GCRYMPI_FMT_USG);
>  +  gcry_sexp_release (l);
>
> Well, yes we could do that.  Howerver this regression test is not here
> to tests allocatins ;-).  For the other test it is a bit too hard to see
> from the diffs what you are going to change.  Anyway, these are
> regression tests and thus we can't change an existing test because that
> one tests existing behaviour.  Always add new tests if you want to test
> more.

It is wrong. You don't release the memory. Usually this will do no harm, 
but a test must be correct. Errors in test must be fixed as any normal 
errors. Especially as the tests are very likely used as user 
implementation examples.

You will be happy about it, whenever memory tracking tests will be added 
(which is what I did with the tests).

>  --- tests/ac-schemes.c (Revision 1283)
>  +++ tests/ac-schemes.c	(Arbeitskopie)
>  @@ -320,6 +320,14 @@
>         es_checks (handle, key_public, key_secret);
>         ssa_checks (handle, key_public, key_secret);
>       }
>  +
>  +  if(handle)
>  +    gcry_ac_close (handle);
>  +
>  +  if(key_secret)
>  +    gcry_ac_key_destroy (key_secret);
>  +  if(key_public)
>  +    gcry_ac_key_destroy (key_public);
>
> Alright, you figured one spot.  However there is bunch of more problems
> in the ac fucntions and worst of all no clear concept of ownership.  I
> once started to fix that but gave up and it is likely that the ac stuff
> will eventually be removed.  See the manual:

Well, same as above. Freeing memory only.

>  --- doc/Makefile.am	(Revision 1283)
>  +++ doc/Makefile.am	(Arbeitskopie)
>  @@ -33,3 +33,7 @@
>   	  $${user}@cvs.gnupg.org:$${dir} ); \
>           rsync -v gcrypt.pdf gcrypt.info $${user}@cvs.gnupg.org:$${dir}
>
>  +gcrypt.info: version.texi
>  +
>  +version.texi: stamp-vti
>  +
>
> Automake already handles this.  No need to add it to Makefile.am

Then the problem lies elsewhere. Without this the docs do not build from 
scratch.

>  -#ifdef USE_ELGAMAL
>  +#if USE_ELGAMAL
>
> Why? It is either defined or not.  Autoconf also make sure that it is
> never defined to 0 thus it is only a matter of style what to use.

That is not true. The file config.h defines the values to 0 when disabled.
Maybe that behaviour changed during autoconf/automake development, but now
USE_ELGAMAL is always defined.

>  --- cipher/rndegd.c	(Revision 1283)
>  +++ cipher/rndegd.c	(Arbeitskopie)
>  @@ -27,8 +29,8 @@
>   #include <string.h>
>   #include <unistd.h>
>   #include <sys/types.h>
>  -#include <sys/socket.h>
>  -#include <sys/un.h>
>  +/*#include <sys/un.h>*/
>  +#include "gcrypt.h"
>
> Why?

sys.un.h is not required. gcrypt.h does WIN32 handling for <sys/socket.h>.
Optional would be:
#ifdef _WIN32
#include <windows.h>
#else
#include <sys/types.h>
#include <sys/socket.h>
#endif

>         /* Store named MPI in data_set_new.  */
>  -      err = gcry_ac_data_set (data_set_new, GCRY_AC_FLAG_DEALLOC, string, mpi);
>  +      err = gcry_ac_data_set (data_set_new, GCRY_AC_FLAG_COPY |
>  +                              GCRY_AC_FLAG_DEALLOC, string, mpi);
>
> I appreciate the work you did to fix the ac problems.  However I doubt
> that it will eventually succeeed. See above.

I fixed bugs I found to get stuff working. I didn't care if these is 
legacy or not. Bug is bug. If it is removed in the future, who cares, but 
until then it is fixed.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)


From wk at gnupg.org  Wed Mar 19 20:01:03 2008
From: wk at gnupg.org (Werner Koch)
Date: Wed, 19 Mar 2008 20:01:03 +0100
Subject: A little cleanup for SVN 1283
In-Reply-To: <alpine.LNX.1.10.0803191530420.3919@mudge.stoecker.eu> (Dirk
	Stoecker's message of "Wed, 19 Mar 2008 16:05:34 +0100 (CET)")
References: <alpine.LNX.1.10.0803191219510.5926@mudge.stoecker.eu>
	<87myou24jn.fsf@wheatstone.g10code.de>
	<alpine.LNX.1.10.0803191530420.3919@mudge.stoecker.eu>
Message-ID: <87myouy1w0.fsf@wheatstone.g10code.de>

On Wed, 19 Mar 2008 16:05, gcrypt at dstoecker.de said:

> HAVE_CONFIG_H only means, that a file config.h can be included or

Right.  But you don't have a choice in libgcrypt.  There we demand that
the config.h as created by configure needs to there.  It is a part of
the code.  If you don't want that, you are on your own and then, if you
like, add @ifdef HAVE_CONFIG_H.

> whole system to a config.h. Actually this is exactly what I do under
> Windows. I have the definitions in the project configuration.

I am sorry, for you, but we use a different build system and as I have
said hundreds of times, building on Windows is not supported.  A sed or awk
script to add the #ifdef HAVE_CONFIG_H si straightforward to implement
but in that case it would be easier to provide a condig.h (even if empty).

> All this goes together with the Makefile.am changes.
> The "-I$(top_srcdir)/mpi" allows including mpi-files. This goes
> together with the removal of "../mpi/" below.

You are wrong.  The ../src is required for VPATH builds.  VPATH builds
are a Good Thing and actually required by the GNU standards and due to
"make distcheck".

> This is a normal C forward declaration, which is perfectly
> valid. Don't know the reason, where I required this. Probably Windows
> again. Maybe the reason is gone already.

It would clash with systems redefining msghdr using cpp tricks.

> See above. No absolute path, but instead of this proper include
> definitions. This ../mpi/ is an ugly fix for the fact, that mpi was
> not included in the include parts of Makefile.am.

The semantics are different with your change.

> Again the same. All of the makefile.am changes cleanup the build to
> use proper definitions. There is no longer any need for "../" paths,
> which makes different building easier.

Well, I want to use them. The directories are closely coupled and thus
it is better to express this with the file names.

> It is wrong. You don't release the memory. Usually this will do no
> harm, but a test must be correct. Errors in test must be fixed as any
> normal errors. Especially as the tests are very likely used as user
> implementation examples.

This is a regression tests.  By releasing the memory you change the test
and may not detect a regression.  Okay, this is a bit of a theoretical
argument but I currently don't have the resources to fix and test the
regression tests.  

> You will be happy about it, whenever memory tracking tests will be
> added (which is what I did with the tests).

These will be new tests.

> Well, same as above. Freeing memory only.

As told, the ac funmctions will go anyway.  They are seriously bugged.

>> Automake already handles this.  No need to add it to Makefile.am
>
> Then the problem lies elsewhere. Without this the docs do not build
> from scratch.

No problem here to bootstrap it. 

> That is not true. The file config.h defines the values to 0 when disabled.
> Maybe that behaviour changed during autoconf/automake development, but now
> USE_ELGAMAL is always defined.

You are right.  The configure tests are broken.  Probably we never build
without some algorithms for a long time.  I'll fix configure.

>>  -#include <sys/socket.h>
>>  -#include <sys/un.h>
>>  +/*#include <sys/un.h>*/
>>  +#include "gcrypt.h"
>>
>> Why?
>
> sys.un.h is not required. gcrypt.h does WIN32 handling for <sys/socket.h>.

POSIX requires sys/un.h as it defines struct sockaddr_un.  Windows is
irrelevant here.  If you want to run change the build system for
Windows, I suggest to provide an sys/un.h stub.

> I fixed bugs I found to get stuff working. I didn't care if these is
> legacy or not. Bug is bug. If it is removed in the future, who cares,
> but until then it is fixed.

First of all I am not sure whether this is the correct fix.  We have
identified several inconsistencies in ac module and found no way to
properly solve that without an API change.

Second, yes bugs are to be fixed.  But sometimes it is better not to fix
a bug if it would introduce a couple of new and unknown bugs.  A
maintainer's job is to overview the overall stability of a software and
not to fix bugs just because there is a bug.  In particular not if it is
in a part scheduled for removal.


Shalom-Salam,

   Werner



-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From farcaller at gmail.com  Mon Mar 31 14:46:44 2008
From: farcaller at gmail.com (Vladimir Pouzanov)
Date: Mon, 31 Mar 2008 12:46:44 +0000 (UTC)
Subject: compilation errors on iPhone
References: <55bc0b200709110709o51a3347ejb3821796bdf06b89@mail.gmail.com>
Message-ID: <loom.20080331T124448-388@post.gmane.org>

Britt Bolen <britt <at> bolen.com> writes:
>  /usr/local/arm-apple-darwin/bin/gcc -DHAVE_CONFIG_H -I. -I. -I..
> -I../src -I/usr/local/arm-apple-darwin/include -g -O2 -Wall -MT
> mpih-div.lo -MD -MP -MF .deps/mpih-div.Tpo -c mpih-div.c  -fno-common
> -DPIC -o .libs/mpih-div.o
> Bad $ operand number in inline asm string: '${:@} Inlined umul_ppmm
> umull ${1:r}, ${0:r}, ${2:r}, ${3:r}'
> make[2]: *** [mpih-div.lo] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2

iPhone toolchain's as doesn't like that % stuff in registers (sheesh, that's
apple-patched *gnu as*).

It does compile if rewritten this way:
  __asm__ (                                     \
           "umull r1, r0, r2, r3"                                   \
                   : "=&r" ((USItype)(xh)),                             \
                     "=r" ((USItype)(xl))                               \
                   : "r" ((USItype)(a)),                                \
                     "r" ((USItype)(b))                                 \
                   : "r0", "r1")

but later fails on:

/home/farcaller/develop/iphone/rootfs/home/farcaller/develop/iphone/toolchain/
lib/gcc/arm-apple-darwin/4.0.1/libgcc.a(_udivsi3.o)
has external relocation entries in non-writable section (__TEXT,__text) for
symbols:
___div0
collect2: ld returned 1 exit status



From simon at josefsson.org  Mon Mar 31 16:21:32 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 31 Mar 2008 16:21:32 +0200
Subject: compilation errors on iPhone
In-Reply-To: <55bc0b200709110709o51a3347ejb3821796bdf06b89@mail.gmail.com>
	(Britt Bolen's message of "Tue, 11 Sep 2007 10:09:08 -0400")
References: <55bc0b200709110709o51a3347ejb3821796bdf06b89@mail.gmail.com>
Message-ID: <87iqz3rn2r.fsf@mocca.josefsson.org>

"Britt Bolen" <britt at bolen.com> writes:

> I'm trying to build libgcrypt so that I can build vpnc on the iphone,
> but I'm running into a compilation/assembly error that I've not been
> able to solve.
>
>  /usr/local/arm-apple-darwin/bin/gcc -DHAVE_CONFIG_H -I. -I. -I..
> -I../src -I/usr/local/arm-apple-darwin/include -g -O2 -Wall -MT
> mpih-div.lo -MD -MP -MF .deps/mpih-div.Tpo -c mpih-div.c  -fno-common
> -DPIC -o .libs/mpih-div.o
> Bad $ operand number in inline asm string: '${:@} Inlined umul_ppmm
> umull ${1:r}, ${0:r}, ${2:r}, ${3:r}'
> make[2]: *** [mpih-div.lo] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> The iPhone is an arm processor, though I wasn't able to figure out how
> mpih-dev.c got the correct #defines to figure out which assembly macro
> was actually being called...
>
> anyhow, I was hoping to get some suggestions on workarounds or
> solutions so I can get this built.

Have you tried building with ./configure --disable-asm?

/Simon