Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#9948 closed defect (fixed)

Configure should error if libssp is not installed

Reported by: huslage Owned by:
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version: Tor: 0.2.4.17-rc
Severity: Keywords: tor-client build
Cc: ben@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Ran ./configure and then make.

Got this error from compile:

make all-am
make[1]: Entering directory `/home/root/tor-0.2.4.17-rc'

CC src/common/address.o

In file included from src/common/compat.h:10:0,

from src/common/address.c:12:

src/common/torint.h:233:2: error: #error "void * is either >8 bytes or <= 2. In either case, I am confused."
src/common/torint.h:237:2: error: #error "Missing type int8_t"
src/common/torint.h:240:2: error: #error "Missing type uint8_t"
src/common/torint.h:243:2: error: #error "Missing type int16_t"
src/common/torint.h:246:2: error: #error "Missing type uint16_t"
src/common/torint.h:249:2: error: #error "Missing type int32_t"
src/common/torint.h:252:2: error: #error "Missing type uint32_t"
src/common/torint.h:255:2: error: #error "Missing type int64_t"
src/common/torint.h:258:2: error: #error "Missing type uint64_t"
src/common/torint.h:265:2: error: #error "Seems that your platform doesn't use 2's complement arithmetic. Argh."
src/common/torint.h:305:2: error: #error "Can't define SHORT_MAX"
src/common/torint.h:341:2: error: #error "Can't define SIZE_T_MAX"
src/common/torint.h:351:2: error: #error "Can't define SSIZE_T_MAX"
In file included from src/common/address.c:12:0:
src/common/compat.h:74:2: error: #error "It seems your platform does not represent NULL as zero. We can't cope."
src/common/compat.h:78:2: error: #error "It seems your platform does not represent 0.0 as zeros. We can't cope."
src/common/compat.h:426:13: error: conflicting types for 'socklen_t'
In file included from /usr/include/sys/socket.h:39:0,

from src/common/compat.h:46,
from src/common/address.c:12:

/usr/include/bits/socket.h:34:21: note: previous declaration of 'socklen_t' was here
In file included from src/common/address.c:16:0:
src/common/container.h:541:2: error: #error "int is neither 4 nor 8 bytes. I can't deal with that."
src/common/container.h: In function 'bitarray_init_zero':
src/common/container.h:552:23: error: 'BITARRAY_SHIFT' undeclared (first use in this function)
src/common/container.h:552:23: note: each undeclared identifier is reported only once for each function it appears in
src/common/container.h: In function 'bitarray_expand':
src/common/container.h:562:31: error: 'BITARRAY_SHIFT' undeclared (first use in this function)
src/common/container.h: In function 'bitarray_set':
src/common/container.h:584:12: error: 'BITARRAY_SHIFT' undeclared (first use in this function)
src/common/container.h: In function 'bitarray_clear':
src/common/container.h:590:12: error: 'BITARRAY_SHIFT' undeclared (first use in this function)
src/common/container.h: In function 'bitarray_is_set':
src/common/container.h:597:19: error: 'BITARRAY_SHIFT' undeclared (first use in this function)
src/common/address.c: In function 'get_interface_address6':
src/common/address.c:1401:32: warning: pointer targets in passing argument 3 of 'getsockname' differ in signedness [-Wpointer-sign]
In file included from src/common/compat.h:46:0,

from src/common/address.c:12:

/usr/include/sys/socket.h:118:12: note: expected 'socklen_t * restrict' but argument is of type 'socklen_t *'
make[1]: * [src/common/address.o] Error 1
make[1]: Leaving directory `/home/root/tor-0.2.4.17-rc'
make:
* [all] Error 2

After speaking with sqrt2 on IRC, and digging through logs we determined that it was actually a missing libssp. After installing libssp things worked fine.

Child Tickets

Attachments (5)

orconfig.h (16.7 KB) - added by huslage 6 years ago.
configure-ssp-check.patch (1.5 KB) - added by sqrt2 6 years ago.
Error when we cannot build with stack protection
cflags-check-linking.2.patch (1.8 KB) - added by sqrt2 6 years ago.
Implement optional linking check in TOR_CHECK_CFLAGS, handle stack protection issues (corrected version)
cflags-check-linking.patch (1.8 KB) - added by sqrt2 6 years ago.
Implement optional linking check in TOR_CHECK_CFLAGS, handle stack protection issues (corrected version)
bug9948.patch (2.3 KB) - added by sqrt2 6 years ago.
patch against git master

Download all attachments as: .zip

Change History (24)

Changed 6 years ago by huslage

Attachment: orconfig.h added

comment:1 Changed 6 years ago by sqrt2

A missing libssp causes the length tests for the standard integer types to fail, resulting in SIZEOF_INT8_T == 0 (etc.) in orconfig.h.

comment:2 Changed 6 years ago by sqrt2

Cc: ben@… added

comment:3 Changed 6 years ago by nickm

What's the right check to see whether we're on a platform that is going to need to use libssp ?

comment:4 Changed 6 years ago by sqrt2

Looking at the config.log huslage posted (<http://pastebin.com/raw.php?i=G89YxfV9>), it appears that --enable-libssp is amongst the default parameters on that platform/their host (while it isn't on others), so testing for that parameter should work.

comment:5 Changed 6 years ago by nickm

That string doesn't appear in our configure script at all, though, and I'm a little leery of looking at default autoconf parameters (unless there's some documentation for this someplace). Is there a compile/link-only test that would work?

comment:6 Changed 6 years ago by sqrt2

It appears what gcc does is to look for a define TARGET_LIBC_PROVIDES_SSP, and if it's not there, add -lssp -lssp_nonshared to the linker flags if -fstack-protector{,-all,-strong} is specified (<http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.c;hb=HEAD#l682>).

The tests for TARGET_LIBC_PROVIDES_SSP are here: <http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;hb=HEAD#l4835>

comment:7 Changed 6 years ago by sqrt2

I'd say if something as simple as

cat > ssptest.c << EOF
#include <stdio.h>
main() { puts("") }
EOF
gcc -o ssptest -fstack-protector ssptest.c

fails, then it's probably a missing libssp on a system without libc stack protection support.

If --enable-gcc-hardening is specified, a test like that is probably good enough to error and suggest to the user to check for SSP support, or --disable-gcc-hardening.

comment:8 Changed 6 years ago by nickm

Hm. Could it be as simple, in that case, to change AC_TRY_COMPILE in the definition of TOR_CHECK_CFLAGS to AC_TRY_LINK instead? Or to add an extra AC_TRY_LINK in the case that TOR_CHECK_CFLAGS decides to use -fstack-protector?

comment:9 Changed 6 years ago by sqrt2

gcc.c contains the specs language (<http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.c;hb=HEAD#l271>), which lets you turn CFLAGS into arbitrary program calls, including linker calls. Against this backdrop it may be reasonable to simply turn AC_TRY_COMPILE into AC_TRY_LINK.

comment:10 Changed 6 years ago by nickm

Keywords: tor-client build added
Milestone: Tor: 0.2.5.x-final

copypasted with permission from IRC:

10:35 < sqrt2> nickm: do you want me to attach a patch to #9948 or is that 
               unnecessarily bureaucratic?
10:37 < nickm> sqrt2: A patch would be cool, but there's one thing I'm worried 
               about.
10:38 < nickm> sqrt2: If we just change AC_TRY_COMPILE to AC_TRY_LINK in that 
               macro, then we won't get the desired effect ("give an error when 
               --enable-gcc-hardening is on, but libssp is needed and absent.") 
               Instead, we will decide that we can't turn on ssp, because 
               linking didn't work.
10:38 < nickm> So we'll need to make sure that if the ssp option makes us 
               compile but not link, we give an error
10:38 < sqrt2> well, technically, we can't turn on ssp, and 
               --enable-gcc-hardening is a default, not something the user 
               explicitly wanted
10:39 < sqrt2> but it may be a good idea to force the user to disable it 
               manually nevertheless
10:39 < nickm> right.
10:44 < sqrt2> nickm: i'll try to get my hands on a build environment that has 
               such a libc and hopefully just test out the methods then

comment:11 Changed 6 years ago by sqrt2

It turns out that the cross-compiling toolchain provided by Ångström Linux, which huslage reported they were using, does not require libssp for -fstack-protector.

I'm going to try to install an old version of Debian with glibc 2.3 in a VM next.

Changed 6 years ago by sqrt2

Attachment: configure-ssp-check.patch added

Error when we cannot build with stack protection

comment:12 Changed 6 years ago by sqrt2

Status: newneeds_review

I could reproduce the behaviour of configure on Debian etch, though not reproduce the exact build error message due to a compiler bug in gcc-4.1.

The attached patch (against 0.2.4.17-rc) should fix this bug.

comment:13 Changed 6 years ago by nickm

That's not quite right. We want to keep the current behavior where we omit -fstack-protector if the compiler does not recognize it, and give a warning only when the compiler recognizes it but the linker rejects it.

comment:14 Changed 6 years ago by sqrt2

Since most issues with gcc specs should be of this type, I decided to implement additional linking in TOR_CHECK_CFLAGS and return the result in a shell variable.

Changed 6 years ago by sqrt2

Implement optional linking check in TOR_CHECK_CFLAGS, handle stack protection issues (corrected version)

Changed 6 years ago by sqrt2

Attachment: cflags-check-linking.patch added

Implement optional linking check in TOR_CHECK_CFLAGS, handle stack protection issues (corrected version)

comment:15 Changed 6 years ago by sqrt2

There was a stray bracket even in the corrected version; the hopefully finally correct version of the patch is now cflags-check-linking.patch.

I'm sorry for my incompetence tonight.

comment:16 Changed 6 years ago by nickm

Okay. It looks almost done! Two final requests:

  • Could you make a file for the changes/ directory?
  • The message should probably be a little more tentative about suggesting libssp, since there could be some other reason for the link failure.

Changed 6 years ago by sqrt2

Attachment: bug9948.patch added

patch against git master

comment:17 Changed 6 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Merged; thanks!

comment:18 Changed 5 years ago by arma

Is this a fair rewrite of the changelog?

@@ -1,6 +1,4 @@
   o Minor features (build):
-
-    - Check in configure whether we can link an executable when
-      stack protection is enabled so we can warn the user about a
-      potentially missing libssp. Addresses ticket 9948. Patch
-      from Benedikt Gollatz. 
+    - If we run ./configure and the compiler recognizes -fstack-protector
+      but the linker rejects it, warn the user about a potentially missing
+      libssp package. Addresses ticket 9948. Patch from Benedikt Gollatz.

comment:19 Changed 5 years ago by nickm

yes.

Note: See TracTickets for help on using tickets.