Bug 1539097 - unbound: Automatically inherit build flags from the build environment
Summary: unbound: Automatically inherit build flags from the build environment
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: unbound
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Menšík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On: 1548821
Blocks: Fedora28BuildFlags
TreeView+ depends on / blocked
 
Reported: 2018-01-26 16:02 UTC by Florian Weimer
Modified: 2018-03-26 09:42 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-03-26 09:42:07 UTC


Attachments (Terms of Use)

Description Florian Weimer 2018-01-26 16:02:48 UTC
Unbound is currently build with outdated build flags because they are hard-coded in the package itself, instead of relying on injection via redhat-rpm-config:

# This is needed to rebuild the configure script to support Python 3.x
# autoreconf -iv
export LDFLAGS="-Wl,-z,relro,-z,now -pie -specs=/usr/lib/rpm/redhat/redhat-hardened-ld"
export CFLAGS="$RPM_OPT_FLAGS -fPIE -pie"
export CXXFLAGS="$RPM_OPT_FLAGS -fPIE -pie"

I'm not attempting the change myself because it was attempted before and failed:

commit 0f4cecfaa6a72b087ce1fba1763300874cf80a22
Author: Paul Wouters <pwouters@redhat.com>
Date:   Mon Jul 8 15:48:24 2013 -0400

    Revert "don't hardcode hardening flags, let hardened build macro handles it"
    
    This reverts commit f577e323b01e9e3b4ef0f69ff0794c158a240361.
    
    The reason is two-fold. It causes the unbound daemon to have less security
    (no full relro, no PIE) and it failed to compile for me at all on f19,
    failing with:
    
            checking consistency of all components of python development environment... no


Note that there is a known issue with the way Python handles build flags.  See bug 1217376.

Comment 1 Fedora End Of Life 2018-02-20 15:33:04 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 2 Petr Menšík 2018-02-21 19:43:55 UTC
Upstream already has support for both -z now and -pie flags in configure. So extra export flags can be removed and package default can be used with a new configure options. Prepared in master and f28.

Comment 3 Fedora Update System 2018-02-21 20:15:23 UTC
unbound-1.6.8-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-cb1f26bd2c

Comment 4 Fedora Update System 2018-02-22 16:04:17 UTC
unbound-1.6.8-6.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-cb1f26bd2c

Comment 5 Fedora Update System 2018-02-27 17:24:01 UTC
unbound-1.6.8-6.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 6 Florian Weimer 2018-02-27 18:20:36 UTC
/usr/lib64/libunbound.so.2.5.7 in unbound-libs-1.6.8-6.fc28.x86_64 still doesn't use the redhat-rpm-config CFLAGS and therefore lacks annobin annotations.

Comment 7 Petr Menšík 2018-02-27 19:03:43 UTC
(In reply to Florian Weimer from comment #6)
> /usr/lib64/libunbound.so.2.5.7 in unbound-libs-1.6.8-6.fc28.x86_64 still
> doesn't use the redhat-rpm-config CFLAGS and therefore lacks annobin
> annotations.

I disagree, flags are used when linking, according to build log [1].

./libtool --tag=CC --mode=link gcc  -I. -I/usr/include/python3.6m -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -flto -fPIE -pthread -Wl,-z,relro  -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -pie -Wl,-z,relro,-z,now  -version-info 7:7:5 -no-undefined -export-symbols ./libunbound/ubsyms.def -o libunbound.la context.lo libunbound.lo libworker.lo ub_event_pluggable.lo dns.lo infra.lo rrset.lo dname.lo msgencode.lo as112.lo msgparse.lo msgreply.lo packed_rrset.lo iterator.lo iter_delegpt.lo iter_donotq.lo iter_fwd.lo iter_hints.lo iter_priv.lo iter_resptype.lo iter_scrub.lo iter_utils.lo localzone.lo mesh.lo modstack.lo view.lo outbound_list.lo alloc.lo config_file.lo configlexer.lo configparser.lo fptr_wlist.lo locks.lo log.lo mini_event.lo module.lo net_help.lo random.lo rbtree.lo regional.lo rtt.lo dnstree.lo lookup3.lo lruhash.lo slabhash.lo timehist.lo tube.lo winsock_event.lo autotrust.lo val_anchor.lo validator.lo val_kcache.lo val_kentry.lo val_neg.lo val_nsec3.lo val_nsec.lo val_secalgo.lo val_sigcrypt.lo val_utils.lo dns64.lo cachedb.lo authzone.lo edns-subnet.lo subnetmod.lo addrtree.lo subnet-whitelist.lo pythonmod.lo pythonmod_utils.lo    ipsecmod.lo ipsecmod-whitelist.lo respip.lo netevent.lo listen_dnsport.lo outside_network.lo keyraw.lo sbuffer.lo wire2str.lo parse.lo parseutil.lo rrdef.lo str2wire.lo strlcat.lo strlcpy.lo arc4random.lo arc4random_uniform.lo explicit_bzero.lo arc4_lock.lo -rpath /usr/lib64 -lssl -levent -L/usr/lib64 -L/usr/lib64/python3.6 -L. -lpython3.6m -lcrypto

There is present this:
... -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic ...

How do you check annobin is present in the binary? Is it possible libtool filtererd it out? Is it possible filter of exported symbols filters it out? Have I missed flags are not present somewhere?

[1] https://kojipkgs.fedoraproject.org//packages/unbound/1.6.8/6.fc28/data/logs/x86_64/build.log

Comment 8 Petr Menšík 2018-02-27 19:15:05 UTC
I think this is hitting bug #1548821, because -flto is used here as well.

Comment 9 Florian Weimer 2018-02-27 19:17:42 UTC
(In reply to Petr Menšík from comment #7)
> How do you check annobin is present in the binary? Is it possible libtool
> filtererd it out? Is it possible filter of exported symbols filters it out?
> Have I missed flags are not present somewhere?

“eu-readelf -S /usr/lib64/libunbound.so.2.5.7” is supposed to show a .gnu.build.attributes section, and “readelf -n” should decode those notes.  But there is simply no data there.

I agree that it is likely that this is related to the use of LTO.  I do not know if libtool is aware of LTO and will pass the CFLAGS down to the gcc compiler driver in link mode.  LTO requires that the CFLAGS are injected for both the compiler and linker invocation, and I suspect that libtool filters out these flags for some unknown reason.

Comment 10 Petr Menšík 2018-02-27 19:32:30 UTC
Makefile rule expands:

LINK_LIB=$(LIBTOOL) --tag=CC --mode=link $(CC) $(RUNTIME_PATH) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) $(staticexe) -version-info 7:7:5 -no-undefined
# then this is used to create libunbound
libunbound.la:  $(LIBUNBOUND_OBJ_LINK)
        $(LINK_LIB) $(UBSYMS) -o $@ $(LIBUNBOUND_OBJ_LINK) -rpath $(libdir) $(SSLLIB) $(LIBS)

I guess also CFLAGS is always there. After all redhat-hardened-cc1 is part of CFLAGS only, it is present also there.

Comment 11 Igor Gnatenko 2018-03-26 08:56:06 UTC
any news here?

Comment 12 Petr Menšík 2018-03-26 09:42:07 UTC
It seems remaining issues were fixed by rebased rebuild in unbound-libs-1.7.0-2.fc28.x86_64

Maybe the issue was lack of BuildRequires for gcc and make in spec file. It may had older version installed. It seems now it works as expected.

$ readelf -n /usr/lib64/libunbound.so.2
...
Displaying notes found in: .gnu.build.attributes
  Owner                 Data size       Description
  GA$<version>3p5      0x00000010       OPEN
    Applies to region from 0x14c70 to 0x15910
  GA$<tool>gcc 8.0.1 2 0x00000000       OPEN
    Applies to region from 0x14c70 to 0x15910
  GA*GOW:0x000000000452a 0x00000000     OPEN
    Applies to region from 0x14c70 to 0x15910
  GA*<stack prot>stron 0x00000000       OPEN
    Applies to region from 0x14c70 to 0x15910
  GA+stack_clash:true  0x00000000       OPEN
    Applies to region from 0x14c70 to 0x15910
  GA*cf_protection:0x008 0x00000000     OPEN
    Applies to region from 0x14c70 to 0x15910
  GA+GLIBCXX_ASSERTION: 0x00000000      OPEN
    Applies to region from 0x14c70 to 0x15910
...


Note You need to log in before you can comment on or make changes to this bug.