Hello,
I am interested in helping out with the development of Nettle. Are there
any small projects I could undertake to get started?
Best wishes,
Andrew Lawrence
The following test program leads to SIGSEGV in 'get_x86_features' while
loading libnettle.so from nettle-3.1 built with --enable-fat:
--8<---------------cut here---------------start------------->8---
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
int main (int argc, char *argv[])
{
void *handle;
handle = dlopen ("libnettle.so", RTLD_NOW);
if (!handle)
{
fprintf (stderr, "%s\n", dlerror ());
exit (EXIT_FAILURE);
}
dlclose (…
[View More]handle);
exit (EXIT_SUCCESS);
}
--8<---------------cut here---------------end--------------->8---
Here's the backtrace:
--8<---------------cut here---------------start------------->8---
#0 0x0000000000009006 in ?? ()
#1 0x00007ffff73f6a37 in get_x86_features (features=<synthetic pointer>) at fat-x86_64.c:94
#2 fat_init () at fat-x86_64.c:133
#3 0x00007ffff7412475 in nettle_memxor_resolve () at fat-x86_64.c:185
#4 0x00007ffff7de8c41 in elf_machine_rela (reloc=0x7ffff73f5170, reloc=0x7ffff73f5170, skip_ifunc=0, reloc_addr_arg=<optimized out>,
version=<optimized out>, sym=0x7ffff73ee2d0, map=0x601050) at ../sysdeps/x86_64/dl-machine.h:286
#5 elf_dynamic_do_Rela (skip_ifunc=0, lazy=0, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, map=0x601050) at do-rel.h:137
#6 _dl_relocate_object (scope=<optimized out>, reloc_mode=reloc_mode@entry=0, consider_profiling=<optimized out>, consider_profiling@entry=0)
at dl-reloc.c:264
#7 0x00007ffff7defb36 in dl_open_worker (a=a@entry=0x7fffffffcea8) at dl-open.c:418
#8 0x00007ffff7deb704 in _dl_catch_error (objname=objname@entry=0x7fffffffce98, errstring=errstring@entry=0x7fffffffcea0,
mallocedp=mallocedp@entry=0x7fffffffce97, operate=operate@entry=0x7ffff7def800 <dl_open_worker>, args=args@entry=0x7fffffffcea8) at dl-error.c:187
#9 0x00007ffff7def2db in _dl_open (file=0x4009f4 "libnettle.so", mode=-2147483646, caller_dlopen=<optimized out>, nsid=-2, argc=1, argv=0x7fffffffd1f8,
env=0x7fffffffd208) at dl-open.c:652
#10 0x00007ffff7bd9fab in dlopen_doit (a=a@entry=0x7fffffffd0c0) at dlopen.c:66
#11 0x00007ffff7deb704 in _dl_catch_error (objname=0x7ffff7ddc0f0 <last_result+16>, errstring=0x7ffff7ddc0f8 <last_result+24>,
mallocedp=0x7ffff7ddc0e8 <last_result+8>, operate=0x7ffff7bd9f50 <dlopen_doit>, args=0x7fffffffd0c0) at dl-error.c:187
#12 0x00007ffff7bda55d in _dlerror_run (operate=operate@entry=0x7ffff7bd9f50 <dlopen_doit>, args=args@entry=0x7fffffffd0c0) at dlerror.c:163
#13 0x00007ffff7bda041 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87
#14 0x0000000000400924 in main ()
--8<---------------cut here---------------end--------------->8---
The SIGSEGV happens in the following call:
_nettle_cpuid (0, cpuid_data);
The problem appears to be that the PLT entry for '_nettle_cpuid' has not
yet been initialized when 'fat_init' is called via
'nettle_memxor_resolve':
--8<---------------cut here---------------start------------->8---
mhw@jojen:~$ LD_LIBRARY_PATH=$HOME/.guix-profile/lib gdb ./test
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test...(no debugging symbols found)...done.
(gdb) directory /home/mhw/nettle-3.1
Source directories searched: /home/mhw/nettle-3.1:$cdir:$cwd
(gdb) run
Starting program: /home/mhw/test
Program received signal SIGSEGV, Segmentation fault.
0x0000000000009006 in ?? ()
(gdb) up
#1 0x00007ffff73f6a37 in get_x86_features (features=<synthetic pointer>) at fat-x86_64.c:94
warning: Source file is more recent than executable.
94 _nettle_cpuid (0, cpuid_data);
(gdb) break 94
Breakpoint 1 at 0x7ffff73f6a1f: file fat-x86_64.c, line 94.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/mhw/test
Breakpoint 1, fat_init () at fat-x86_64.c:133
warning: Source file is more recent than executable.
133 get_x86_features (&features);
(gdb) si
0x00007ffff73f6a24 in get_x86_features (features=<synthetic pointer>) at fat-x86_64.c:94
94 _nettle_cpuid (0, cpuid_data);
(gdb)
96 features->vendor = X86_INTEL;
(gdb)
94 _nettle_cpuid (0, cpuid_data);
(gdb)
95 if (memcmp (cpuid_data + 1, "Genu" "ntel" "ineI", 12) == 0)
(gdb)
94 _nettle_cpuid (0, cpuid_data);
(gdb)
0x00007ffff73f6000 in _nettle_cpuid@plt () from /home/mhw/.guix-profile/lib/libnettle.so
(gdb) disassemble /m 0x00007ffff73f6000
Dump of assembler code for function _nettle_cpuid@plt:
=> 0x00007ffff73f6000 <+0>: jmpq *0x22c722(%rip) # 0x7ffff7622728 <_nettle_cpuid(a)got.plt>
0x00007ffff73f6006 <+6>: pushq $0x26
0x00007ffff73f600b <+11>: jmpq 0x7ffff73f5d90
End of assembler dump.
(gdb) disassemble /m 0x7ffff7622728
Dump of assembler code for function _nettle_cpuid(a)got.plt:
0x00007ffff7622728 <+0>: (bad)
0x00007ffff7622729 <+1>: nop
0x00007ffff762272a <+2>: add %al,(%rax)
0x00007ffff762272c <+4>: add %al,(%rax)
0x00007ffff762272e <+6>: add %al,(%rax)
End of assembler dump.
(gdb) si
0x0000000000009006 in ?? ()
(gdb)
--8<---------------cut here---------------end--------------->8---
This is a problem for GNU Guix because 'gstreamer' loads its modules
using the glib function 'g_module_open' (based on 'dlopen') and the
'gst-libav' module is linked with nettle. This breaks 'gst-libav' on
x86_64.
Details
=======
System type: x86_64-unknown-linux-gnu
nettle-3.1 compiled with:
gcc-4.8.4
binutils-2.25
glibc-2.21
Nettle configure flags:
CONFIG_SHELL=/gnu/store/wxcgfy43r6lmxhm2m7xk1vsgyddhx3y0-bash-4.3.33/bin/bash
SHELL=/gnu/store/wxcgfy43r6lmxhm2m7xk1vsgyddhx3y0-bash-4.3.33/bin/bash
--prefix=/gnu/store/k0bhgy2l5kj1hp2vxx3ys42pn4kr599h-nettle-3.1
--enable-fast-install
--enable-fat
LDFLAGS=-Wl,-rpath=/gnu/store/k0bhgy2l5kj1hp2vxx3ys42pn4kr599h-nettle-3.1/lib
Here's the build log for the nettle used in the above tests:
http://hydra.gnu.org/build/381502/log/raw
If needed, I can explain how to reproduce this exact environment using
GNU Guix.
Mark
[View Less]
Hello everybody,
we at suse ran address sanitizer against libnettle and found two bugs [1][2].
The first one is easy to fix (simple off by one) and thus we already have the
patch (see attachment 0001-...).
The second one is about memory leaks, and it would be better if someone more
aware of the source took a look wether and how to fix it.
Cheers
Tom
[1] https://bugzilla.suse.com/show_bug.cgi?id=928328
[2] https://bugzilla.suse.com/show_bug.cgi?id=929109
PS: I am not subscribed so keep …
[View More]me in CC please.
[View Less]
[I'm cross-posting to the nettle list and a debian bug, so please take
care when replying]
The issue is that there are some differences in generated nettle header
files depending on architecture and compiler version.
Francois Gouget <fgouget(a)free.fr> writes:
> Here is a proposed patch for the compiler version issue in nettle-stdint.h:
>
> $ cat debian/patches/multiarch.patch
> --- a/aclocal.m4
> +++ b/aclocal.m4
> @@ -857,7 +857,7 @@
> fi # shortcircut to …
[View More]system "stdint.h"
> # ------------------ PREPARE VARIABLES ------------------------------
> if test "$GCC" = "yes" ; then
> -ac_cv_stdint_message="using gnu compiler "`$CC --version | head -1`
> +ac_cv_stdint_message="using gnu compiler $CC"
> else
> ac_cv_stdint_message="using $CC"
> fi
If we go this path, maybe just drop the conditional and unconditionally
print "using $CC"? I'm not sure about the reason for displaying the
version, but I guess some older gcc versions did stdint and/or
inttypes.h differently.
If you have the time, it would be helpful to look at the latest version
of AX_CREATE_STDINT_H (from autoconf archive) and see if it does
anything differently. Nettle uses a pretty old version (which seems to
work fine).
> For GMP_NUMB_BITS here are some thoughts:
You must understand that nettle defines GMP_NUMB_BITS only if configured
with --enable-mini-gmp. This configuration is not intended to be
compatible with anything else, and should never be installed on a normal
debian system. It's intended for small embedded systems which needs to
verify digital signatures, but which consider the real libgmp too large.
> * Is it really necessary to install version.h?
> IMHO the right place for other packages to figure out library versions is through
> some scripting in the configure script rather than through a
> header.
This has been requested by users. Not everyone uses autoconf. And it's
very common practice, I think both gmp and gnutls have similar version
defines.
> * GMP_NUMB_BITS is already defined by libgmp-dev in gmp.h. More
> preceisely
Exactly, and when not configuring with --enable-mini-gmp, that's the
definitions which is used.
Getting into the details, Nettle's definition of GMP_NUMB_BITS
conceptually belongs in mini-gmp.h. However, mini-gmp is a standalone
package which doesn't use autoconf. And it has to be a preprocessor
*constant*, so definiting it like sizeof(unsigned long) * CHAR_BIT won't
cut it, since the preprocessor doesn't understand sizeof.
Therefore the definition, for the --enable-mini-gmp configuration which
needs it, should be in a nettle include file. Then the cleanest way
would be to omit the definition completely when not using
--enable-mini-gmp. I haven't done that, because it would make the
substitution logic harder, and because I was thinking that
#define NETTLE_USE_MINI_GMP 0
#if NETTLE_USE_MINI_GMP
# define GMP_NUMB_BITS 64
#endif
is harmless whatever value appears in the second define. If it helps, I
guess this could be changed into the architecture independent
#define NETTLE_USE_MINI_GMP 0
#if NETTLE_USE_MINI_GMP
# define GMP_NUMB_BITS the moon is made of green cheese
#endif
Opinions?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
[View Less]
Hello there, I saw the recent addition of the version #define's, which are
great, but a runtime function that I can call to find out libnettle's API
is essential for dynamic bindings.
I maintain the Julia language bindings for Nettle
<https://github.com/staticfloat/Nettle.jl> which loads the dynamic library
and generates methods to use Nettle's cryptographic functions on the fly.
This process does not use header files, it's similar to Python's ctypes
functionality, and thus knowing which …
[View More]API version we're dealing with by
only using the dynamic library itself is necessary. Most other projects
have some method or other for determining this, as you guys have already
discussed, but simply placing the information into a header file is not
sufficient for this use case.
Is this something it would be possible to support?
Thanks!
-E
[View Less]
Now we see some transition problems,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784009, and it's going
to also hit other distributions than debian.
Would it make sense to issue a nettle-2.7.2, which is nettle-2.7.1 +
symbol versions? There's at least one bugfix which could be backported
if we do another 2.7.x:
2014-06-30 Niels Möller <nisse(a)lysator.liu.se>
* camellia-absorb.c: Include <limits.h>, needed for correct use of
HAVE_NATIVE_64_BIT. Reported and debugged by …
[View More]Magnus Holmgren.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
[View Less]
I've made another release of GNU Nettle, a low-level
cryptographics library, to fix bugs reported for Nettle 3.1.
The Nettle home page can be found at
http://www.lysator.liu.se/~nisse/nettle/, and the manual at
http://www.lysator.liu.se/~nisse/nettle/nettle.html.
NEWS for the Nettle 3.1.1 release
This release fixes a couple of non-critical bugs.
Bug fixes:
* By accident, nettle-3.1 disabled the assembly code for the
secp_224r1 and secp_521r1 elliptic curves on all x86_64
…
[View More]configurations, making signature operations on those curves
10%-30% slower. This code is now re-enabled.
* The x86_64 assembly implementation of gcm hashing has been
fixed to work with the Sun/Oracle assembler.
The shared library names are libnettle.so.6.1 and
libhogweed.so.4.1, with sonames still libnettle.so.6 and
libhogweed.so.4. It is intended to be fully binary compatible
with nettle-3.1.
Available at:
https://ftp.gnu.org/gnu/nettle/nettle-3.1.1.tar.gzftp://ftp.gnu.org/gnu/nettle/nettle-3.1.1.tar.gzhttp://www.lysator.liu.se/~nisse/archive/nettle-3.1.1.tar.gz
ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-3.1.1.tar.gz (soon)
Happy hacking,
/Niels Möller
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
[View Less]