gmane.comp.encryption.nettle.bugs

Re: arm compilation

Niels Möller — 2013-05-22T07:53:52


I see, I haven't tested --disable-static very much, and definitely not
in this setup. Then I should be able to reproduce the problem.

About the pre-v6 ARM problems, are those solved now?

Regards,
/Niels

Re: arm compilation

Nikos Mavrogiannopoulos — 2013-05-22T07:04:06



I was using the additional flags: --enable-shared --disable-static

It seems the issue was due to --disable-static with which built cannot
complete (the Makefile.ins assume that the static libraries are always
there).

regards,
Nikos

Re: arm compilation

Niels Möller — 2013-05-21T20:35:55


Is that a general problem, or just with this branch? There shouldn't be
any windows-related changes there.

I just tested

  $ ~/hack/nettle-stable/configure --host=i586-mingw32msvc
  $ make check

and that works fine for me (EMULATOR=wine). I guess you're doing
something differently, maybe native compilation, or w*ndows-8 on arm, or
something?


If the currrent setup doesn't work, you need to change the setup of
LIBNETTLE_FILE (or invent some new variables if required) and set it all
up inside the

  case "$host_os"

in configure.ac. And then substitute those values at the right place in
Makefile.in. I don't remember exactly how it's supposed to work, but
maybe the _FORLINK variables are the ones you need.

Regards,
/Niels

Re: arm compilation

Nikos Mavrogiannopoulos — 2013-05-21T19:56:25



I tried to build this branch using mingw32 and I got linking issues with
libnettle.a and libhogweed.a (in that system I get libnettle.dll.a.

By fixing the makefiles to link with the LIBNETTLE_FILE and
LIBHOGWEED_FILE fixes the issue in mingw, but creates a problem on linux
where libnettle.so is built but LIBNETTLE_FILE is libnettle.so.4.7.

Any ideas?

regards,
Nikos
diff --git a/examples/Makefile.in b/examples/Makefile.in
index 563d0dc..98f1d75 100644
--- a/examples/Makefile.in
+++ b/examples/Makefile.in
< at >< at > -117,8 +117,8 < at >< at > hogweed-benchmark$(EXEEXT): $(HOGWEED_BENCH_OBJS)
 -lhogweed -lnettle $(BENCH_LIBS) $(LIBS) $(OPENSSL_LIBFLAGS) \
 -o hogweed-benchmark$(EXEEXT)
 
-$(TARGETS) : io.$(OBJEXT) ../libnettle.a
-$(HOGWEED_TARGETS): ../libhogweed.a
+$(TARGETS) : io.$(OBJEXT) ../$(LIBNETTLE_FILE)
+$(HOGWEED_TARGETS): ../$(LIBHOGWEED_FILE)
 
 check: $(TS_ALL)
 LD_LIBRARY_PATH=../.lib PATH="../.lib:$$PATH" srcdir="$(srcdir)" \
diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in
index 91f6e2a..f88b2d

Re: arm compilation

Niels Möller — 2013-05-21T14:25:59


I just pushed a branch "nettle-2.7-fixes" to the public repo, intended to
also fix the pre-v6 ARM problems.

Regards,
/Niels

Re: arm compilation

Nikos Mavrogiannopoulos — 2013-05-19T07:58:05



Yes, this is what I eventually did (i deleted those files).

regards,
Nikos

Re: arm compilation

Niels Möller — 2013-05-19T06:12:20


I see. Does it work if you move the offending source files in arm/ to
the subdirectory arm/v6? In the build tree, you need either make
distclean, or remove corresponding symlinks manually.

The instructions which fail are used for reading the possibly unaliged
input area, and it seems some different tricks will be needed for pre-v6
ARM. (I haven't yet checked the ARM manual, so I'm not 100% sure in
which arch version they were introduced, but I guess they're also ARMv6)

Regards,
/Niels

Re: arm compilation

Nikos Mavrogiannopoulos — 2013-05-18T13:05:04




I now get errors in sha1 and sha256 code. I used make -i and no other
code seems to fail.

/home/nmav/cvs/buildroot/output/host/usr/bin/ccache
/home/nmav/cvs/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
-I.  -DHAVE_CONFIG_H -pipe -Os  -Wno-pointer-sign -Wall -W
-Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
-Wpointer-arith -Wbad-function-cast -Wnested-externs -fpic -MT
sha1-compress.o -MD -MP -MF sha1-compress.o.d -fpic -c sha1-compress.s
sha1-compress.s: Assembler messages:
sha1-compress.s:79: Error: selected processor does not support ARM mode
`uadd8 r7,r7,r12'
sha1-compress.s:86: Error: selected processor does not support ARM mode
`sel r12,r10,r7'
sha1-compress.s:89: Error: selected processor does not support ARM mode
`rev r12,r12'
sha1-compress.s:103: Error: selected processor does not support ARM mode
`sel r12,r10,r7'
sha1-compress.s:106: Error: selected processor does not support ARM mode
`rev r12,r12'
sha1-compress.s:120: Error: selected processor does not s

Bug in nettle-2.7 ecc code

Niels Möller — 2013-05-17T07:39:18

Testing on the debian build machines revealed a bug in the new ecc code.
Curiously enough, causing failures only on 32-bit sparc (see
https://buildd.debian.org/status/fetch.php?pkg=nettle&arch=sparc&ver=2.7-2&stamp=1368128015),
but the bug is not really platform-specific.

It turned out that ecc_j_to_a called GMP:s mpn_mul_n (via ecc_modp_mul)
with overlapping input and output arguments, which is not supported.

The following patch seems to solve the problem:

diff --git a/ecc-j-to-a.c b/ecc-j-to-a.c
index df8b876..26c1a03 100644
--- a/ecc-j-to-a.c
+++ b/ecc-j-to-a.c
< at >< at > -46,6 +46,7 < at >< at > ecc_j_to_a (const struct ecc_curve *ecc,
 #define up   (scratch + ecc->size)
 #define iz2p (scratch + ecc->size)
 #define iz3p (scratch + 2*ecc->size)
+#define izBp (scratch + 3*ecc->size)
 #define tp    scratch
 
   mp_limb_t cy;
< at >< at > -72,11 +73,11 < at >< at > ecc_j_to_a (const struct ecc_curve *ecc,
       if (flags & 1)
 {
   /* Divide this common factor by B */
-  mpn_copyi (iz3p, izp, ecc->size);
-  mpn_zero (iz3p + ecc->size, ec

Re: arm compilation

Niels Möller — 2013-05-16T14:57:31


I've checked in new AES code for pre-v6 processors. Can you test if it
works now? Haven't yet tried to address the other issue, with supporting
older assemblers.

Regards,
/Niels

Re: arm compilation

Niels Möller — 2013-05-15T11:25:41


I have tried this now. I get same speed if I do this trick to the main
round transformations. But uxtb is also used in the final round, and I'm
having some difficulty replacing that with and without making it slower.

Timing on the A9 appears to be very sensitive, adding a single
instruction, even a nop, can slow it down a lot. And for the final
round, we do substitutions via the sbox table, and hence need the mask
0xff rather than 0x3fc, and the single instruction to set that up seems
remarkably expensive. 

So I think we may need separate versions.

Regards,
/Niels

Re: arm compilation

Martin Storsjö — 2013-05-08T08:20:11


Hmm, I don't have much experience with the older binutils so I don't know 
for sure if they've got a problem with the it instructions or not. In 
general this might be a good direction, but there's probably not much need 
to actually make it all the way and finish it unless someone steps up to 
do it (having an actual need at the time), as long as we aren't moving in 
the opposite direction.

// Martin_______________________________________________
nettle-bugs mailing list
nettle-bugs-UqbJ+GOpo48MZebb/hMgdxVBtSSS1xAv< at >public.gmane.org
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: arm compilation

Niels Möller — 2013-05-08T08:12:56


Ok, if that is useful, I guess we should move in the opposite direction
and use it for *all* arm assembly files. But I'm worrying that the same
old assemblers which barf on

  orr r4,r8,lsl#8

may also barf on the itee instruction which is required for conditional
execution in unified syntax. Except possibly conditional branches, I
don't remember. Could of course use some configure/m4 magic to get
around that, if we think it's worth the effort.

Regards,
/Niels

Re: arm compilation

Niels Möller — 2013-05-08T08:05:18


I see.


So the aes functions could be moved to an arm/v6 subdirectory (the uxtb
occurs in aes.m4, included in the aes-*.asm).

What alternative are there to uxtb? The easiest alternative is to have a
series of rotates and ands.

But if we sacrifice a register to hold the byte mask 0xff, uxtb can be
replaced by an and with rotate.

This even has the advantage that we can offset the rotate by two bits,
and avoid shifting the index when it is used for the table lookup.

So instead of, e.g,

uxtbT0, X, ror #8
ldr[TABLE, T0, lsl #2]

put the value 0x3fc in MASK, and do

andT0, MASK, X, ror#6
ldr[TABLE, T0]
    
Eliminating a shift/rotate operation might even make the code faster.

Regards,
/Niels

Re: arm compilation

Martin Storsjö — 2013-05-08T07:47:51


I wouldn't suggest moving away from the unified syntax - being able to 
build for both thumb and arm from the same source is useful. Normally it's 
sufficient to support only arm mode, but there are certain cases where you 
want/need to build in thumb mode. One of them is the fact that windows 8 
on arm (WinRT and Windows Phone 8) only supports thumb mode.

If the instructions can be written more elaborately to allow older tools 
to assemble them, without making the code itself worse, it's probably a 
good tradeoff.

// Martin_______________________________________________
nettle-bugs mailing list
nettle-bugs-UqbJ+GOpo48MZebb/hMgdxVBtSSS1xAv< at >public.gmane.org
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: arm compilation

Niels Möller — 2013-05-08T07:41:30


I recently got a similar bugreport from a user with an arm system
running freebsd with an ancient GNU as. I think it would make sense to
use more traditional ARM asm syntax. Things I'm aware of:

1. Always use 3-operand form instructions, i.e.,

     add r1, r1, r2

   rather then

     add r1, r2

2. Write shift and rotate instructions as mov with a shift/rotate
   operand.

3. Add explicit ia/db suffixes on push, pop, ldm, stm.

4. Some file uses "unified" assembler syntax. Revert to traditional arm
   syntax (unless we have a good reason to support compiling to thumb
   instructions? I don't really understand pros and cons there).

I don't have time to test that right now, but patches are welcome. Is it
a common enough problem that it motivates a bug-fix release?

Regards,
/Niels

Re: arm compilation

Martin Storsjö — 2013-05-08T07:29:53


The uxtb instruction requires ARMv6, while an ARM10 is ARMv5, afaik.

So the functions using uxtb should only be enabled if the target is >= 
ARMv6, not arm in general. (The check can probably be done by testing to 
assemble such instructions, just as the check for neon does.)

// Martin

arm compilation

Nikos Mavrogiannopoulos — 2013-05-08T07:19:43

Hello,
 Trying to build nettle 2.7 for an arm10 system of mine using its (old)
toolchain fails with assembler errors.

arm-linux-gcc -Os  -I[...] -I.  -DHAVE_CONFIG_H -g -O2 -ggdb3
-Wno-pointer-sign -Wall -W   -Wmissing-prototypes -Wmissing-declarations
-Wstrict-prototypes   -Wpointer-arith -Wbad-function-cast
-Wnested-externs -fpic -MT aes-decrypt-internal.o -MD -MP -MF
aes-decrypt-internal.o.d -fpic -c aes-decrypt-internal.s
aes-decrypt-internal.s: Assembler messages:
aes-decrypt-internal.s:81: Error: bad instruction `push
{r4,r5,r6,r7,r8,r10,r11,lr}'
aes-decrypt-internal.s:87: Error: register or shift expression expected

Portable rotates

Niels Möller — 2013-05-03T10:47:09

I'm rewriting the cast128 key schedule, to get rid of false warnings, and
avoid lots of conditions, and to separate the rotation and the mask
subkeys.

Then I noticed a portability problem with the rotation macros,

  #define ROTL32(n,x) (((x)<<(n)) | ((x)>>(32-(n))))

For n == 0, this will work on most machines, but it's not portable,
since x >> 32 gives undefined behaviour according to the C spec (when x
is a 32-bit type). (On typical hardware, the result of x >> 32 will be
either x or 0, and the rotation macro gives the intended result in
either case).

In most of nettle, there's no problem, because rotation counts are
constant and non-zero.

cast128 is an exception, with key-dependent rotation counts, which can
well be zero (don't know if that's exercised by the test suite, though).

A fix is to redefine the macro as

  #define ROTL32(n,x) (((x)<<(n)) | ((x)>>((-(n))&31)))

It should make no difference when n is constant, but for cast128, this
portability fix makes the code almost 20% slower. Apparently,

raspberry pi

Niels Möller — 2013-04-30T13:33:05

I finally got a Raspberry Pi setup. Took almost 20 minutes to compile
nettle, and the configure script figured out not to use neon
instructions. It passes the testsuite. Benchmark for the public key
functions:

           name size   sign/ms verify/ms
            rsa 1024    0.1073    1.9099
            rsa 2048    0.0167    0.5539
            dsa 1024    0.1992    0.1014
          ecdsa  192    0.5297    0.1922
          ecdsa  224    0.3623    0.1354
          ecdsa  256    0.2621    0.0971
          ecdsa  384    0.1125    0.0391
          ecdsa  521    0.0551    0.0190

So 3 to 5 times slower than the pandaboard (although that's not a
completely fair comparison, since the raspberry pi is using gmp-5.0.5,
not the gmp bleeding edge).

Regards,
/Niels

Re: AEs interface (was: Re: Switching to size_t)

Nikos Mavrogiannopoulos — 2013-04-29T11:33:07


At least for gnutls, that's looks fine.

regards,
Nikos
_______________________________________________
nettle-bugs mailing list
nettle-bugs< at >lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs