From owner-freebsd-toolchain@freebsd.org Sun Aug 21 01:16:55 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C17C6BB9A32 for ; Sun, 21 Aug 2016 01:16:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B09251E43 for ; Sun, 21 Aug 2016 01:16:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7L1Grxt044197 for ; Sun, 21 Aug 2016 01:16:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 192320] Use of thread_local produces linking errors on system version of clang++ Date: Sun, 21 Aug 2016 01:16:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mi@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kib@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 01:16:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192320 --- Comment #14 from Mikhail Teterin --- Some of the ports could benefit from knowing, the functionality is availabl= e. Can the OSVERSION be bumped to reflect it? Thanks! --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Aug 21 21:30:37 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1D69BC1771 for ; Sun, 21 Aug 2016 21:30:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-12.reflexion.net [208.70.210.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F96D172D for ; Sun, 21 Aug 2016 21:30:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21522 invoked from network); 21 Aug 2016 21:23:48 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 21 Aug 2016 21:23:48 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Sun, 21 Aug 2016 17:23:48 -0400 (EDT) Received: (qmail 17741 invoked from network); 21 Aug 2016 21:23:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Aug 2016 21:23:48 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id BCDBD1C43F0; Sun, 21 Aug 2016 14:23:50 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: Problems with our libgcc_s.so in base [FYI: armv6 C++/g++6 example under stable/11 -r304029] Message-Id: <65040FD8-1CDF-4D39-9D8B-19480E23CD31@dsl-only.net> Date: Sun, 21 Aug 2016 14:23:54 -0700 To: FreeBSD Toolchain , freebsd-arm , freebsd-stable@freebsd.org, FreeBSD Ports Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 21:30:37 -0000 "problems come when we try to us archtiectures not fully supported by = out libgcc_s.so" ( from https://people.freebsd.org/~db/libgcc.txt ). . . On armv6 (an rpi2) C++ by itself can have /lib/libgcc_s.so.1 not being = sufficient, for example with g++6 being used:=20 > # g++6 -std=3Dc++14 -O2 cpp_clocks_investigation.cpp > # ldd a.out > a.out: > libstdc++.so.6 =3D> /usr/local/lib/gcc6/libstdc++.so.6 = (0x20100000) > libm.so.5 =3D> /lib/libm.so.5 (0x20053000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x20076000) > libc.so.7 =3D> /lib/libc.so.7 (0x20300000) > # ./a.out > /usr/local/lib/gcc6/libstdc++.so.6: Undefined symbol = "__aeabi_uldivmod" By contrast: > # g++6 -Wl,-rpath=3D/usr/local/lib/gcc6 -std=3Dc++14 -O2 = cpp_clocks_investigation.cpp > # ldd a.out > a.out: > libstdc++.so.6 =3D> /usr/local/lib/gcc6/libstdc++.so.6 = (0x20100000) > libm.so.5 =3D> /lib/libm.so.5 (0x20053000) > libgcc_s.so.1 =3D> /usr/local/lib/gcc6/libgcc_s.so.1 = (0x20076000) > libc.so.7 =3D> /lib/libc.so.7 (0x20300000) > # ./a.out > std::numeric_limits::max(): 9'223'372'036'854'775'807 . . . (works fine) . . . Context details: > # svnlite info /usr/src/ | grep "Re[vl][ia:]" > Relative URL: ^/stable/11 > Revision: 304029 > Last Changed Rev: 304029 > # uname -apKU > FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #4 r304029M: Sat = Aug 13 01:10:34 PDT 2016 = markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-N > ODBG arm armv6 1100500 1100500 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Aug 22 08:29:13 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72CC9BB8826; Mon, 22 Aug 2016 08:29:13 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5867128B; Mon, 22 Aug 2016 08:29:12 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u7M8LdkB065170 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Aug 2016 08:21:43 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: multipart/signed; boundary="Apple-Mail=_E19F0EEC-3A77-456F-9729-D6DB9ED6362B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Problems with our libgcc_s.so in base [FYI: armv6 C++/g++6 example under stable/11 -r304029] From: David Chisnall In-Reply-To: <65040FD8-1CDF-4D39-9D8B-19480E23CD31@dsl-only.net> Date: Mon, 22 Aug 2016 09:21:44 +0100 Cc: FreeBSD Toolchain , freebsd-arm , freebsd-stable@freebsd.org, FreeBSD Ports Message-Id: References: <65040FD8-1CDF-4D39-9D8B-19480E23CD31@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 08:29:13 -0000 --Apple-Mail=_E19F0EEC-3A77-456F-9729-D6DB9ED6362B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 21 Aug 2016, at 22:23, Mark Millard wrote: >=20 > On armv6 (an rpi2) C++ by itself can have /lib/libgcc_s.so.1 not being = sufficient, for example with g++6 being used:=20 >=20 >> # g++6 -std=3Dc++14 -O2 cpp_clocks_investigation.cpp >> # ldd a.out >> a.out: >> libstdc++.so.6 =3D> /usr/local/lib/gcc6/libstdc++.so.6 = (0x20100000) >> libm.so.5 =3D> /lib/libm.so.5 (0x20053000) >> libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x20076000) >> libc.so.7 =3D> /lib/libc.so.7 (0x20300000) >> # ./a.out >> /usr/local/lib/gcc6/libstdc++.so.6: Undefined symbol = "__aeabi_uldivmod" >=20 The problem appears to be that we=E2=80=99ve not imported (all of?) the = ARM-specific bits of compiler-rt. For example, this function is = provided upstream: = http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/builtins/arm/aea= bi_uldivmod.S?revision=3D273500&view=3Dmarkup David --Apple-Mail=_E19F0EEC-3A77-456F-9729-D6DB9ED6362B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCCBPww ggPkoAMCAQICECJrrb9nBol9MHok/UZg/AYwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTAeFw0xNjA0MTkw OTI3NDJaFw0xNzA0MTkwOTI3NDJaMEQxHTAbBgNVBAMMFHRoZXJhdmVuQGZyZWVic2Qub3JnMSMw IQYJKoZIhvcNAQkBFhR0aGVyYXZlbkBmcmVlYnNkLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALsL5pEhrGjrswHVdMHWhgxb8ARKDYRePSqpDLmjJ40bpx+n1zrvIwjC2Vk2IpoD 04rg5Pog2IrhnX+Qk2NSXzBXWj2JAaTc9OtSeAY0BtgJYXONGONQbRKVy97QBdzd1SbMEzDrOgH5 UDI+5sF1PboOTmLyTAPI9273XdfZ0BnstUXs8NXr/7p9E5CWJOsO1iQcINbm4XiwC1PLNMeWUknE Nji/hFKwcE8IFtaUe1ymbw6yA3rBpDu3KewIRD1T66FPTZJeIzvUoBIqWd+GAOfCBG2QYmbc3y/x K2hCtcXThcB1uVFA2q39koLKA8wHyqv4Jhm3wzhAqKDsWK4bGW0CAwEAAaOCAbcwggGzMA4GA1Ud DwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIwADAdBgNV HQ4EFgQU5J3Kc8GeW8pEGxBkcMoA7eUOPRwwHwYDVR0jBBgwFoAUJIFsOWG+SQ+PtxtGK8kotSdI bWgwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20w OQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGllbnQxLmNy dDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xpZW50MS5j cmwwHwYDVR0RBBgwFoEUdGhlcmF2ZW5AZnJlZWJzZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgUwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQBSBDH+kZf5 bZkNFcMSPdfnGC7F8utBIxs2bi3JQjsBoQTm1vnXdwgINSfO9At6iQZHoEyj8ZE6PcMFuEU0+bk0 aE8aYcW59WnxfWx943upZoMhX0YVaJcFK01EHFrddRAP44sh7Eu6JtdFuAG+6btDReMcg35Qm65X 7/280aVm7awadJ+IQs8r9qBVk2NFqkvHCETtJjNWXd7M6mcsfXstvykbubPQH/VNW/zrX6yzIcI4 aoz+Sn8RJmHNkk6cImqe1KvsdDLXmqCoeoMwos62pT18RaI//jwTdmnf5EHFMlevnxOr7rzA++71 OSZfdYf6+nvHOod1F721rNuy6lxFMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkq hkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50 IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tfrh4bdcC1 Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR+8eklf/EqeZW RLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I7062uHsskM8b7gPxmcC oO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo12SLBO5tbk8h2imbKTC8i Ms+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aMsvi2raFhC643SOGvErWWPPnS EfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5j b20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAW gBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGL hK0PAQJbnOEjJyMEvTTwcAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm 7NKezWVnCHuwb3ptgFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAI hV4L8aaya1u4s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1st p+C7omqM5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8 wBUaBxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe3X+r n0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvSodfiar0w iM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqmRHYj1TjMSw0l Al7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK7zmjozGCA04wggNK AgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3Mg MSBDbGllbnQgQ0ECECJrrb9nBol9MHok/UZg/AYwCQYFKw4DAhoFAKCCAZkwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODIyMDgyMTQ1WjAjBgkqhkiG9w0BCQQx FgQU0yAw7goPuwTK3tBzh1wWFd3OFmAwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJ fTB6JP1GYPwGMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx IzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJfTB6JP1GYPwGMA0G CSqGSIb3DQEBAQUABIIBAJtf0rdznUJOYSgD278yFtDFlyZ7leOZWRFn0cyUe0j7U3ROoUBPKEhI izvmtHald1NFPU6eTcogv1qPT+QnLTQFl/ZOIR9+hd4oi8Bkofm/34c/NH73HfVmXsk79/oh6TuY mYjY/7PTRGC8D1XUZD/dPdqZKv/jhyocrGUZSqYBaLaNjf5db3pKQVz1u2t0GIUOcIhejYEKuHxA t2Lwpv+yguy0UclY3vCL1Zozk4cEE8g5F7n1/N7nLUH+Qc2iQiCkcrKV09DdXoThPyfFjxog/G5E /QUExhvLWWOfLMRfIMws+o7bc3Dxdp3OHsAj1/jH43wWpCPTpAUa6bG28PwAAAAAAAA= --Apple-Mail=_E19F0EEC-3A77-456F-9729-D6DB9ED6362B-- From owner-freebsd-toolchain@freebsd.org Mon Aug 22 15:52:45 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBBB8BC2BCA for ; Mon, 22 Aug 2016 15:52:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAF2C18B9 for ; Mon, 22 Aug 2016 15:52:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7MFqhoI093457 for ; Mon, 22 Aug 2016 15:52:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 192320] Use of thread_local produces linking errors on system version of clang++ Date: Mon, 22 Aug 2016 15:52:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kib@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 15:52:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192320 --- Comment #15 from commit-hook@freebsd.org --- A commit references this bug: Author: bdrewery Date: Mon Aug 22 15:52:04 UTC 2016 New revision: 304608 URL: https://svnweb.freebsd.org/changeset/base/304608 Log: Bump __FreeBSD_version for C++11 thread_local support in r303795. PR: 192320 Changes: head/sys/sys/param.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Aug 22 15:53:49 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97FF8BC2CBB for ; Mon, 22 Aug 2016 15:53:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8722D1BEC for ; Mon, 22 Aug 2016 15:53:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7MFrmx2094972 for ; Mon, 22 Aug 2016 15:53:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 192320] Use of thread_local produces linking errors on system version of clang++ Date: Mon, 22 Aug 2016 15:53:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kib@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 15:53:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192320 --- Comment #16 from commit-hook@freebsd.org --- A commit references this bug: Author: bdrewery Date: Mon Aug 22 15:53:33 UTC 2016 New revision: 304609 URL: https://svnweb.freebsd.org/changeset/base/304609 Log: MFC r304608: Bump __FreeBSD_version for C++11 thread_local support in r303795. PR: 192320 Changes: _U stable/11/ stable/11/sys/sys/param.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Aug 22 16:04:53 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BDD9BC2177 for ; Mon, 22 Aug 2016 16:04:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B013190F for ; Mon, 22 Aug 2016 16:04:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7MG4q94057723 for ; Mon, 22 Aug 2016 16:04:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 192320] Use of thread_local produces linking errors on system version of clang++ Date: Mon, 22 Aug 2016 16:04:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kib@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 16:04:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192320 --- Comment #17 from commit-hook@freebsd.org --- A commit references this bug: Author: bdrewery Date: Mon Aug 22 16:04:25 UTC 2016 New revision: 304610 URL: https://svnweb.freebsd.org/changeset/base/304610 Log: MFS r304609: MFC r304608: Bump __FreeBSD_version for C++11 thread_local support in r303795. PR: 192320 Approved by: re (gjb) Changes: _U releng/11.0/ releng/11.0/sys/sys/param.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Aug 22 16:35:58 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E0BCBC2EAE for ; Mon, 22 Aug 2016 16:35:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 561C615F5 for ; Mon, 22 Aug 2016 16:35:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7MGZvLO025266 for ; Mon, 22 Aug 2016 16:35:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 192320] Use of thread_local produces linking errors on system version of clang++ Date: Mon, 22 Aug 2016 16:35:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kib@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 16:35:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192320 --- Comment #18 from commit-hook@freebsd.org --- A commit references this bug: Author: bdrewery Date: Mon Aug 22 16:35:51 UTC 2016 New revision: 304611 URL: https://svnweb.freebsd.org/changeset/base/304611 Log: MFC r304608: Bump __FreeBSD_version for C++11 thread_local support in r303795. PR: 192320 Changes: _U stable/10/ stable/10/sys/sys/param.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Aug 22 16:38:15 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8FDCBC2F0C for ; Mon, 22 Aug 2016 16:38:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 981C416D0 for ; Mon, 22 Aug 2016 16:38:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7MGcE93028439 for ; Mon, 22 Aug 2016 16:38:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 192320] Use of thread_local produces linking errors on system version of clang++ Date: Mon, 22 Aug 2016 16:38:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bdrewery@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kib@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 16:38:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192320 Bryan Drewery changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Aug 24 10:14:35 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 181F9BBEDEA for ; Wed, 24 Aug 2016 10:14:35 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (gtw.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D94BB1CA0 for ; Wed, 24 Aug 2016 10:14:34 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id F2A7326313; Wed, 24 Aug 2016 12:14:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKGfuHVHdmrs; Wed, 24 Aug 2016 12:14:30 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 2778326312 for ; Wed, 24 Aug 2016 12:14:30 +0200 (CEST) To: FreeBSD Toolchain From: Willem Jan Withagen Subject: name conflict after upgrade to HEAD. Message-ID: <0777433b-66fd-7a16-c8b5-25f6fee7ad31@digiware.nl> Date: Wed, 24 Aug 2016 12:14:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 10:14:35 -0000 Hi, While compile Ceph source code I run into this conflict of the usuage of 'log' Now I've fixed it by prefixing the log with ::log on line 845. Which works for me, but I'm pretty sure that that is not the best solution. Why is this al of a sudden a problem? The log namespace has been in Ceph for a long time. The original namespace block looks like: namespace ceph { class PluginRegistry; class HeartbeatMap; namespace log { class Log; } } So where does this conflict come from? --WjW This is FreeBSD Revision: 304572 and clang: FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin In file included from /usr/include/c++/v1/cmath:301: /usr/include/c++/v1/math.h:845:37: error: reference to 'log' is ambiguous log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);} ^ /usr/include/c++/v1/math.h:845:1: note: candidate found by name lookup is 'log' log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);} ^ /usr/include/c++/v1/math.h:839:46: note: candidate found by name lookup is 'log' inline _LIBCPP_INLINE_VISIBILITY long double log(long double __lcpp_x) _NOEXCEPT {return logl(__lcpp_x);} ^ /usr/include/c++/v1/math.h:838:46: note: candidate found by name lookup is 'log' inline _LIBCPP_INLINE_VISIBILITY float log(float __lcpp_x) _NOEXCEPT {return logf(__lcpp_x);} ^ /usr/include/math.h:247:8: note: candidate found by name lookup is 'log' double log(double); ^ /home/wjw/ceph/src/common/ceph_context.h:44:13: note: candidate found by name lookup is 'ceph::log' namespace log { ^ From owner-freebsd-toolchain@freebsd.org Wed Aug 24 13:24:07 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1F83BC4ED3 for ; Wed, 24 Aug 2016 13:24:07 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9AE41E5A for ; Wed, 24 Aug 2016 13:24:07 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2a03:fc02:2:1:6cd3:14de:4a54:ef50] (unknown [IPv6:2a03:fc02:2:1:6cd3:14de:4a54:ef50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6896A39CD7; Wed, 24 Aug 2016 15:24:04 +0200 (CEST) Subject: Re: name conflict after upgrade to HEAD. Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FAA8B0F9-ABD7-48A5-A015-61E2C75B2FF9"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6.1 From: Dimitry Andric In-Reply-To: <0777433b-66fd-7a16-c8b5-25f6fee7ad31@digiware.nl> Date: Wed, 24 Aug 2016 15:23:57 +0200 Cc: FreeBSD Toolchain Message-Id: <2783A1E7-853F-4361-88BF-362B6C5F4764@andric.com> References: <0777433b-66fd-7a16-c8b5-25f6fee7ad31@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 13:24:08 -0000 --Apple-Mail=_FAA8B0F9-ABD7-48A5-A015-61E2C75B2FF9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 24 Aug 2016, at 12:14, Willem Jan Withagen wrote: > > While compile Ceph source code I run into this conflict of the usuage of > 'log' > > Now I've fixed it by prefixing the log with ::log on line 845. > Which works for me, but I'm pretty sure that that is not the best solution. ... > > In file included from /usr/include/c++/v1/cmath:301: > /usr/include/c++/v1/math.h:845:37: error: reference to 'log' is ambiguous > log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);} Can you show the full command line used to build the offending source file? Usually this is caused by an incorrect include directory search order. And most often, that is caused by build systems inserting -isystem into compile command lines. -Dimitry --Apple-Mail=_FAA8B0F9-ABD7-48A5-A015-61E2C75B2FF9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAle9n/UACgkQsF6jCi4glqMMrgCdFlg7EMEm9a2mybcXAfquAVW3 6RgAoKnBsEFRuYAXcnUw9MnscVLPRVSg =Lc+s -----END PGP SIGNATURE----- --Apple-Mail=_FAA8B0F9-ABD7-48A5-A015-61E2C75B2FF9-- From owner-freebsd-toolchain@freebsd.org Wed Aug 24 14:31:07 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2B32BC2948 for ; Wed, 24 Aug 2016 14:31:07 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 818041A8E for ; Wed, 24 Aug 2016 14:31:06 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 6C92026AC3; Wed, 24 Aug 2016 16:30:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdXqRZ0RUj4d; Wed, 24 Aug 2016 16:30:56 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 893DA26AC2; Wed, 24 Aug 2016 16:30:56 +0200 (CEST) Subject: Re: name conflict after upgrade to HEAD. To: Dimitry Andric References: <0777433b-66fd-7a16-c8b5-25f6fee7ad31@digiware.nl> <2783A1E7-853F-4361-88BF-362B6C5F4764@andric.com> Cc: FreeBSD Toolchain From: Willem Jan Withagen Message-ID: <8892da81-7aa6-20cf-3edd-106d85cd5aef@digiware.nl> Date: Wed, 24 Aug 2016 16:30:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2783A1E7-853F-4361-88BF-362B6C5F4764@andric.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 14:31:08 -0000 On 24-8-2016 15:23, Dimitry Andric wrote: > On 24 Aug 2016, at 12:14, Willem Jan Withagen wrote: >> >> While compile Ceph source code I run into this conflict of the usuage of >> 'log' >> >> Now I've fixed it by prefixing the log with ::log on line 845. >> Which works for me, but I'm pretty sure that that is not the best solution. > ... >> >> In file included from /usr/include/c++/v1/cmath:301: >> /usr/include/c++/v1/math.h:845:37: error: reference to 'log' is ambiguous >> log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);} > > Can you show the full command line used to build the offending source > file? Usually this is caused by an incorrect include directory search > order. And most often, that is caused by build systems inserting > -isystem into compile command lines. Hi Dimitry, This is the full output of the failing compile --WjW [ 3%] Building CXX object src/CMakeFiles/common.dir/common/perf_counters.cc.o cd /home/wjw/ceph/build/src && /usr/bin/CC -DCEPH_LIBDIR=\"/usr/local/lib\" -DCEPH_PKGLIBDIR=\"/usr/local/lib/ceph\" -I/home/wjw/ceph/build/src/include -I/home/wjw/ceph/src -I/usr/local/include -I/home/wjw/ceph/build/include -I/home/wjw/ceph/src/xxHash -Wall -Wtype-limits -Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security -fno-strict-aliasing -fsigned-char -Wno-inconsistent-missing-override -Wno-mismatched-tags -Wno-unused-function -Wno-unused-local-typedef -Wno-inconsistent-missing-override -Wno-unused-private-field -Wno-varargs -Wno-gnu-designator -Wno-mismatched-tags -Wno-missing-braces -Wno-parentheses -Wno-deprecated-register -ftemplate-depth-1024 -Wno-invalid-offsetof -Wnon-virtual-dtor -Wno-overloaded-virtual -fdiagnostics-color=auto -I/usr/local/include/nss/nss -I/usr/local/include/nspr -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -O0 -g -fPIC -DHAVE_CONFIG_H -D__CEPH__ -D_REENTRANT -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -std=c++11 -o CMakeFiles/common.dir/common/perf_counters.cc.o -c /home/wjw/ceph/src/common/perf_counters.cc In file included from /home/wjw/ceph/src/common/perf_counters.cc:17: In file included from /home/wjw/ceph/src/common/perf_counters.h:21: In file included from /home/wjw/ceph/src/include/utime.h:18: /usr/include/c++/v1/math.h:845:37: error: reference to 'log' is ambiguous log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);} ^ /usr/include/c++/v1/math.h:845:1: note: candidate found by name lookup is 'log' log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);} ^ /usr/include/c++/v1/math.h:839:46: note: candidate found by name lookup is 'log' inline _LIBCPP_INLINE_VISIBILITY long double log(long double __lcpp_x) _NOEXCEPT {return logl(__lcpp_x);} ^ /usr/include/c++/v1/math.h:838:46: note: candidate found by name lookup is 'log' inline _LIBCPP_INLINE_VISIBILITY float log(float __lcpp_x) _NOEXCEPT {return logf(__lcpp_x);} ^ /usr/include/math.h:247:8: note: candidate found by name lookup is 'log' double log(double); ^ /home/wjw/ceph/src/common/ceph_context.h:44:13: note: candidate found by name lookup is 'ceph::log' namespace log { ^ 1 error generated. gmake[2]: *** [src/CMakeFiles/common.dir/build.make:208: src/CMakeFiles/common.dir/common/perf_counters.cc.o] Error 1 gmake[2]: Leaving directory '/usr/srcs/Ceph/work/ceph/build' gmake[1]: *** [CMakeFiles/Makefile2:380: src/CMakeFiles/common.dir/all] Error 2 gmake[1]: Leaving directory '/usr/srcs/Ceph/work/ceph/build' gmake: *** [Makefile:139: all] Error 2 235.883u 5.236s 4:01.13 99.9% 129523+964k 642+267342io 8646pf+0w Exit 2 From owner-freebsd-toolchain@freebsd.org Thu Aug 25 07:07:03 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C9B9BB7CA8 for ; Thu, 25 Aug 2016 07:07:03 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0408819EC for ; Thu, 25 Aug 2016 07:07:02 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7::e1f3:a144:11be:3140] (unknown [IPv6:2001:7b8:3a7:0:e1f3:a144:11be:3140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A4BCD39D57; Thu, 25 Aug 2016 09:06:53 +0200 (CEST) Subject: Re: name conflict after upgrade to HEAD. Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_64E84B92-AD2D-460A-8ED2-6EEDF70170AB"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6.1 From: Dimitry Andric In-Reply-To: <8892da81-7aa6-20cf-3edd-106d85cd5aef@digiware.nl> Date: Thu, 25 Aug 2016 09:06:42 +0200 Cc: FreeBSD Toolchain Message-Id: <098B0C71-3287-49B6-A80F-25A63087134F@andric.com> References: <0777433b-66fd-7a16-c8b5-25f6fee7ad31@digiware.nl> <2783A1E7-853F-4361-88BF-362B6C5F4764@andric.com> <8892da81-7aa6-20cf-3edd-106d85cd5aef@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 07:07:03 -0000 --Apple-Mail=_64E84B92-AD2D-460A-8ED2-6EEDF70170AB Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 On 24 Aug 2016, at 16:30, Willem Jan Withagen wrote: > > On 24-8-2016 15:23, Dimitry Andric wrote: ... >> Can you show the full command line used to build the offending source >> file? Usually this is caused by an incorrect include directory search >> order. And most often, that is caused by build systems inserting >> -isystem into compile command lines. > > This is the full output of the failing compile > > --WjW > > [ 3%] Building CXX object > src/CMakeFiles/common.dir/common/perf_counters.cc.o > cd /home/wjw/ceph/build/src && /usr/bin/CC > -DCEPH_LIBDIR=\"/usr/local/lib\" > -DCEPH_PKGLIBDIR=\"/usr/local/lib/ceph\" > -I/home/wjw/ceph/build/src/include -I/home/wjw/ceph/src > -I/usr/local/include -I/home/wjw/ceph/build/include > -I/home/wjw/ceph/src/xxHash -Wall -Wtype-limits -Wignored-qualifiers > -Winit-self -Wpointer-arith -Werror=format-security -fno-strict-aliasing > -fsigned-char -Wno-inconsistent-missing-override -Wno-mismatched-tags > -Wno-unused-function -Wno-unused-local-typedef > -Wno-inconsistent-missing-override -Wno-unused-private-field > -Wno-varargs -Wno-gnu-designator -Wno-mismatched-tags > -Wno-missing-braces -Wno-parentheses -Wno-deprecated-register > -ftemplate-depth-1024 -Wno-invalid-offsetof -Wnon-virtual-dtor > -Wno-overloaded-virtual -fdiagnostics-color=auto > -I/usr/local/include/nss/nss -I/usr/local/include/nspr > -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc > -fno-builtin-free -O0 -g -fPIC -DHAVE_CONFIG_H -D__CEPH__ -D_REENTRANT > -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -std=c++11 -o > CMakeFiles/common.dir/common/perf_counters.cc.o -c > /home/wjw/ceph/src/common/perf_counters.cc > In file included from /home/wjw/ceph/src/common/perf_counters.cc:17: > In file included from /home/wjw/ceph/src/common/perf_counters.h:21: > In file included from /home/wjw/ceph/src/include/utime.h:18: > /usr/include/c++/v1/math.h:845:37: error: reference to 'log' is ambiguous > log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);} > ^ > /usr/include/c++/v1/math.h:845:1: note: candidate found by name lookup > is 'log' > log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);} > ^ > /usr/include/c++/v1/math.h:839:46: note: candidate found by name lookup > is 'log' > inline _LIBCPP_INLINE_VISIBILITY long double log(long double __lcpp_x) > _NOEXCEPT {return logl(__lcpp_x);} > ^ > /usr/include/c++/v1/math.h:838:46: note: candidate found by name lookup > is 'log' > inline _LIBCPP_INLINE_VISIBILITY float log(float __lcpp_x) > _NOEXCEPT {return logf(__lcpp_x);} > ^ > /usr/include/math.h:247:8: note: candidate found by name lookup is 'log' > double log(double); > ^ > /home/wjw/ceph/src/common/ceph_context.h:44:13: note: candidate found by > name lookup is 'ceph::log' > namespace log { > ^ Okay, no -isystem options there. So that's not it. Now I'm assuming this is because the original .cc file includes , which imports a global "log" symbol. Can you try changing that include to ? However, this could require prefixing some math function calls with std::. -Dimitry --Apple-Mail=_64E84B92-AD2D-460A-8ED2-6EEDF70170AB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAle+mQ0ACgkQsF6jCi4glqNnEwCdH4HZVZAI+s8EscuqGIO9M8g5 ga8AoPZ+Zfk0s/cag3hwCkhz+89a8CKS =NavC -----END PGP SIGNATURE----- --Apple-Mail=_64E84B92-AD2D-460A-8ED2-6EEDF70170AB-- From owner-freebsd-toolchain@freebsd.org Thu Aug 25 10:19:54 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7620BBC53A3 for ; Thu, 25 Aug 2016 10:19:54 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 093191CBF for ; Thu, 25 Aug 2016 10:19:53 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 4273B26F84; Thu, 25 Aug 2016 12:19:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaVvLBcT2IA3; Thu, 25 Aug 2016 12:19:50 +0200 (CEST) Received: from [IPv6:2001:4cb8:90:1:d027:7f40:7841:3039] (unknown [IPv6:2001:4cb8:90:1:d027:7f40:7841:3039]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 0C72626F83; Thu, 25 Aug 2016 12:19:50 +0200 (CEST) Subject: Re: name conflict after upgrade to HEAD. To: Dimitry Andric References: <0777433b-66fd-7a16-c8b5-25f6fee7ad31@digiware.nl> <2783A1E7-853F-4361-88BF-362B6C5F4764@andric.com> <8892da81-7aa6-20cf-3edd-106d85cd5aef@digiware.nl> <098B0C71-3287-49B6-A80F-25A63087134F@andric.com> Cc: FreeBSD Toolchain From: Willem Jan Withagen Message-ID: <861853e6-4749-8b80-c1f0-05998f13ab78@digiware.nl> Date: Thu, 25 Aug 2016 12:19:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <098B0C71-3287-49B6-A80F-25A63087134F@andric.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 10:19:54 -0000 On 25-8-2016 09:06, Dimitry Andric wrote: > On 24 Aug 2016, at 16:30, Willem Jan Withagen wrote: >> >> On 24-8-2016 15:23, Dimitry Andric wrote: > ... >>> Can you show the full command line used to build the offending source >>> file? Usually this is caused by an incorrect include directory search >>> order. And most often, that is caused by build systems inserting >>> -isystem into compile command lines. >> >> This is the full output of the failing compile >> >> --WjW >> >> [ 3%] Building CXX object >> src/CMakeFiles/common.dir/common/perf_counters.cc.o >> cd /home/wjw/ceph/build/src && /usr/bin/CC >> -DCEPH_LIBDIR=\"/usr/local/lib\" >> -DCEPH_PKGLIBDIR=\"/usr/local/lib/ceph\" >> -I/home/wjw/ceph/build/src/include -I/home/wjw/ceph/src >> -I/usr/local/include -I/home/wjw/ceph/build/include >> -I/home/wjw/ceph/src/xxHash -Wall -Wtype-limits -Wignored-qualifiers >> -Winit-self -Wpointer-arith -Werror=format-security -fno-strict-aliasing >> -fsigned-char -Wno-inconsistent-missing-override -Wno-mismatched-tags >> -Wno-unused-function -Wno-unused-local-typedef >> -Wno-inconsistent-missing-override -Wno-unused-private-field >> -Wno-varargs -Wno-gnu-designator -Wno-mismatched-tags >> -Wno-missing-braces -Wno-parentheses -Wno-deprecated-register >> -ftemplate-depth-1024 -Wno-invalid-offsetof -Wnon-virtual-dtor >> -Wno-overloaded-virtual -fdiagnostics-color=auto >> -I/usr/local/include/nss/nss -I/usr/local/include/nspr >> -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc >> -fno-builtin-free -O0 -g -fPIC -DHAVE_CONFIG_H -D__CEPH__ -D_REENTRANT >> -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -std=c++11 -o >> CMakeFiles/common.dir/common/perf_counters.cc.o -c >> /home/wjw/ceph/src/common/perf_counters.cc >> In file included from /home/wjw/ceph/src/common/perf_counters.cc:17: >> In file included from /home/wjw/ceph/src/common/perf_counters.h:21: >> In file included from /home/wjw/ceph/src/include/utime.h:18: >> /usr/include/c++/v1/math.h:845:37: error: reference to 'log' is ambiguous >> log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);} >> ^ >> /usr/include/c++/v1/math.h:845:1: note: candidate found by name lookup >> is 'log' >> log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);} >> ^ >> /usr/include/c++/v1/math.h:839:46: note: candidate found by name lookup >> is 'log' >> inline _LIBCPP_INLINE_VISIBILITY long double log(long double __lcpp_x) >> _NOEXCEPT {return logl(__lcpp_x);} >> ^ >> /usr/include/c++/v1/math.h:838:46: note: candidate found by name lookup >> is 'log' >> inline _LIBCPP_INLINE_VISIBILITY float log(float __lcpp_x) >> _NOEXCEPT {return logf(__lcpp_x);} >> ^ >> /usr/include/math.h:247:8: note: candidate found by name lookup is 'log' >> double log(double); >> ^ >> /home/wjw/ceph/src/common/ceph_context.h:44:13: note: candidate found by >> name lookup is 'ceph::log' >> namespace log { >> ^ > > > Okay, no -isystem options there. So that's not it. Now I'm assuming > this is because the original .cc file includes , which imports a > global "log" symbol. Can you try changing that include to ? > However, this could require prefixing some math function calls with > std::. That did not work either. Same stack of errors, only now "includes/utimes.h" calls calls math.h on the next include. Problem is still with the inclusion of the std math stuff. And yes, namespace ceph{ namespace log{ ... } } is included before this. But I'd expect the ceph::log not to conflict with {std::}log. Compiler however thinks otherwise. Needless to say that GCC does not complain and "does the expected". (I'm not going to say: ther right thing) --WjW From owner-freebsd-toolchain@freebsd.org Thu Aug 25 22:50:31 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 908F0BC56D3 for ; Thu, 25 Aug 2016 22:50:31 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A0B01EB6 for ; Thu, 25 Aug 2016 22:50:31 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472165423; bh=GKNRfeb5g1tGX4sRl94pyBnwI76AY8W8PTeKKPKmkeA=; h=To:From:Subject:Date:From:Subject; b=doGUTw8wsLUMdzwRVAScMQ8A4s33HcxlsoNqjm8fuBTdpWeLGb83LZ1h78RGnqTpOpdJa8wFzK3DiFvY6/vKI2ccAal6Gukq9C3MPmGXoAzyCAOOOZEr/HV1yxxUNeCe1Mwkg6GuwwwV++S8Hs7+MgajEOcycZw3giQacSBAvKyJSo4wxyAecECm1SBvtcwsYpqXZZ2iuayi0U+1913ZFK3MJVXk5gSmz/T00ug1I9G21kTXr0iMOtEUqibq+Fd8C19Olzi7MN953bA2BhOREOkx5L01gmd5/QOw5pCePnru/JhwrWbr3oeb2o4AJakgoRXNpJC3JaRc/C3JFKkGjg== Received: from [98.139.170.182] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 25 Aug 2016 22:50:23 -0000 Received: from [98.139.211.193] by tm25.bullet.mail.bf1.yahoo.com with NNFMP; 25 Aug 2016 22:50:23 -0000 Received: from [127.0.0.1] by smtp202.mail.bf1.yahoo.com with NNFMP; 25 Aug 2016 22:50:23 -0000 X-Yahoo-Newman-Id: 896128.20032.bm@smtp202.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .5ncuuwVM1kjwRqFRFsqDSjTRBgy_TB301DX590iPFv8pku ok1X_bDPb0MvdxVlkIeTM4I9cg8.GyfZnIJxafF3bxrniKcMVGDkySqpjLTE E6E.tKq2.5AFx4NCCslAblPUvOWAUZcGXkGd8ISSe2SRAXIzsW8EZhzyZKsE YHIs6qSRwoX6NenV0MeQbKQZJUSe3lQcjLv6dgBcqEbbttNbOZJjrCpk.Egn fIPKjiff5XKPYQRYz5ljhyMnojaGlflqZuCzhQZgLuWVxZBOwQvCsB7lomw3 wtgTg5Vuqc4ewsB1EE8bKDklo_SgN.t.efU5IW14W3ZwRWM9Mycx2GxCmc21 fX_hDCvlIdpJjJycosEhpd2R9ptc1RwrbcqWjp0Iy8ivFkRoN85f6._h_Dx7 eZ_WXLSYwIP7MmM_UCxjl0eUKE9YfMT7XvnsTVvcRZp_uLzas8LPCsgZs_F2 QNpLaa8IwLtdY0UPIrHaoOflKu0HLG3zNbOoxV1Hiya6Wm9zjFd8UdYNw7dF .n7tczw9iEXPk_iSBpoPrfly6y4HHrsANJK5lV31ML8fQGw-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf To: freebsd-toolchain@FreeBSD.org From: Pedro Giffuni Subject: Time to enable partial relro Message-ID: Date: Thu, 25 Aug 2016 17:50:31 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------B7BF4F72F4202B122F41AEA1" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 22:50:31 -0000 This is a multi-part message in MIME format. --------------B7BF4F72F4202B122F41AEA1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello; GNU RELRO support was committed in r230784 (2012-01-30) but we never enabled it by default. There was some discussion about it on https://reviews.freebsd.org/D3001 By now, all Linux distributions, NetBSD and DragonFly support it and it is the default for most systems in binutils 2.27. This doesn't affect performance, I ran it through an exp-run last year, no other OS has had issues etc ... seems safe and can be disabled if needed when linking. I think it's time to enable it be default in our base binutils. If there are no objections, I will just commit the attached patch over the weekend. Regards, Pedro. --------------B7BF4F72F4202B122F41AEA1 Content-Type: text/x-patch; name="partial-relro.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="partial-relro.diff" Index: contrib/binutils/ld/emultempl/elf32.em =================================================================== --- contrib/binutils/ld/emultempl/elf32.em (revision 304807) +++ contrib/binutils/ld/emultempl/elf32.em (working copy) @@ -97,6 +97,7 @@ ldfile_set_output_arch ("${OUTPUT_ARCH}", bfd_arch_`echo ${ARCH} | sed -e 's/:.*//'`); config.dynamic_link = ${DYNAMIC_LINK-TRUE}; config.has_shared = `if test -n "$GENERATE_SHLIB_SCRIPT" ; then echo TRUE ; else echo FALSE ; fi`; + link_info.relro = TRUE; } EOF --------------B7BF4F72F4202B122F41AEA1-- From owner-freebsd-toolchain@freebsd.org Fri Aug 26 10:56:24 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FD2EA94111 for ; Fri, 26 Aug 2016 10:56:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2DF2935; Fri, 26 Aug 2016 10:56:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u7QAuI8u062139 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 26 Aug 2016 13:56:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7QAuI8u062139 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7QAuIH1062138; Fri, 26 Aug 2016 13:56:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 26 Aug 2016 13:56:18 +0300 From: Konstantin Belousov To: Pedro Giffuni Cc: freebsd-toolchain@FreeBSD.org Subject: Re: Time to enable partial relro Message-ID: <20160826105618.GS83214@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 10:56:24 -0000 On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: > Hello; > > GNU RELRO support was committed in r230784 (2012-01-30) but we never > enabled it by default. > > There was some discussion about it on > https://reviews.freebsd.org/D3001 > > By now, all Linux distributions, NetBSD and DragonFly support it and > it is the default for most systems in binutils 2.27. > > This doesn't affect performance, I ran it through an exp-run last > year, no other OS has had issues etc ... seems safe and can be > disabled if needed when linking. Exp-run does not test anything interesting about relro. If all testing that was done is basically just an exp-run, then there was no useful runtime testing done. > > I think it's time to enable it be default in our base binutils. If > there are no objections, I will just commit the attached patch over > the weekend. There are objections, the change must be runtime tested on large and representative set of real-world applications before turning the knob. From owner-freebsd-toolchain@freebsd.org Fri Aug 26 10:58:49 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CE3AA94142 for ; Fri, 26 Aug 2016 10:58:49 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D931979; Fri, 26 Aug 2016 10:58:48 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u7QAwemA095768 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2016 10:58:42 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: multipart/signed; boundary="Apple-Mail=_2A4FF392-6C07-4AC1-AE6B-48A36D7CA960"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Time to enable partial relro From: David Chisnall In-Reply-To: <20160826105618.GS83214@kib.kiev.ua> Date: Fri, 26 Aug 2016 11:58:51 +0100 Cc: Pedro Giffuni , freebsd-toolchain@FreeBSD.org Message-Id: <16BFC2DC-3571-4817-A104-D0C4BC8E2EA1@FreeBSD.org> References: <20160826105618.GS83214@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 10:58:49 -0000 --Apple-Mail=_2A4FF392-6C07-4AC1-AE6B-48A36D7CA960 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 Aug 2016, at 11:56, Konstantin Belousov = wrote: >=20 >> I think it's time to enable it be default in our base binutils. If >> there are no objections, I will just commit the attached patch over >> the weekend. >=20 > There are objections, the change must be runtime tested on large and > representative set of real-world applications before turning the knob. Can portmgr create a temporary package set with the knob turned so that = people can test easily? David --Apple-Mail=_2A4FF392-6C07-4AC1-AE6B-48A36D7CA960 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCCBPww ggPkoAMCAQICECJrrb9nBol9MHok/UZg/AYwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTAeFw0xNjA0MTkw OTI3NDJaFw0xNzA0MTkwOTI3NDJaMEQxHTAbBgNVBAMMFHRoZXJhdmVuQGZyZWVic2Qub3JnMSMw IQYJKoZIhvcNAQkBFhR0aGVyYXZlbkBmcmVlYnNkLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALsL5pEhrGjrswHVdMHWhgxb8ARKDYRePSqpDLmjJ40bpx+n1zrvIwjC2Vk2IpoD 04rg5Pog2IrhnX+Qk2NSXzBXWj2JAaTc9OtSeAY0BtgJYXONGONQbRKVy97QBdzd1SbMEzDrOgH5 UDI+5sF1PboOTmLyTAPI9273XdfZ0BnstUXs8NXr/7p9E5CWJOsO1iQcINbm4XiwC1PLNMeWUknE Nji/hFKwcE8IFtaUe1ymbw6yA3rBpDu3KewIRD1T66FPTZJeIzvUoBIqWd+GAOfCBG2QYmbc3y/x K2hCtcXThcB1uVFA2q39koLKA8wHyqv4Jhm3wzhAqKDsWK4bGW0CAwEAAaOCAbcwggGzMA4GA1Ud DwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIwADAdBgNV HQ4EFgQU5J3Kc8GeW8pEGxBkcMoA7eUOPRwwHwYDVR0jBBgwFoAUJIFsOWG+SQ+PtxtGK8kotSdI bWgwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20w OQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGllbnQxLmNy dDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xpZW50MS5j cmwwHwYDVR0RBBgwFoEUdGhlcmF2ZW5AZnJlZWJzZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgUwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQBSBDH+kZf5 bZkNFcMSPdfnGC7F8utBIxs2bi3JQjsBoQTm1vnXdwgINSfO9At6iQZHoEyj8ZE6PcMFuEU0+bk0 aE8aYcW59WnxfWx943upZoMhX0YVaJcFK01EHFrddRAP44sh7Eu6JtdFuAG+6btDReMcg35Qm65X 7/280aVm7awadJ+IQs8r9qBVk2NFqkvHCETtJjNWXd7M6mcsfXstvykbubPQH/VNW/zrX6yzIcI4 aoz+Sn8RJmHNkk6cImqe1KvsdDLXmqCoeoMwos62pT18RaI//jwTdmnf5EHFMlevnxOr7rzA++71 OSZfdYf6+nvHOod1F721rNuy6lxFMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkq hkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50 IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tfrh4bdcC1 Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR+8eklf/EqeZW RLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I7062uHsskM8b7gPxmcC oO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo12SLBO5tbk8h2imbKTC8i Ms+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aMsvi2raFhC643SOGvErWWPPnS EfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5j b20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAW gBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGL hK0PAQJbnOEjJyMEvTTwcAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm 7NKezWVnCHuwb3ptgFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAI hV4L8aaya1u4s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1st p+C7omqM5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8 wBUaBxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe3X+r n0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvSodfiar0w iM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqmRHYj1TjMSw0l Al7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK7zmjozGCA04wggNK AgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3Mg MSBDbGllbnQgQ0ECECJrrb9nBol9MHok/UZg/AYwCQYFKw4DAhoFAKCCAZkwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODI2MTA1ODUyWjAjBgkqhkiG9w0BCQQx FgQUARkACQEFrZPtAg2X/KL2erbRZSgwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJ fTB6JP1GYPwGMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx IzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJfTB6JP1GYPwGMA0G CSqGSIb3DQEBAQUABIIBABRT2ieUEkMHp4bNblhxeqSq15X5whHTwflZjf194NcQEfatQietFLkV nqj+L5cRDtBZsh3XmnF/QyQf7emOEo7Yb6nDTNhx0Z7xJzfvEEa1N91XsccmP8mHXQNYweEkiz1F Gd5OVEWCmbPCph/elRNPC9l00JU+nnEoOtfuE4vjeJt7CWS68jdekiylXmxnKXkK8gwavXx/8GUX 5JGxrjnKARXNt1A2xNQ6JliFtCAQBd6b9kq1zSeElMvvUJPgHMV1kqVBVqHHy1WeoAvC1sm7HBa5 eEstTpVGTnZX7ZzozGL928z4RpHziIfE//wvlhZ51aD9d6ecXMWEibyUIDsAAAAAAAA= --Apple-Mail=_2A4FF392-6C07-4AC1-AE6B-48A36D7CA960-- From owner-freebsd-toolchain@freebsd.org Fri Aug 26 14:18:23 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0021B714CD for ; Fri, 26 Aug 2016 14:18:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA1A1F80 for ; Fri, 26 Aug 2016 14:18:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id x131so333710023ite.0 for ; Fri, 26 Aug 2016 07:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=N8PUubgcYVs0BrsURuDJ1EDAr5XTHyi+i/psq4+DOCE=; b=NWcrkPHig8YupVo+B5bIEeePcwPSCLiwn8q6ZGKmo9Q9SzHi+S50iD0fhCOmAghOc6 buW9UkHgfwBBDGwVW11NSF1myZfDkDfedrEPNE3bvrroUH/YdTawDV94k1BDTjd8n/r8 oV99I6N8zRUSbwpoU/dCRaB2JhdXLJZItoOEbYK2dr98MOVgrB/ap7K8HmJv5MLGVp1I qIau3XTmO6wJl2kjjBtbLMzcB8g5kMSUas0ois04MTEZ2XGGa+HhbllyHCBaTwZr88R8 YEbdNFIewHvJo/3m6E2yJCWxxqHNmQtMkezkcQfx42arzaooQL4oRgx6ywFBQ672ft1x 3H2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=N8PUubgcYVs0BrsURuDJ1EDAr5XTHyi+i/psq4+DOCE=; b=IX/8Wf80oRIzXBh/Aib4XGC1LWG/dVFPYj4Ei5C/YGsMWUYX6iFNsCb8qMtyWcsrJ/ fsaCyG7yr+t/YYwRD0Uuvb71Hsix+Zg1vAT0M0gsfr14eGbngtRCq1bUnajDTMdRadrE LYYjlGs+k3VikIjTAsYaWeJYPUISgcDJ/ShLibAJ8XCRbP5vhydsf6iDVVgIF3NgQnmA tB3YPeR7yq04q0+gOtKDqFkdyKBpFezeksH+6YK6KDUy9Z5bHGB3Sx9sely8YOHovD2i OMYtuTvySzCNDheBUY2LX+lUCsS71sSWsAZtay2Q7Sw4vEHpbVXvOZKqBGiwrJYD15Ec JcxQ== X-Gm-Message-State: AE9vXwNOfBpcdJO9AfUA/75yokf2zXeQh+M9PzEn6/to3DjgF5HlN8RkG0vu26XYRMZqj9OCfs2lF7/bJqhL0w== X-Received: by 10.107.21.134 with SMTP id 128mr4192818iov.59.1472221103078; Fri, 26 Aug 2016 07:18:23 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.7 with HTTP; Fri, 26 Aug 2016 07:18:22 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: From: Warner Losh Date: Fri, 26 Aug 2016 08:18:22 -0600 X-Google-Sender-Auth: fRXMVF6KMx8NjbSBrVm438jO7VI Message-ID: Subject: Re: Time to enable partial relro To: Pedro Giffuni Cc: "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 14:18:24 -0000 On Thu, Aug 25, 2016 at 4:50 PM, Pedro Giffuni wrote: > Hello; > > GNU RELRO support was committed in r230784 (2012-01-30) but we never enabled > it by default. So what's the summary of why we'd want to do that? What benefit does it bring? Sure, other folks do it, but why? Warner From owner-freebsd-toolchain@freebsd.org Fri Aug 26 14:35:43 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6092EB71AC8 for ; Fri, 26 Aug 2016 14:35:43 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 20426B34 for ; Fri, 26 Aug 2016 14:35:43 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x22a.google.com with SMTP id r9so49536510ywg.0 for ; Fri, 26 Aug 2016 07:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SVYPM77/KbqV7vZlKyxWjtSANw1LWAyPMLAh2Ynikxc=; b=UZCtTFRxD9kUalWMiwWEWzZehQT+vNHvfp9DsNneN9IF5KXyszRsNOpxqQJUyixQQv JyOJs4Z9Sn9kGzroXU0weOP0jWzMPF1+OITV6LrKJgfec4y9so5xwBcxbiNJlf9Ud+az HeoS8doP4tvX3zzsr+7d0i9UqQX8hv11kfIb9PfZK7utPknaz+mhj+htUvOunMYip6wp RcK4xAqzWNCT7QWdvrtRDHJKRgrkuqw8bEQ6nK2XpBDo0CXV7bSK5rDCBqy7m2GwZE9D wlZARrRtnl+Cgd28N2BcBQXedUReOQ01iB1zVFSGL60GlHPVPRyL47kw9diSVcvsmVJ6 TaaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SVYPM77/KbqV7vZlKyxWjtSANw1LWAyPMLAh2Ynikxc=; b=R4a8U842T+f8+z4x5JFTPkO5mDXLBBJM24jym6CyHgCPqBJLD074uDYvcXlT0KmGqI btRZ1ZnTehqyngZW1QFQsUa9oIiqA/9XYmjj6Ta62l/k4ql9d9EDXhiCa4SzfMLkIuNY 8Dk1dQPg4Zj4dlzVbLiVJtXPj3+flnD7UR+Q6Lmr2WCmSmv2frkwG0VMiG5M3XeGxuek sR66DdQALtST0S32MH7FKm9404DXJCo0YNeZe/wdbkYqPMOdGn2jf4nzeNAyM1GXMH+I gITGIFb0jx/csGy2YQuYRqo6R1e1aYd9pMxya3l43dYImf+SHV9KEnCsLFenoEhylpfF Z46w== X-Gm-Message-State: AE9vXwMOvGNu8P+d3U1BHbFxB3B0zkgh5xYDMv71kbXMETyWU9EG9RayX7G4/xl/ltVJBPbxlEmkee5EY1EF0A== X-Received: by 10.129.122.7 with SMTP id v7mr3258082ywc.219.1472222142346; Fri, 26 Aug 2016 07:35:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.201.71 with HTTP; Fri, 26 Aug 2016 07:35:41 -0700 (PDT) In-Reply-To: References: From: Ed Schouten Date: Fri, 26 Aug 2016 16:35:41 +0200 Message-ID: Subject: Re: Time to enable partial relro To: Warner Losh Cc: Pedro Giffuni , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 14:35:43 -0000 2016-08-26 16:18 GMT+02:00 Warner Losh : >> GNU RELRO support was committed in r230784 (2012-01-30) but we never enabled >> it by default. > > So what's the summary of why we'd want to do that? What benefit does it bring? > Sure, other folks do it, but why? In a nutshell: ELF files that contain relocations (shared libraries, dynamically linked and/or position-independent executables) typically contain pages of memory that can be marked read-only (i.e., they only contain constants). Unfortunately, they had to be marked for writing, for the reason that rtld had to walk over them to apply the relocations on startup. GNU added an extension to their linker, making it group together all of such constants in consecutive pages, while also making it add a special record to the ELF file (RELRO). This record can be used by rtld to mprotect(PROT_READ) the range after relocating is finished. In other words, it means that global constants actually become constant again. It makes it easier to detect programming mistakes (accidentally discarding const qualifiers and writing). -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-toolchain@freebsd.org Fri Aug 26 14:36:26 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8598DB71AEB for ; Fri, 26 Aug 2016 14:36:26 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50D79B71; Fri, 26 Aug 2016 14:36:26 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from c124.sec.cl.cam.ac.uk (c124.sec.cl.cam.ac.uk [128.232.18.124]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u7QEaMYm096712 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2016 14:36:23 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_FEE99771-1460-4CAE-B0DD-C432D6A57CD4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Time to enable partial relro From: David Chisnall In-Reply-To: Date: Fri, 26 Aug 2016 15:36:39 +0100 Cc: Pedro Giffuni , "freebsd-toolchain@FreeBSD.org" Message-Id: <0DDF18BF-E867-4275-AC5F-D52E5B543BD7@FreeBSD.org> References: To: Warner Losh X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 14:36:26 -0000 --Apple-Mail=_FEE99771-1460-4CAE-B0DD-C432D6A57CD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 26 Aug 2016, at 15:18, Warner Losh wrote: >=20 > So what's the summary of why we'd want to do that? What benefit does = it bring? > Sure, other folks do it, but why? It reduce the attack surface for code reuse attacks: non-PLT GOT entries = are read-only and so can=E2=80=99t be manipulated by a memory safety = bug. It doesn=E2=80=99t provide much mitigation, but it also doesn=E2=80=99= t cost very much - some security for a negligible cost is probably a = sensible thing to pick. When combined with RTLD_NOW, it provides more hardening, but at a much = more significant cost (bigger startup times - much bigger for things = like OpenOffice or Firefox, some forms of interposition break, and so = on). That=E2=80=99s still probably worth it for some things (sshd, for = example). David --Apple-Mail=_FEE99771-1460-4CAE-B0DD-C432D6A57CD4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCCBPww ggPkoAMCAQICECJrrb9nBol9MHok/UZg/AYwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTAeFw0xNjA0MTkw OTI3NDJaFw0xNzA0MTkwOTI3NDJaMEQxHTAbBgNVBAMMFHRoZXJhdmVuQGZyZWVic2Qub3JnMSMw IQYJKoZIhvcNAQkBFhR0aGVyYXZlbkBmcmVlYnNkLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALsL5pEhrGjrswHVdMHWhgxb8ARKDYRePSqpDLmjJ40bpx+n1zrvIwjC2Vk2IpoD 04rg5Pog2IrhnX+Qk2NSXzBXWj2JAaTc9OtSeAY0BtgJYXONGONQbRKVy97QBdzd1SbMEzDrOgH5 UDI+5sF1PboOTmLyTAPI9273XdfZ0BnstUXs8NXr/7p9E5CWJOsO1iQcINbm4XiwC1PLNMeWUknE Nji/hFKwcE8IFtaUe1ymbw6yA3rBpDu3KewIRD1T66FPTZJeIzvUoBIqWd+GAOfCBG2QYmbc3y/x K2hCtcXThcB1uVFA2q39koLKA8wHyqv4Jhm3wzhAqKDsWK4bGW0CAwEAAaOCAbcwggGzMA4GA1Ud DwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIwADAdBgNV HQ4EFgQU5J3Kc8GeW8pEGxBkcMoA7eUOPRwwHwYDVR0jBBgwFoAUJIFsOWG+SQ+PtxtGK8kotSdI bWgwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20w OQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGllbnQxLmNy dDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xpZW50MS5j cmwwHwYDVR0RBBgwFoEUdGhlcmF2ZW5AZnJlZWJzZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgUwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQBSBDH+kZf5 bZkNFcMSPdfnGC7F8utBIxs2bi3JQjsBoQTm1vnXdwgINSfO9At6iQZHoEyj8ZE6PcMFuEU0+bk0 aE8aYcW59WnxfWx943upZoMhX0YVaJcFK01EHFrddRAP44sh7Eu6JtdFuAG+6btDReMcg35Qm65X 7/280aVm7awadJ+IQs8r9qBVk2NFqkvHCETtJjNWXd7M6mcsfXstvykbubPQH/VNW/zrX6yzIcI4 aoz+Sn8RJmHNkk6cImqe1KvsdDLXmqCoeoMwos62pT18RaI//jwTdmnf5EHFMlevnxOr7rzA++71 OSZfdYf6+nvHOod1F721rNuy6lxFMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkq hkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50 IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tfrh4bdcC1 Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR+8eklf/EqeZW RLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I7062uHsskM8b7gPxmcC oO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo12SLBO5tbk8h2imbKTC8i Ms+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aMsvi2raFhC643SOGvErWWPPnS EfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5j b20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAW gBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGL hK0PAQJbnOEjJyMEvTTwcAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm 7NKezWVnCHuwb3ptgFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAI hV4L8aaya1u4s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1st p+C7omqM5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8 wBUaBxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe3X+r n0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvSodfiar0w iM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqmRHYj1TjMSw0l Al7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK7zmjozGCA04wggNK AgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3Mg MSBDbGllbnQgQ0ECECJrrb9nBol9MHok/UZg/AYwCQYFKw4DAhoFAKCCAZkwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODI2MTQzNjM5WjAjBgkqhkiG9w0BCQQx FgQUxLwucQ0YS8uR9ILkNX0hO0S4cicwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJ fTB6JP1GYPwGMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx IzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJfTB6JP1GYPwGMA0G CSqGSIb3DQEBAQUABIIBAA6u6CxTBxovrF2V+siqPM8rjBKcOesHJSJR2Gh7SiWtQRwzHu5yCs8+ WziMranrd1oYKBWj6fS/qMS4BJBMq7Fhzt3IJWaddjbK3JI8sZRZMCGwlX6tntYOkyTvyjTN++4l +swpDxhY+BthopXGJIKM/gDWi5P1nmm+h/yo6zc/JrVeA4vZ5Qy3CAMNvq+sS03VMW62MqLXfxan eHVPO5JpQe7G+GWott9G3JdLZoOE2KGXOlWQ2hOm4zhWY6A+SJ0WNCUr34q7yQUVakZI7VwbiVRb ekCbvR1ZwieH1oHlFlY1i+QSpioYbXsoJyETeNkBUxVpHG9VIl70VcYGy/4AAAAAAAA= --Apple-Mail=_FEE99771-1460-4CAE-B0DD-C432D6A57CD4-- From owner-freebsd-toolchain@freebsd.org Fri Aug 26 14:36:34 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B8AFB71AFF for ; Fri, 26 Aug 2016 14:36:34 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1587FB92; Fri, 26 Aug 2016 14:36:34 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x233.google.com with SMTP id g62so11816796ith.1; Fri, 26 Aug 2016 07:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CGZcrGJRR5JSAu/ByzihxoVrZMO5w9PZpMKSfFv+lis=; b=ulPrHiU2AqRT0tmIsjG5f7LjtrZ7sDXy4KwFqFvOmOcbOClDqKDp6aS8RGV8TTNINA OkfRUyoiy9sAJFRQ1JL7Vo08pSTEYumXtrHtZTf86ofFj8agXChDv/a2EMmlDx329jWR lngerO4U6DAbzYi7sq7k8gHB27XPnDrUkfXrv1SS5zU4+a0+dUWFAxQcxdrh+tXkX2q+ DklO8VXJHr+42x/qfBBY0qxJTQgbTgkNhVVHZykhuF+MiDiI/gVCHNkYWGwFk2A7kbdj PvYTaR3U1IOy2UrcFy+7sB6SUMrm11Tb4/bdn48p20eu5dRCPndNQFx7SQg6Axg6PvyO L75A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CGZcrGJRR5JSAu/ByzihxoVrZMO5w9PZpMKSfFv+lis=; b=N0c+DluF46Fi3NepA2fS6gEfoy9Q7uRJZ1hSH7ZoVeXmLYrjkMZbaO8hl8nN3C/d46 2oeabVq1TV/PvAW0B4b6hnW2O6CnDcM3U0OmcKkm8gx1dHSbwSUAUf51JKGYZD3pvsu/ 8p4Ue86eTk6/zEuWDtY979miTFnPwarjX6m0EMfOyBSovwAeTxU5iMxz5zg4SupbJK8p fDTCLmRnemoP/L445MElHJHqsOFyByzGWEoHRwsMxNipGSuagLUX2TebHh6Ds/z5G7rM ZSEj6MH/qufnVPj7yNqf2N6O6/+Sy0iw1M6nveODdEeL6QrDg3tkNfgEjqRN6JVVje8f iXVw== X-Gm-Message-State: AE9vXwON1T3iTbJRrNbNZLRHaMVVghDy0nBXrLXxaj4dLzgu79WCH8k/9Cpt3krE6XVu/3jk45YjzlR2mD6uQQ== X-Received: by 10.36.10.145 with SMTP id 139mr12697020itw.68.1472222193488; Fri, 26 Aug 2016 07:36:33 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.138.28 with HTTP; Fri, 26 Aug 2016 07:36:13 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Fri, 26 Aug 2016 10:36:13 -0400 X-Google-Sender-Auth: g21sPAwiz5msXUfD4V0xZno2v-w Message-ID: Subject: Re: Time to enable partial relro To: Warner Losh Cc: Pedro Giffuni , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 14:36:34 -0000 On 26 August 2016 at 10:18, Warner Losh wrote: > > So what's the summary of why we'd want to do that? What benefit does it bring? > Sure, other folks do it, but why? It's a relatively low cost technique to mitigate certain vulnerabilities. rtld needs to write to some sections during load but they don't need to be writeable after starting the program. relro reorders the output sections so that they are grouped together, and rtld remaps them read-only on start. This is often called "partial relro." I don't know of any real downside to enabling it, other than it could possibly break some strangely built third party software. It's been enabled on other platforms for quite some time though and I doubt we'd run into new issues. It doesn't bring a huge benefit by itself though; the PLT is still writeable. Adding "-z now" to the linker invocation produces "full relro" which makes the PLT read-only too. It has a negative impact on process start-up time though. From owner-freebsd-toolchain@freebsd.org Fri Aug 26 15:00:55 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B7E1B7017C for ; Fri, 26 Aug 2016 15:00:55 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 353FCC8C for ; Fri, 26 Aug 2016 15:00:54 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472223648; bh=LgHGcNcTeXP3OEZmgYWZ/gxSssiWY5+/65ucjQ6raIo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=KSdQTuFKvsir76cTNYZpzLatHcrTn8ZbO8aRiwrhmrSYWqj+CjZvn4JEkJxQ6B3VJum/1hgEydNQshdVTTuGInY53TDMYmQqerPauZwhc8MMBogoF2MuglITgBZNXUJ65zhXFNkR6BItbY84Tozw0oX1cajGgmAbBf2pgGZb74ACdNhgwz/iJggrVYIApPzYjqkXDzQKYujQU2J7fHRw5V5q70f4NQBc+kZoOGEtjwIUDLwWCCDkh+xv2McUCiGNxq6Yifd81RpgTiDSy+hc8cRVm4ETvFFwk4J79P8JTSsqKqutjqrzdVtrOo6rGCiX3y7UoCa369Fo6+gBibrLpQ== Received: from [66.196.81.172] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 15:00:48 -0000 Received: from [98.139.213.15] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 15:00:48 -0000 Received: from [127.0.0.1] by smtp115.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 15:00:48 -0000 X-Yahoo-Newman-Id: 29185.74208.bm@smtp115.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 7TcGJSIVM1mt_7ubyqS05vVl1vK4mMauMhyLtw_Kz8SRfni CaZSmglRJ7KHk.q4fufqLdENxNRLh28zaZEoLCcjGJhL_6qpGmBJg0fJzYMD 4LhtTnVbpUzdfllVPiDrznjYAmB5S64Onvsavo84MrrUFE3SEc_.mk.MvQBO MqbOEa5h_fOFaBQECK_EkBGK_aBdfCX8rMO.ilHu2VPLY2qIYLUjBLfOWnGo NI0E5z2_3hjipXYB5rYPIxGNBOmyVbXc0g1QbY706gg0ZbgtUT8PzaKhu5NA 3vEPr8sBfUucEsV0JxpEHCGUlItCcEGtokEqEwbzE70tUOq62MjnIJ2PR8B8 RR.ifq4prhfGN6if3Vz0JsMhNtgr9JhxQteEkwYxr7DT4yFI6TZIG1hTU6OO Eqibd1Cs0KpRpgc_Z2WguJqj44.ibPBsZiC_5G_js4_LyN1yqZsYO._IYcWq kRm_yeoobgjCIOCAde2hjh1vCT2ebwNxgGjYvvP2OEdVke2OMd4TVCHmiTdR uBFXT.hv7Zw1UtpInGEve5634OpiKrJjnN4lnTxgXuQb6OA-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: Time to enable partial relro To: Konstantin Belousov References: <20160826105618.GS83214@kib.kiev.ua> Cc: freebsd-toolchain@FreeBSD.org From: Pedro Giffuni Message-ID: Date: Fri, 26 Aug 2016 10:00:58 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160826105618.GS83214@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 15:00:55 -0000 On 08/26/16 05:56, Konstantin Belousov wrote: > On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: >> Hello; >> >> GNU RELRO support was committed in r230784 (2012-01-30) but we never >> enabled it by default. >> >> There was some discussion about it on >> https://reviews.freebsd.org/D3001 >> >> By now, all Linux distributions, NetBSD and DragonFly support it and >> it is the default for most systems in binutils 2.27. >> >> This doesn't affect performance, I ran it through an exp-run last >> year, no other OS has had issues etc ... seems safe and can be >> disabled if needed when linking. > Exp-run does not test anything interesting about relro. If all testing > that was done is basically just an exp-run, then there was no useful > runtime testing done. > The exp-run does cover Java and other VM-type thingies that bootstrap. For upstream binutils this is now the default (at least for linux, they never ask us if we want to follow). So the change has been tested extensively but perhaps not on cases that are relevant to us. Note that the "fix" for any port is ultimately trivial: LDFLAGS+= "-z norelro" >> >> I think it's time to enable it be default in our base binutils. If >> there are no objections, I will just commit the attached patch over >> the weekend. > > There are objections, the change must be runtime tested on large and > representative set of real-world applications before turning the knob. > You are not giving any hint on what would be a "representative set of real-world applications". Given that you committed the initial support your objection stands very high and is a blocker. :( As I see it committing it now would give ample time to test this in current before it hits any release. If you want more extensive testing merging it in -stable right after the 11-Release is guaranteed to help weed out any remaining update ports may need. Pedro. From owner-freebsd-toolchain@freebsd.org Fri Aug 26 15:01:22 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE3E9B701A7 for ; Fri, 26 Aug 2016 15:01:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 864AFDED for ; Fri, 26 Aug 2016 15:01:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id e63so336671656ith.1 for ; Fri, 26 Aug 2016 08:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rUKE3FABTHs2dSH69Yt7RPTinhLyjzhmRCG1Ck60ZMc=; b=JBNF3BR2XTz+Dyb1sAry+MI70tFWdwOVYhn0VBiiiDxW+6DUKpCv1kHj9fzSbAOQVR /5u/y09eKZv1fX3iNUATKKXwEKCy59Sio5BvKME7XBN2C6TIC4dMO0womeNd1N4iO5VJ R//Ix23mr0h6BlJw3ZtdbzD8KpZXMnhpX3KoIwhJgEwZxeyFoh6UzaDi5SF2PfMGClie mUdydDtcodk1YQ+aI4LXhIQIfOPJ/lJ6HNyslT+g4FUoDxQ3hHWAcS+UW3mtJ3JM78I1 VIT2wy9c8SHEFX4iGRS9PL3Aktl3EtB0yQLLgVmLPL3vyOkDGiqFOWRCc6Vvxv9JP7Z2 cocA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rUKE3FABTHs2dSH69Yt7RPTinhLyjzhmRCG1Ck60ZMc=; b=FXc1yn/xWH4Jf4JfHYkcc+MD4e6ajOjldhAcLtjSjbReWuZhChqn+RoPl6jaL3A3rW bKqgK8OM3JpILjrx7ob3yks8gu9+tzgp9IErUUk+rN9d5PupRpa3iz5zw4q/WwkwNKca ymnWBBEW5p2M+Fg2s4t/bXjkBmCDZXqbrJOatMkdlndscG6MbymgXMAwweqd6GrYzmoE 8aUuUx/VX67NQM/IgtH+RCCbLIV5Mtt0Hp4j0/NSieax9EeJFvql6dkbc26l/QAsnoxu VNBmMJ7lzaj6vaFKZZxRfAMtPcsofN59QUwvQrk7J9NTY/6ZXyfga2aGsb/yXQfDp6+T F1ww== X-Gm-Message-State: AEkoouu+AA5HWhMeEELw2vxBtZeSWz2yUMKE/01jWbW4X2L3DhWUylctTXyadf8VDe9G7JS8X2E53rWjAQt2ig== X-Received: by 10.36.116.193 with SMTP id o184mr12473692itc.14.1472223681829; Fri, 26 Aug 2016 08:01:21 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.7 with HTTP; Fri, 26 Aug 2016 08:01:21 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: From: Warner Losh Date: Fri, 26 Aug 2016 09:01:21 -0600 X-Google-Sender-Auth: XBe7cbTeX-52m2gKXdMoNIv36qA Message-ID: Subject: Re: Time to enable partial relro To: Ed Maste Cc: Pedro Giffuni , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 15:01:22 -0000 On Fri, Aug 26, 2016 at 8:36 AM, Ed Maste wrote: > On 26 August 2016 at 10:18, Warner Losh wrote: >> >> So what's the summary of why we'd want to do that? What benefit does it bring? >> Sure, other folks do it, but why? > > It's a relatively low cost technique to mitigate certain > vulnerabilities. rtld needs to write to some sections during load but > they don't need to be writeable after starting the program. relro > reorders the output sections so that they are grouped together, and > rtld remaps them read-only on start. This is often called "partial > relro." I don't know of any real downside to enabling it, other than > it could possibly break some strangely built third party software. > It's been enabled on other platforms for quite some time though and I > doubt we'd run into new issues. > > It doesn't bring a huge benefit by itself though; the PLT is still > writeable. Adding "-z now" to the linker invocation produces "full > relro" which makes the PLT read-only too. It has a negative impact on > process start-up time though. Sounds like this has implications for all the RTLD on all our architectures. Has this been tested across all of them? Warner From owner-freebsd-toolchain@freebsd.org Fri Aug 26 15:06:50 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FEC2B703F1 for ; Fri, 26 Aug 2016 15:06:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28E27163 for ; Fri, 26 Aug 2016 15:06:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x242.google.com with SMTP id f128so767162ith.2 for ; Fri, 26 Aug 2016 08:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DQ7TclWz81hlUTEKkfnanH+8mRA9sB0GmDDlKt6w0NA=; b=MNPLpLQL91rZBX1c8+mieL/N+lKgCF8Xft66vDt2kSSYtipQwnGXBFLaO1UOoPcwAg dZLr1FS9FsCEBOW26mbobLMWr6Fl2MOlne672XqsfmSi+Y0MHGY3QIinGwrJ65oHTS22 aN2/VRRV7gzRMSBDbhRRgGgQP8C9sO4zdcvU8/0WWGFV3w3oVoP1FhZgT9Z8MomYqvkR UiUzmx9yPIeIuJdt+KlMAxz3JEj/85cmCeckh0ht7YEfhEc8tYoT0VIHoK9jQufpSw7h WT5AnwXjym+AJWMrkn6+Pyx+FN420G7uaIsrbso+TlALtwV2Wc5+gKgp1jZJsLF7a5Zj 3GOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DQ7TclWz81hlUTEKkfnanH+8mRA9sB0GmDDlKt6w0NA=; b=XxEktxHp+Hreedg8+7rJJz5KdscXmbDXbN3J73FqAIFC07V8mfzZK7JKKSnMSgGoyX rr1QdK9bZnoGq8TSnQ2tBYWtFP7aqDHkQYLa7fs0xy3mIFR9VxcO/Fq50APJKePauYC7 bTSbkIdjj0VFkIM2y/jX2TjSxNuf1l0UWes+oWjyhRN91vHLL02qke7qhgmmcGfo9AVB BdihuH6l8+c3UXdsrJusX0JXM0xyXtIcx81S7D2ZHB+DAzWcPoZqlUTvJdDwW2NKLo/j bQmVz98qL5Vxx15Gy5z2TNckii4YoiPTcvPzNP78F9FH0mu4lbV3VfjD+lBMZAyfkd4W ZPGA== X-Gm-Message-State: AE9vXwNaTaE1G94lXZU5TlUv0z1oHDH0f4XK8SQsbC1Pp8DSi95+D/95M9xf3DTacv3dCuFoY5QsVfJ7BatcIA== X-Received: by 10.107.21.134 with SMTP id 128mr4465440iov.59.1472224009505; Fri, 26 Aug 2016 08:06:49 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.7 with HTTP; Fri, 26 Aug 2016 08:06:48 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <20160826105618.GS83214@kib.kiev.ua> From: Warner Losh Date: Fri, 26 Aug 2016 09:06:48 -0600 X-Google-Sender-Auth: cD1MRlvTfW4sy4zubMs2pLx6gLY Message-ID: Subject: Re: Time to enable partial relro To: Pedro Giffuni Cc: Konstantin Belousov , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 15:06:50 -0000 On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni wrote: > > > On 08/26/16 05:56, Konstantin Belousov wrote: >> >> On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: >>> >>> Hello; >>> >>> GNU RELRO support was committed in r230784 (2012-01-30) but we never >>> enabled it by default. >>> >>> There was some discussion about it on >>> https://reviews.freebsd.org/D3001 >>> >>> By now, all Linux distributions, NetBSD and DragonFly support it and >>> it is the default for most systems in binutils 2.27. >>> >>> This doesn't affect performance, I ran it through an exp-run last >>> year, no other OS has had issues etc ... seems safe and can be >>> disabled if needed when linking. >> >> Exp-run does not test anything interesting about relro. If all testing >> that was done is basically just an exp-run, then there was no useful >> runtime testing done. >> > > The exp-run does cover Java and other VM-type thingies that bootstrap. > For upstream binutils this is now the default (at least for linux, > they never ask us if we want to follow). So the change has been tested > extensively but perhaps not on cases that are relevant to us. > > Note that the "fix" for any port is ultimately trivial: > LDFLAGS+= "-z norelro" > >>> >>> I think it's time to enable it be default in our base binutils. If >>> there are no objections, I will just commit the attached patch over >>> the weekend. >> >> >> There are objections, the change must be runtime tested on large and >> representative set of real-world applications before turning the knob. >> > > You are not giving any hint on what would be a "representative set of > real-world applications". Given that you committed the initial support your > objection stands very high and is a blocker. :( > > As I see it committing it now would give ample time to test this in current > before it hits any release. If you want more extensive testing merging it in > -stable right after the 11-Release is guaranteed to help > weed out any remaining update ports may need. I'd say a minimum is 'buildworld' + a test boot on at least Intel (i386 and amd64), armv6 and mips (both 32-bit and 64-bit) before we proceed. How many of those have we done? Warner From owner-freebsd-toolchain@freebsd.org Fri Aug 26 15:08:02 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C768B70451 for ; Fri, 26 Aug 2016 15:08:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E7301E8 for ; Fri, 26 Aug 2016 15:08:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id x131so336547282ite.0 for ; Fri, 26 Aug 2016 08:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=g/FDtkN1cn6D6flW1x6VnvpDQqSbVkMqR/RO2pnvxhA=; b=mv/H7m+ipBzAMPU/Zr8hEOkvpFmNRIpF7eOa4fL09/zR6FMRQucoRcuObulgKB9xeb uiaSaTsdkN56FxjujnFmlalg2KCjwfDvTSzYEU4J6QdAV3PHmrnPRNY0tHcOE8cIZaWW PqYVNB1aR1I2YsPn5Kj+blW43tz0BNWB4/PX6ZELK5VpFUPcjcrtI/iCV1OLvALZRD9u amTitq6q2Dod4d8zwo8Zq/w0luvOjnrVe0avcgRCrTVNUBtnXb07C9ZeP6/GVTH/ZEqR J7fX2WmjIr7n1JtU2f43IAjON1EcLnUXDAWqJnpGd6XKdGJfmUEY/AzTIFZrM8+ZUf1K neFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=g/FDtkN1cn6D6flW1x6VnvpDQqSbVkMqR/RO2pnvxhA=; b=h1M+yTzSkKkMrFSAfAIKk5NQ6pywQsU6muIjOgtMQYOOxsuxhsVUDWSFHR7JbkPlvq SCR69VyZpYXqgAhPbKSMfgmryMbS1krOKFRMPoGbPh7TnSIFUYeH39Rb7Mx6JYvSj6eM 5W0OGfe0aQ/aJO9MAbj0kGuC65begHJ7iuf696Wt1DGXDTlPU8BWROcisxBbrGbEMIB/ VkGRbtsvgr3Nv0/7lfwpxf2VJAJ0/h9TNcg+bspBzePJrLJLQ73Ijgh/48zbSt/J9z9n MpNBP6iPyeh7aGRGMGj6gNKT0lmnsOtjnWyJcSudIV2M5+6Pmmw1EkdQBN03PaaxFJ/V ejsg== X-Gm-Message-State: AE9vXwNjnKh+2hVtKzdxgAIRepPDvXIOtp2Uf1rabFv2narz8sCIhs4rS0duv6FvNMJPhsLpyysiSyFfSGgQvw== X-Received: by 10.107.9.39 with SMTP id j39mr4588083ioi.73.1472224081603; Fri, 26 Aug 2016 08:08:01 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.7 with HTTP; Fri, 26 Aug 2016 08:08:01 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: <6af6f640-a00a-1359-d40f-c62b40eafb9c@FreeBSD.org> References: <6af6f640-a00a-1359-d40f-c62b40eafb9c@FreeBSD.org> From: Warner Losh Date: Fri, 26 Aug 2016 09:08:01 -0600 X-Google-Sender-Auth: rIMVC8aWwNnrWUYbbSFTseBJg0s Message-ID: Subject: Re: Time to enable partial relro To: Pedro Giffuni Cc: Ed Maste , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 15:08:02 -0000 On Fri, Aug 26, 2016 at 9:06 AM, Pedro Giffuni wrote: > > > On 08/26/16 10:01, Warner Losh wrote: >> >> On Fri, Aug 26, 2016 at 8:36 AM, Ed Maste wrote: >>> >>> On 26 August 2016 at 10:18, Warner Losh wrote: >>>> >>>> >>>> So what's the summary of why we'd want to do that? What benefit does it >>>> bring? >>>> Sure, other folks do it, but why? >>> >>> >>> It's a relatively low cost technique to mitigate certain >>> vulnerabilities. rtld needs to write to some sections during load but >>> they don't need to be writeable after starting the program. relro >>> reorders the output sections so that they are grouped together, and >>> rtld remaps them read-only on start. This is often called "partial >>> relro." I don't know of any real downside to enabling it, other than >>> it could possibly break some strangely built third party software. >>> It's been enabled on other platforms for quite some time though and I >>> doubt we'd run into new issues. >>> >>> It doesn't bring a huge benefit by itself though; the PLT is still >>> writeable. Adding "-z now" to the linker invocation produces "full >>> relro" which makes the PLT read-only too. It has a negative impact on >>> process start-up time though. >> >> >> Sounds like this has implications for all the RTLD on all our >> architectures. Has this been tested across all of them? >> > > It affects anything ELF yes, but AFAICT the change is platform independent. That's a different answer than 'it's been tested on all platforms and it's fine.' Warner From owner-freebsd-toolchain@freebsd.org Fri Aug 26 15:14:31 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D344AB70756 for ; Fri, 26 Aug 2016 15:14:31 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm43-vm10.bullet.mail.bf1.yahoo.com (nm43-vm10.bullet.mail.bf1.yahoo.com [216.109.114.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 99AB9A2A for ; Fri, 26 Aug 2016 15:14:31 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472224464; bh=4UuK7sbJmHmwK1B8T4XUOksad+igGCmqwCiMJ2dEUIc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=PGu9hkCA5nTrAAwgCITSnJp04bog1y+C4z3g83PuBHXHgYsbFbImewlsDw9pZqyMFx5nmWnuRDNGdpnU58Ccnyb/4194ZQCX+76OVXhKkC9IQemFroABQI2Zaw9+r39JA1r/xVqCw3JJZa8+Y1bTP5p5pkox/8mZ4Q58ETJwESIXZ8LxZ5/dBz45JuBs46nEYVGfyCFjQcQel378XPdnckW1r1Oug0yXizAWk+Z44zrlBrSY2HKeSd5Vsj7Mg/liXmIZgnBtitW32RDwePme61Uo5A6dLqHcXLjiQpOSMILgsx405WqxKjbsO5E9fbOpWayBf0TzNaayMBAfno1a2g== Received: from [98.139.215.140] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 15:14:24 -0000 Received: from [98.139.211.160] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 15:14:24 -0000 Received: from [127.0.0.1] by smtp217.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 15:14:24 -0000 X-Yahoo-Newman-Id: 246555.53956.bm@smtp217.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3RH4RKgVM1k8p6BZTnUVp21nTINb3oEaL0zThGxckLlgP7l cMiYivD4gNXtFwUCcZTkIPn7T7I2WGmvyf40c23PDXCeAlm4OsQ0kBXsZEwD 6exMoCI4sVyEU826nMHJkq8ZQp5KxhkjvPaYNSxXasn62fWETZ.mkzBbasKf YxC5PP0o_HTdtn2W6Kxh.nbhCMaeuq6skO4D1XsxxWVg4WeHNaL3c_3NLY_Y OB4pVZelLwJQ1vvP3mHA2o1CQjzDM0QI7WTN4kI4BS.XpREjAbHWthYYrC.G tVi4YBfy7qPm8SHhNX2hMA9oEQNIOwSDM6d.GRBFgnz_KeqA9wrm7ukai1hC D.9Ytfn.SlONHEybjDaf9KzUY4JrcbTZzoBUjR_aAVmZgtWOLYIYUTV.VO9w eP9vTp4PAfD0Qldl66pRwtM5q59q.nyTPfn5uWeNzaXi13p1TlvK9LQ3_tWu rB9X_AdRp7gZOZILR14hLPEHwrfXRqovZe6ej5btnnmF5msHYGsCGTL58MJQ OmppgibSh9yagEEo_xJ0nD4ddbxHw0eYH4HqPWDYqbELa2Q-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: Time to enable partial relro To: Warner Losh References: <20160826105618.GS83214@kib.kiev.ua> Cc: Konstantin Belousov , "freebsd-toolchain@FreeBSD.org" From: Pedro Giffuni Message-ID: Date: Fri, 26 Aug 2016 10:14:33 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 15:14:31 -0000 Hello; On 08/26/16 10:06, Warner Losh wrote: > On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni wrote: >> >> >> On 08/26/16 05:56, Konstantin Belousov wrote: >>> >>> On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: >>>> >>>> Hello; >>>> >>>> GNU RELRO support was committed in r230784 (2012-01-30) but we never >>>> enabled it by default. >>>> >>>> There was some discussion about it on >>>> https://reviews.freebsd.org/D3001 >>>> >>>> By now, all Linux distributions, NetBSD and DragonFly support it and >>>> it is the default for most systems in binutils 2.27. >>>> >>>> This doesn't affect performance, I ran it through an exp-run last >>>> year, no other OS has had issues etc ... seems safe and can be >>>> disabled if needed when linking. >>> >>> Exp-run does not test anything interesting about relro. If all testing >>> that was done is basically just an exp-run, then there was no useful >>> runtime testing done. >>> >> >> The exp-run does cover Java and other VM-type thingies that bootstrap. >> For upstream binutils this is now the default (at least for linux, >> they never ask us if we want to follow). So the change has been tested >> extensively but perhaps not on cases that are relevant to us. >> >> Note that the "fix" for any port is ultimately trivial: >> LDFLAGS+= "-z norelro" >> >>>> >>>> I think it's time to enable it be default in our base binutils. If >>>> there are no objections, I will just commit the attached patch over >>>> the weekend. >>> >>> >>> There are objections, the change must be runtime tested on large and >>> representative set of real-world applications before turning the knob. >>> >> >> You are not giving any hint on what would be a "representative set of >> real-world applications". Given that you committed the initial support your >> objection stands very high and is a blocker. :( >> >> As I see it committing it now would give ample time to test this in current >> before it hits any release. If you want more extensive testing merging it in >> -stable right after the 11-Release is guaranteed to help >> weed out any remaining update ports may need. > > I'd say a minimum is 'buildworld' + a test boot on at least Intel (i386 and > amd64), armv6 and mips (both 32-bit and 64-bit) before we proceed. How > many of those have we done? > I have been running it my desktop (amd64) for a year now. I can test i386 in a VM but I doubt it will affect anything. The issue, and it's probably kib's worry are some rarely used but important ports. Stuff like erlang, or virtualbox maybe, but as I wrote, the fix (if needed) is trivial by adding a flag to the link command. FWIW, but it is largely irrelevant to us, RELRO is the default on OpenBSD and there is no way out of it there. Pedro. From owner-freebsd-toolchain@freebsd.org Fri Aug 26 15:20:27 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB247B708EA for ; Fri, 26 Aug 2016 15:20:27 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 916B5B8D for ; Fri, 26 Aug 2016 15:20:27 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472224820; bh=/FXIB4mkdHUltcHuNAtyiKoRd1qcW4oW6OTI2cYJsqQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=VPOqeH/ATqkmKLjFh20cgU1AP7l+exrLd63mA4lEBnlX5MQAe/cXN4YNSlZRm0VyHzxIvwCGoErZc0PzrEWt5vyxfK88m0w/nUMfvLev3VGczPXdTWpkSsUPbfRvefyS4WV37DV3y/u53mGfVEGIaUT7ZayMYRFdd8pP/5RLAq2jjuSJI1C2rpQpA+1TmwmnikqwTXtNJKnoFwjO0/kxlkt7xqiyFHoCocgBX1P315YYwP1FM2bAzuOGcXRPvDGT04HC9r1tKnbZJWbW0On3/HMdFJHh3sZYEkPpsyKawzdfaKPPaTDFOjD6ZfNl1o5IjExjdbZpaQzke7vSlp6akQ== Received: from [98.139.170.182] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 15:20:20 -0000 Received: from [68.142.230.65] by tm25.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 15:20:20 -0000 Received: from [127.0.0.1] by smtp222.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 15:20:20 -0000 X-Yahoo-Newman-Id: 116459.41620.bm@smtp222.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: u4hGY20VM1mX23mVjw4V_IGgoujSp_F3PMRkAeD3Jh_u.zw EpsDtWDaBUb1bcQAzE6N6oIa2Tsy7V2786wvBCDrFDCJw4HF8ersvhHr7tf6 LtZQhq8F0pl5kiPT4RJ_8Fq7MkzDSrP9e8qCW.ch.liSn41kNJWJzI7byWOD fOD.TrtgQPH.s9ZQPZfUnnSRRhac_UtjQvzVxW0zQmbpQt53a2lDI.lbFU4Z Amj4Cs7tZmT5VcWxNfkLuIW5B54SvGVBo.LUnTkTMdTiS5IbauCvYD8JsQR2 KgRLsduqRPtpcl1OZmxmv.fb13FCJay0.Wit178uK97zcuK3RWeQ48qHIXiM 8kKGLS5ZscreQxKQ93JCZ3H0E836sW_vw36n6G8NgexPKc9.kTOl0BdAXzlp T5ExSDMx8mlcMQWJwIFdZWNS4AwvdgcW9XBajaRGyltZ.H4t33oTpnZyMmIj OKBnxWaCqFxLj1MY9ZnZ5F2liXq56Kb9h0I7bYXqENRjnEa3GR31MaMW0fmA 75y2dr1l3F8jyyU_G1el.fWb5PbhgKUOqOMeXXQOU0CXqkQ-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: Time to enable partial relro To: Warner Losh References: <6af6f640-a00a-1359-d40f-c62b40eafb9c@FreeBSD.org> Cc: Ed Maste , "freebsd-toolchain@FreeBSD.org" From: Pedro Giffuni Message-ID: <3995b10f-f9dc-ff85-9575-5e421884816c@FreeBSD.org> Date: Fri, 26 Aug 2016 10:20:29 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 15:20:28 -0000 On 08/26/16 10:08, Warner Losh wrote: > On Fri, Aug 26, 2016 at 9:06 AM, Pedro Giffuni wrote: >> >> >> On 08/26/16 10:01, Warner Losh wrote: >>> >>> On Fri, Aug 26, 2016 at 8:36 AM, Ed Maste wrote: >>>> >>>> On 26 August 2016 at 10:18, Warner Losh wrote: >>>>> >>>>> >>>>> So what's the summary of why we'd want to do that? What benefit does it >>>>> bring? >>>>> Sure, other folks do it, but why? >>>> >>>> >>>> It's a relatively low cost technique to mitigate certain >>>> vulnerabilities. rtld needs to write to some sections during load but >>>> they don't need to be writeable after starting the program. relro >>>> reorders the output sections so that they are grouped together, and >>>> rtld remaps them read-only on start. This is often called "partial >>>> relro." I don't know of any real downside to enabling it, other than >>>> it could possibly break some strangely built third party software. >>>> It's been enabled on other platforms for quite some time though and I >>>> doubt we'd run into new issues. >>>> >>>> It doesn't bring a huge benefit by itself though; the PLT is still >>>> writeable. Adding "-z now" to the linker invocation produces "full >>>> relro" which makes the PLT read-only too. It has a negative impact on >>>> process start-up time though. >>> >>> >>> Sounds like this has implications for all the RTLD on all our >>> architectures. Has this been tested across all of them? >>> >> >> It affects anything ELF yes, but AFAICT the change is platform independent. > > That's a different answer than 'it's been tested on all platforms and > it's fine.' > It's the best answer I have. I will test running buildworld on i386. If you can kindly test on other platforms, it would be very welcome. In any case I will not commit anything unless there is complete consensus, which is why I asked in this list in the first place :). Pedro. From owner-freebsd-toolchain@freebsd.org Fri Aug 26 16:00:16 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70405B7430D for ; Fri, 26 Aug 2016 16:00:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 186B02D7; Fri, 26 Aug 2016 16:00:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u7QG0AIi033600 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 26 Aug 2016 19:00:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7QG0AIi033600 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7QG0AUT033596; Fri, 26 Aug 2016 19:00:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 26 Aug 2016 19:00:09 +0300 From: Konstantin Belousov To: Pedro Giffuni Cc: freebsd-toolchain@FreeBSD.org Subject: Re: Time to enable partial relro Message-ID: <20160826160009.GU83214@kib.kiev.ua> References: <20160826105618.GS83214@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 16:00:16 -0000 On Fri, Aug 26, 2016 at 10:00:58AM -0500, Pedro Giffuni wrote: > > > On 08/26/16 05:56, Konstantin Belousov wrote: > > On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: > >> Hello; > >> > >> GNU RELRO support was committed in r230784 (2012-01-30) but we never > >> enabled it by default. > >> > >> There was some discussion about it on > >> https://reviews.freebsd.org/D3001 > >> > >> By now, all Linux distributions, NetBSD and DragonFly support it and > >> it is the default for most systems in binutils 2.27. > >> > >> This doesn't affect performance, I ran it through an exp-run last > >> year, no other OS has had issues etc ... seems safe and can be > >> disabled if needed when linking. > > Exp-run does not test anything interesting about relro. If all testing > > that was done is basically just an exp-run, then there was no useful > > runtime testing done. > > > > The exp-run does cover Java and other VM-type thingies that bootstrap. > For upstream binutils this is now the default (at least for linux, > they never ask us if we want to follow). So the change has been tested > extensively but perhaps not on cases that are relevant to us. > > Note that the "fix" for any port is ultimately trivial: > LDFLAGS+= "-z norelro" > > >> > >> I think it's time to enable it be default in our base binutils. If > >> there are no objections, I will just commit the attached patch over > >> the weekend. > > > > There are objections, the change must be runtime tested on large and > > representative set of real-world applications before turning the knob. > > > > You are not giving any hint on what would be a "representative set of > real-world applications". Given that you committed the initial support > your objection stands very high and is a blocker. :( Well, I indeed do not think that 'works on my desktop' is good enough testing for this change. I understand that it is impossible to test all ports at runtime, or even a significant percentage of them, not to mention programs which sit on the user's storage. What actually worries me in the fate of such changes is that submitter never starts monitoring user complains and see whether the change causes some delayed random breakage. It just ends up in the 'BSD is broken' basket with one more supportive case. > > As I see it committing it now would give ample time to test this in > current before it hits any release. If you want more extensive testing > merging it in -stable right after the 11-Release is guaranteed to help > weed out any remaining update ports may need. It is useless 'testing' when the cause of breakage is not actively looked for and identified. You commit it now, five months later some unlucky user reports that his application coredumps. What next ? From owner-freebsd-toolchain@freebsd.org Fri Aug 26 16:43:05 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 321CBB74F71 for ; Fri, 26 Aug 2016 16:43:05 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE1E1EE3 for ; Fri, 26 Aug 2016 16:43:04 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472229783; bh=9ZVW2WmW6QvaQI79JpEL/4z+oUUJEOo0lguNmhDkV1Y=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=kMPZ4QOqr5j9LY1QQvXNeu/7BFpVlAhoMbFZ8zH8X1AVv3Q7rUiYSioc6N/pVwlH+7wGdd2toHX6K+mJ0sLD8LMkHptIxZhHGXrIytzyFP4xttnLg4L/GMdE3iJcD6pBG0MpRuNys4+LyMRssa0tTJ05STZ2TgViCHQkfTTlrzAJYzthyeDvum7XSjzgBujXhXbD0S+2QtkZhAUVhNhqt4Fy8wO8B2k9BhB3DtZK+t+Hmzh5HjiY9wmBUBGsk+pcX3VjSZD8VZ3I6bF/TEZUSTP6jKBt8n1IYS+RVwNcl4LTNZEeiHb03ECs9yRV1SAlGUy+dgg8JDVdI1IRIOfOsA== Received: from [98.139.215.140] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 16:43:03 -0000 Received: from [98.139.211.203] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 16:43:03 -0000 Received: from [127.0.0.1] by smtp212.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 16:43:03 -0000 X-Yahoo-Newman-Id: 575161.60388.bm@smtp212.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: b2si3lYVM1kj4rRFCgCr3llxsfhjsspeOCkGhKbCyiqB.dM PoE52V0z1KeyfJQhUQdxxOYyf8dVjoSVuE5jf67iG0bibLk4t0ttRpM9ca0d DcHMSBKUPlUrPo09.MRRhPTUuOzdUAIEAoPc3wC6onzY0c5A9ne8BSqB6zUT oL0aW8lD6ouScypIoAlDiFlw6hc6NIzZKOXFH4f7DntOXekzcTGa1OcWB9I9 iNTjGG.EnPGRM5oO0yw5aGcXK7Kn9BMR6BNgoo16jknzPPHJU88yXiNDRGlO sMmIZA4leJWjWri24FL1brOfuqS9PBu6s44vyAgnyqkm4mXtvkgXuUnM4DE3 lQMYEl3zttFOVqYgnOqDw0kCIQG.rWFJzM97WAdvN2UQLm_Yvw9YA22tglwz gkpwI_9TB1pkvpdFRcC2ZUl2dgZaUzunEkZkiQmHk28a3wMjUyExOrokPd2P j_HVsiT7vx2iOxrsIDRlxsFuF3Dd5kD8vcRtHQ5YHI1zCiofE.cSJ0PDTWXv rpjS2acqJTyIEHD0ZbuTBL.B30eRHlHyXENfLCdtZu2d7kg-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: Time to enable partial relro To: Konstantin Belousov References: <20160826105618.GS83214@kib.kiev.ua> <20160826160009.GU83214@kib.kiev.ua> Cc: freebsd-toolchain@FreeBSD.org From: Pedro Giffuni Message-ID: Date: Fri, 26 Aug 2016 11:43:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160826160009.GU83214@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 16:43:05 -0000 Hello; On 26/08/2016 11:00, Konstantin Belousov wrote: > On Fri, Aug 26, 2016 at 10:00:58AM -0500, Pedro Giffuni wrote: >> >> On 08/26/16 05:56, Konstantin Belousov wrote: >>> On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: >>>> Hello; >>>> >>>> GNU RELRO support was committed in r230784 (2012-01-30) but we never >>>> enabled it by default. >>>> >>>> There was some discussion about it on >>>> https://reviews.freebsd.org/D3001 >>>> >>>> By now, all Linux distributions, NetBSD and DragonFly support it and >>>> it is the default for most systems in binutils 2.27. >>>> >>>> This doesn't affect performance, I ran it through an exp-run last >>>> year, no other OS has had issues etc ... seems safe and can be >>>> disabled if needed when linking. >>> Exp-run does not test anything interesting about relro. If all testing >>> that was done is basically just an exp-run, then there was no useful >>> runtime testing done. >>> >> The exp-run does cover Java and other VM-type thingies that bootstrap. >> For upstream binutils this is now the default (at least for linux, >> they never ask us if we want to follow). So the change has been tested >> extensively but perhaps not on cases that are relevant to us. >> >> Note that the "fix" for any port is ultimately trivial: >> LDFLAGS+= "-z norelro" >> >>>> I think it's time to enable it be default in our base binutils. If >>>> there are no objections, I will just commit the attached patch over >>>> the weekend. >>> There are objections, the change must be runtime tested on large and >>> representative set of real-world applications before turning the knob. >>> >> You are not giving any hint on what would be a "representative set of >> real-world applications". Given that you committed the initial support >> your objection stands very high and is a blocker. :( > Well, I indeed do not think that 'works on my desktop' is good enough > testing for this change. I understand that it is impossible to test > all ports at runtime, or even a significant percentage of them, not to > mention programs which sit on the user's storage. > > What actually worries me in the fate of such changes is that submitter > never starts monitoring user complains and see whether the change causes > some delayed random breakage. It just ends up in the 'BSD is broken' > basket with one more supportive case. The change is now in linux too, so they will be saying "BSD and Linux are broken". ;) I understand the concern, and admittedly there's no way to catch all issues, but that's why we have -current and -stable, so we can isolate all of those cases before the users in a release get hit by it. I see this change pretty much in the lines of the "stack-protector-strong" change: FreeBSD 11 will be the first release to include the change (only in base). I recall there was one overflow in the FAT filesystem which was caught by the change and by now I hope/wish we have figured out any issue. Had we committed the change earlier it might have received more testing. There is no perfect time to make such changes but it's better to try to keep in line with the changes upstream (binutils in this case) than to stay still while the rest of the world moves on. >> As I see it committing it now would give ample time to test this in >> current before it hits any release. If you want more extensive testing >> merging it in -stable right after the 11-Release is guaranteed to help >> weed out any remaining update ports may need. > It is useless 'testing' when the cause of breakage is not actively > looked for and identified. You commit it now, five months later some > unlucky user reports that his application coredumps. What next ? Unlucky user must be running -current to be affected: if we don't MFC the change it will take more than one year until it hits end users in a release. If the breakage is in base, we want to know as early as we can, if the breakage is in third party ports, they will benefit from upstream getting the BSD and linux breakage reports. BTW, I wonder how lld handles RELRO, is it supported or even the default? Pedro. From owner-freebsd-toolchain@freebsd.org Fri Aug 26 16:48:33 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07929B7502C for ; Fri, 26 Aug 2016 16:48:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6521B7 for ; Fri, 26 Aug 2016 16:48:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-pa0-x230.google.com with SMTP id fi15so28802802pac.1 for ; Fri, 26 Aug 2016 09:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=GbBvh0CS8fNW05MHv8yh2h5UnW3ejT9DSkH0L1xSfvs=; b=LSBqnUi0vb6EMPkOvQQ1lvt1Pb3iBv5/APJj1GyudyCI7Lz3PSQqeOjoQIOC0JfX24 aKNZdBumGE2UIeZOU+Rj9NqMWuyvBcWhJj8C8kg4cpnc/bc3eZ2UJK211y0O7XVpfyS3 ScSAeeqfCQQBEgqgVcg1KRAMoXt9lwQnqp9Xh4SvB8iUCRwJPyQL/lds45ty2AwAKlAk EgeKREZMXE4ddYKPCFzInzZ9L/ntR3D/lgp/KeT/gdZ2+nsJGADlW5DsQC0Z4J2pLUFx lQUBe1SIsDSynnBVxc8pMdSB8AJqxla8BUiDDu/4gIHcmMO7SSlLyY3EmXeS1oT9lCyT 60lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=GbBvh0CS8fNW05MHv8yh2h5UnW3ejT9DSkH0L1xSfvs=; b=Zw9FDYKZpcA46cAi1+xCqtsJOXqNQFqotiXnso+/OO7w1XjPN7iIaCtGS/+Jlqbzb1 njCcoV2lBS1E5QRRgI4oAY+natX90rn1DqmZsILYM+C27679hYD+6c7VBvNHzMBouzrY u6iVnFY6SWKXRW4IWT/KjnJUfK/zazuSv6BC+S3EqetwAdZUdI5gfIHuLcpWwcyuj1qZ D/BAfx34yVQtRGarBCccPiPLc+SJgQSrqLhBi6Rt9zRR1GjI4a4sVqK7FP1rkvto+VbI Q2Y0awfplvKVGE+YLUYB6K8ECkKFC+Hl/OCk66OcHSsETDZbohXyI3ZIiiFl4MWthxa1 Wzwg== X-Gm-Message-State: AE9vXwN3RunpgRV2gSR1psgShIErxZ+KE97EEK04Y+brI1+9iBkwjp2kA66DgTTfoJyvgw== X-Received: by 10.66.169.68 with SMTP id ac4mr7706450pac.85.1472230112280; Fri, 26 Aug 2016 09:48:32 -0700 (PDT) Received: from autobvt-1p7qt1t.corp.netflix.com ([69.53.245.200]) by smtp.gmail.com with ESMTPSA id tr1sm30052934pab.19.2016.08.26.09.48.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Aug 2016 09:48:30 -0700 (PDT) Subject: Re: Time to enable partial relro Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7348908C-1D39-41E3-AA39-FA85F423750A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Warner Losh In-Reply-To: Date: Fri, 26 Aug 2016 10:48:29 -0600 Cc: Warner Losh , Konstantin Belousov , "freebsd-toolchain@FreeBSD.org" Message-Id: References: <20160826105618.GS83214@kib.kiev.ua> To: Pedro Giffuni X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 16:48:33 -0000 --Apple-Mail=_7348908C-1D39-41E3-AA39-FA85F423750A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 26, 2016, at 9:14 AM, Pedro Giffuni wrote: >=20 > Hello; >=20 > On 08/26/16 10:06, Warner Losh wrote: >> On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni = wrote: >>>=20 >>>=20 >>> On 08/26/16 05:56, Konstantin Belousov wrote: >>>>=20 >>>> On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: >>>>>=20 >>>>> Hello; >>>>>=20 >>>>> GNU RELRO support was committed in r230784 (2012-01-30) but we = never >>>>> enabled it by default. >>>>>=20 >>>>> There was some discussion about it on >>>>> https://reviews.freebsd.org/D3001 >>>>>=20 >>>>> By now, all Linux distributions, NetBSD and DragonFly support it = and >>>>> it is the default for most systems in binutils 2.27. >>>>>=20 >>>>> This doesn't affect performance, I ran it through an exp-run last >>>>> year, no other OS has had issues etc ... seems safe and can be >>>>> disabled if needed when linking. >>>>=20 >>>> Exp-run does not test anything interesting about relro. If all = testing >>>> that was done is basically just an exp-run, then there was no = useful >>>> runtime testing done. >>>>=20 >>>=20 >>> The exp-run does cover Java and other VM-type thingies that = bootstrap. >>> For upstream binutils this is now the default (at least for linux, >>> they never ask us if we want to follow). So the change has been = tested >>> extensively but perhaps not on cases that are relevant to us. >>>=20 >>> Note that the "fix" for any port is ultimately trivial: >>> LDFLAGS+=3D "-z norelro" >>>=20 >>>>>=20 >>>>> I think it's time to enable it be default in our base binutils. If >>>>> there are no objections, I will just commit the attached patch = over >>>>> the weekend. >>>>=20 >>>>=20 >>>> There are objections, the change must be runtime tested on large = and >>>> representative set of real-world applications before turning the = knob. >>>>=20 >>>=20 >>> You are not giving any hint on what would be a "representative set = of >>> real-world applications". Given that you committed the initial = support your >>> objection stands very high and is a blocker. :( >>>=20 >>> As I see it committing it now would give ample time to test this in = current >>> before it hits any release. If you want more extensive testing = merging it in >>> -stable right after the 11-Release is guaranteed to help >>> weed out any remaining update ports may need. >>=20 >> I'd say a minimum is 'buildworld' + a test boot on at least Intel = (i386 and >> amd64), armv6 and mips (both 32-bit and 64-bit) before we proceed. = How >> many of those have we done? >>=20 >=20 > I have been running it my desktop (amd64) for a year now. I can test = i386 in a VM but I doubt it will affect anything. The issue, and it's = probably kib's worry are some rarely used but important ports. Stuff = like erlang, or virtualbox maybe, but as I wrote, the fix (if needed) > is trivial by adding a flag to the link command. >=20 > FWIW, but it is largely irrelevant to us, RELRO is the default on > OpenBSD and there is no way out of it there. What I=E2=80=99m worried about is that our run time linker may get the = RELRO stuff wrong and that=E2=80=99s a very platform specific thing and = needs to be validated. I also share Kib=E2=80=99s worry about different = ports being broken, but that=E2=80=99s a different issue. Recent = compilers have broken our run time linker on mips, for example, because = they generate new / different relocations than those before. It=E2=80=99s = easy enough to test to make sure that we=E2=80=99re good on at least the = fairly active platforms (i386, amd64, armv6, mips and mips64) to make = sure that nothing bad happens. The others can be tested in due time = (though the powerpc ones likely can be tested easily enough by the = powerpc guys since they are quite active). I get very nervous when I see =E2=80=9Cshould work=E2=80=9D or =E2=80=9Csh= ould be platform independent=E2=80=9D for such a low-level thing. Warner --Apple-Mail=_7348908C-1D39-41E3-AA39-FA85F423750A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXwHLdAAoJEGwc0Sh9sBEARkQP/jN4/Y0azhX4ASQW5PU97z+u ee5nWbUqVlJCRzpeTl33sHBuBmAbq/nrkcOyDtsMz9jWkvl0/Ei7/6FpkYyYJk8b Ret06oB/2Ia7KO2Hajj/4yS5g13tRm4tHnzZZi+1KMsEBI/VNIeJRWgPN1o/4cre yByqpAZzgaf8X5C4SHydAzruVlmZLaJ+AJ53mWNoBj45xRw96yUDxx4MQ5KSntkZ SDbXUCno9OyPq4PblnO7Ai8PIAhgPdPU0Z/p3mV2QguCoz20POa2Y7x1Y/xZoIO8 fp1iHXgdAJVyS4LgrosdpE7hb1Qpzu6HWa+vXVKDGzRA8+ocn35IYLKQ3a1B2vci O1vLGRfEbB7KtgqWfoJcvGhLggphxBo3N/z2qlldYbSu24Z8maiD1hU6SiKuZVbL 3DwRrIlxhr7Bhf0kqoZFTNvNUyQWdx8uvynXgrEOa/95m16VWfYsT4RYeKFrrwLp KhngSl13k4UFv8s84Qs6nn6msX6+YQ2RPporrFTAMyqJ7QjV5SslXdn7U7uYXelm 0oAd8EB3ZK6QifqMuJbqTPgVS2ZHEqsQL+0LlTV410oAT8JeH7Xe8TiSW+1/ppkU PskA9qfKgD+Oi7pJAWFBoSLZ0notSVhxuZ6igYaAd5nx3zVbWDgvquU08xrGR5W2 9VABo2uEEsMlhW6oswem =9UzM -----END PGP SIGNATURE----- --Apple-Mail=_7348908C-1D39-41E3-AA39-FA85F423750A-- From owner-freebsd-toolchain@freebsd.org Fri Aug 26 16:50:58 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71897B7506B for ; Fri, 26 Aug 2016 16:50:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BD7A14A for ; Fri, 26 Aug 2016 16:50:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-pa0-x22b.google.com with SMTP id hb8so28880780pac.2 for ; Fri, 26 Aug 2016 09:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=rWZVvKVbJJ5N26M0vzJScBQxhEVYc0gqLhM/XQKYXMQ=; b=fXyGdC/mJyjRRy5RQpPNjQ8Ph0qGLUmWyrQkfzO+I0FL5UaVDtorUOhQV76PGtpAnm OAOCCT4UvexQkykr0Z6IhwAChlh4hGbBUqVuZJ5DPaxQQsgUEg6zwfJqQdsBoXiKLLzH KJvcW+qf6TKuFKZGVIRnah5coFDpOCB8k8QClv35jAZj7u/XzVCKDl6TovnDH3Nqxmrj OceQCTlw1WIPdQjp0fZITiEMnKBU4w6dVmIPcEjNnnzJ6/o7wWrFi6b3SgRZ42dVTGWI w190PrGTF9TNqe3o+ejg/+bh0xAxpmS3LPwdZ/xzEr+wMgt9XfluhUtLVcQr/OFWW8+g dktw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=rWZVvKVbJJ5N26M0vzJScBQxhEVYc0gqLhM/XQKYXMQ=; b=PucS3BxM8guPWnJ4JtCKEw2lHcB+92NnKS9S4sTqYRdKCCxiFiRUE7A2ynxoAHDP1Y Jn1Ffb0ULXXKhkqlAXf3ejxLuf3XA1n2h0zsPsA7db+DXQEHOodcOR/obc3eaa6DHCYP qDaDQIc6Em3VrwwGJtuGUeN8SIkp11+ku6qQl1FVSJCrmEpujmHOx4NWihBDME6ACDwF GezwWmXY3lTAwN39n+bRKhiNAtdXUKmokBfjrjax9VBaKJmtUAlIUXMQxrhIOfXKRZ7i +VMOvdRE1G79WLHwg3WodjlKvtydqE9UfLSC4JaXPPFuNgIA1lZg7PbGpg1um20l/KY/ 4H4g== X-Gm-Message-State: AE9vXwNgMVhZEYddwDXsIugBl5+7mqlOwR9ljdJ3KurIRQ4EWwkSAYWPBEQmyMYnQ5rRLA== X-Received: by 10.66.87.6 with SMTP id t6mr7588114paz.141.1472230257652; Fri, 26 Aug 2016 09:50:57 -0700 (PDT) Received: from autobvt-1p7qt1t.corp.netflix.com ([69.53.245.200]) by smtp.gmail.com with ESMTPSA id n13sm30030484pfj.16.2016.08.26.09.50.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Aug 2016 09:50:56 -0700 (PDT) Subject: Re: Time to enable partial relro Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C877F52B-651B-49E8-9D70-802518B443E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Warner Losh In-Reply-To: <3995b10f-f9dc-ff85-9575-5e421884816c@FreeBSD.org> Date: Fri, 26 Aug 2016 10:50:55 -0600 Cc: Warner Losh , Ed Maste , "freebsd-toolchain@FreeBSD.org" Message-Id: <486AA283-9E0B-4566-92B7-56919FA2BECF@bsdimp.com> References: <6af6f640-a00a-1359-d40f-c62b40eafb9c@FreeBSD.org> <3995b10f-f9dc-ff85-9575-5e421884816c@FreeBSD.org> To: Pedro Giffuni X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 16:50:58 -0000 --Apple-Mail=_C877F52B-651B-49E8-9D70-802518B443E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 26, 2016, at 9:20 AM, Pedro Giffuni wrote: >=20 >=20 >=20 > On 08/26/16 10:08, Warner Losh wrote: >> On Fri, Aug 26, 2016 at 9:06 AM, Pedro Giffuni = wrote: >>>=20 >>>=20 >>> On 08/26/16 10:01, Warner Losh wrote: >>>>=20 >>>> On Fri, Aug 26, 2016 at 8:36 AM, Ed Maste = wrote: >>>>>=20 >>>>> On 26 August 2016 at 10:18, Warner Losh wrote: >>>>>>=20 >>>>>>=20 >>>>>> So what's the summary of why we'd want to do that? What benefit = does it >>>>>> bring? >>>>>> Sure, other folks do it, but why? >>>>>=20 >>>>>=20 >>>>> It's a relatively low cost technique to mitigate certain >>>>> vulnerabilities. rtld needs to write to some sections during load = but >>>>> they don't need to be writeable after starting the program. relro >>>>> reorders the output sections so that they are grouped together, = and >>>>> rtld remaps them read-only on start. This is often called "partial >>>>> relro." I don't know of any real downside to enabling it, other = than >>>>> it could possibly break some strangely built third party software. >>>>> It's been enabled on other platforms for quite some time though = and I >>>>> doubt we'd run into new issues. >>>>>=20 >>>>> It doesn't bring a huge benefit by itself though; the PLT is still >>>>> writeable. Adding "-z now" to the linker invocation produces "full >>>>> relro" which makes the PLT read-only too. It has a negative impact = on >>>>> process start-up time though. >>>>=20 >>>>=20 >>>> Sounds like this has implications for all the RTLD on all our >>>> architectures. Has this been tested across all of them? >>>>=20 >>>=20 >>> It affects anything ELF yes, but AFAICT the change is platform = independent. >>=20 >> That's a different answer than 'it's been tested on all platforms and >> it's fine.' >>=20 >=20 > It's the best answer I have. I=E2=80=99d politely suggest that we solicit help to get a better = answer. > I will test running buildworld on i386. If you can kindly test on = other platforms, it would be very welcome. I might be able to do armv6, but I have no time to do mips. The mailing = lists for them might get results faster since I=E2=80=99m kinda swamped. = And since the powerpc guys are around and active, it wouldn=E2=80=99t = hurt to send it there too. > In any case I will not commit anything unless there is complete > consensus, which is why I asked in this list in the first place :). Yea. This should be easy enough to test to make sure there=E2=80=99s no = weird gotchas. Warner --Apple-Mail=_C877F52B-651B-49E8-9D70-802518B443E9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXwHNvAAoJEGwc0Sh9sBEAqBcP/2HRcY5tTsor7VdVE8r54Cns thkTIRzcEDTHIp3SLV0kJE6IqIKD5zNG1hbRK44Wk4/hINkquzx2Olq4/fKHKGAV 7RAxN950FQ0kZVlHhg5bQc6tZsZe/KOFRAl672FBpUNvYH5DgI0lHEsnAyJ25M7J OjvVkCRLhR2G4yceHQ8g0OhZ/+sJVHYvMunpiVNMrevc9319TDr3U8OClMp5DOnH t9AYcSHeH1rsL0ETitMDRw495hzrSfCfMPSO1TGNInZOB47TuHoDn8yjvzAgVsmc E9x53Ky0lMhH+WYVw94wf6w29Tzmna/bE/ahM4/9q4JB8kCKCJMg+xaAlzhC0zON uD30+vadhSBsP7hNfEY/gBpmcbLNqm1sn7DBfXCwC7Q+9IYIb3JBlKjacxXCKlmC hIOx6rzFdqdXaPxuelHczULYZftGy64NfdG/HFHyKJcCVct8Lds36TZHgu3ZGnzf Iz7/E7Rc8oY2f6MoXcLjx2VPArZYt1tEkMZwB71PMeA3guLdjDIVOfT1lZQPrZ0j Q3oyF6rD/HDfzitFEapaUbiNS9H5DeZnySsJfVHSBpGgaq2D9DrdLuyI76fcfWFZ c1bfE/DdVTqZDk8F3kjqbQX5coKEkve1PnQbuo8EwioAZCuw91/4rZQw2KWhgCpg Nf/JXn/5OMj2y9bpoIxE =Ih1T -----END PGP SIGNATURE----- --Apple-Mail=_C877F52B-651B-49E8-9D70-802518B443E9-- From owner-freebsd-toolchain@freebsd.org Fri Aug 26 18:25:51 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5877A94553 for ; Fri, 26 Aug 2016 18:25:51 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7706D25A3 for ; Fri, 26 Aug 2016 18:25:51 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472235949; bh=5J65kUsYjlGJ72NNLwcJWfjYHq0axR1sdpNiMqo0XK4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=oYjmBi9fFJxrRpF6uOX+frtFOTV8PLbnYq3jbpW+3rzEq1GRaJGppP/9pBJxBHhhBCOgMXHmiUw9wHb+lcy2suPEt/MZiuL2S14diOq983ivzF5tiQ2Saz8+zR3I277qjXrl/5VWj3ii/iAv9V+6bDJrXvBEXILsZiVtGHxPfCXQ3+mH8s4b2DlQjS4WFljqUlw5n7bF6BgirhcYvlb1kVr2XpdAw8G2Ykalk/+8F7FI8RI8IlXmicKRsZ7220u6G1JcSHok9BwCgfyZmSJ0fQjHilnGp4D7sT8v8aUXF3zI8d/lKJEIU8WR8or/vdJi89WZAWFeE8gRx9CgIOEMaw== Received: from [66.196.81.171] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 18:25:49 -0000 Received: from [98.139.211.203] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 18:25:49 -0000 Received: from [127.0.0.1] by smtp212.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 18:25:49 -0000 X-Yahoo-Newman-Id: 683764.28672.bm@smtp212.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: dle50f0VM1mQylYMWiTmKiaWfFS7S38b7FIEKatCOZXZS_i HaL0qcZc4PzMF0CSHln8IhBzko3q1jkZ.iLzsgw2.OA49XlDnAh5u6K4DfLf I73EUWLE_OZDWfXmpVWoIcIunJfz8hzh7v4YBo06Lb9tldLlOCYltWRwHEV2 n2Hy9qqYEoHu5cJBhfWRd1sOxS5TT4fsI9gAVtEBosadhadx_Aj.KD0RtQ.e F7cu5RQWySqT_M6W_DOz74zp9ZJENDhrltVPcXWqEqNJV8IkcsdjeJr7pJ2C LS7SVzklvUQsvBJfqQxeOVYh.I6JY550cnTvZA5fQmGsvlDEz5DkeKV3.Hsm UUrTZgZeVhsgtNvY_JaXWf7hT0Pbw_S9CClhGMWUQL2ygDw_A5FW6SZ16mlM P61O1h_PGgm1dMlzPenp35iI8c0zLozWH4F4vgZeWNfd9QWfDH_NQ5VXX4cY 2YTuk50v0F8lTjZwfR7_ZrKNBAwUaHLX9snIKl_H_FJFaW120PcavVU8TUES EFe6g9FDvCp9LEawHDNo8qSAdKFEbqpnYw.gLPgkE5zWVbw-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: Time to enable partial relro To: Warner Losh References: <20160826105618.GS83214@kib.kiev.ua> Cc: Warner Losh , Konstantin Belousov , "freebsd-toolchain@FreeBSD.org" From: Pedro Giffuni Message-ID: <2e5bee0b-0102-8454-9975-e997bd5229ae@FreeBSD.org> Date: Fri, 26 Aug 2016 13:25:58 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 18:25:51 -0000 On 26/08/2016 11:48, Warner Losh wrote: >> On Aug 26, 2016, at 9:14 AM, Pedro Giffuni wrote: >> >> Hello; >> >> On 08/26/16 10:06, Warner Losh wrote: >>> On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni wrote: >>>> >>>> On 08/26/16 05:56, Konstantin Belousov wrote: >>>>> On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: >>>>>> Hello; >>>>>> >>>>>> GNU RELRO support was committed in r230784 (2012-01-30) but we never >>>>>> enabled it by default. >>>>>> >>>>>> There was some discussion about it on >>>>>> https://reviews.freebsd.org/D3001 >>>>>> >>>>>> By now, all Linux distributions, NetBSD and DragonFly support it and >>>>>> it is the default for most systems in binutils 2.27. >>>>>> >>>>>> This doesn't affect performance, I ran it through an exp-run last >>>>>> year, no other OS has had issues etc ... seems safe and can be >>>>>> disabled if needed when linking. >>>>> Exp-run does not test anything interesting about relro. If all testing >>>>> that was done is basically just an exp-run, then there was no useful >>>>> runtime testing done. >>>>> >>>> The exp-run does cover Java and other VM-type thingies that bootstrap. >>>> For upstream binutils this is now the default (at least for linux, >>>> they never ask us if we want to follow). So the change has been tested >>>> extensively but perhaps not on cases that are relevant to us. >>>> >>>> Note that the "fix" for any port is ultimately trivial: >>>> LDFLAGS+= "-z norelro" >>>> >>>>>> I think it's time to enable it be default in our base binutils. If >>>>>> there are no objections, I will just commit the attached patch over >>>>>> the weekend. >>>>> >>>>> There are objections, the change must be runtime tested on large and >>>>> representative set of real-world applications before turning the knob. >>>>> >>>> You are not giving any hint on what would be a "representative set of >>>> real-world applications". Given that you committed the initial support your >>>> objection stands very high and is a blocker. :( >>>> >>>> As I see it committing it now would give ample time to test this in current >>>> before it hits any release. If you want more extensive testing merging it in >>>> -stable right after the 11-Release is guaranteed to help >>>> weed out any remaining update ports may need. >>> I'd say a minimum is 'buildworld' + a test boot on at least Intel (i386 and >>> amd64), armv6 and mips (both 32-bit and 64-bit) before we proceed. How >>> many of those have we done? >>> >> I have been running it my desktop (amd64) for a year now. I can test i386 in a VM but I doubt it will affect anything. The issue, and it's probably kib's worry are some rarely used but important ports. Stuff like erlang, or virtualbox maybe, but as I wrote, the fix (if needed) >> is trivial by adding a flag to the link command. >> >> FWIW, but it is largely irrelevant to us, RELRO is the default on >> OpenBSD and there is no way out of it there. > What I’m worried about is that our run time linker may get the RELRO stuff wrong and that’s a very platform specific thing and needs to be validated. I also share Kib’s worry about different ports being broken, but that’s a different issue. Recent compilers have broken our run time linker on mips, for example, because they generate new / different relocations than those before. It’s easy enough to test to make sure that we’re good on at least the fairly active platforms (i386, amd64, armv6, mips and mips64) to make sure that nothing bad happens. The others can be tested in due time (though the powerpc ones likely can be tested easily enough by the powerpc guys since they are quite active). > > I get very nervous when I see “should work” or “should be platform independent” for such a low-level thing. OK, the doubts are very reasonable and it is critical for us to effectively test that the runtime linker does the right thing on all platforms (independent on their Tier status). Now that I think about it, even if I/we do commit the change, it is perfectly likely that it won't see the light of a Release: the plans for 12 are to replace GNU ld with lld (no ETA) so what ever we do with ld on -current can stay in current. It does seem important to have the chance to test ld+RELRO at least for a while before moving to lld to make sure things work as they should. Pedro. From owner-freebsd-toolchain@freebsd.org Sat Aug 27 00:00:35 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B851BB76605 for ; Sat, 27 Aug 2016 00:00:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81F43D5 for ; Sat, 27 Aug 2016 00:00:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-pa0-x234.google.com with SMTP id hb8so31478021pac.2 for ; Fri, 26 Aug 2016 17:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=qSAPZTn8yvqZWn1b+vCzI5DGmeBP5Q0//h6MeSeRKNM=; b=ALp+Jh0wRfwV04NIWoo32fFPx1yd0sn3Q1PnFMNybDBHUWZdPWk5rnQjQyZheRGEkk 1zMKe/bVHzVnL0aWiKzZP9qBxA3bmHfKQtcKZV8jCCOXt39UJR2/N0CCyUqBvnFa8Wp2 WO+tDhxSVnHaaTJayJjtNTgaUl7IzvQaoU+ARhNahzJI1Rq/6lRfMGqujCVGrPhp2be3 crF/0Jn1rEU6C2vHHElt1AHRsUDm1NuoafauE+oExKzDuoAcXjpEq3ige7kwKxFg1VCv R6kF/F+8zMTvKb9FhMepN4zNfANDPwUe11R+7szBAgYkaLvLPrWRjuARUlfjiaPeM0jI RNsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=qSAPZTn8yvqZWn1b+vCzI5DGmeBP5Q0//h6MeSeRKNM=; b=NU9SPBah0rHFBsg156SN6hKqpRETIfDbXiVezHVm9WP2e7bBAN1mFRrEFjBU0vl2rn 7KKI111dnWmafmzYb1Uke+xLVxAPJGfAWPa84qy5LlaPHwfAuP5waPg61v/Xz1Lmgq0B w0K6sGftzfOXulbbrGRPN3z+ZCR7abxXbEsrhPpChT/mW+qU/GQ0MrR6OSUggn1iEScr Wgrk0uFQ6e94+ZqOix9wBuaoMdyaTTijhCr5L7VzN9NYlbmMDVxrmu4t7Gls7Y/8wZ12 +6kLKyPPZSNdFczYtEMlVbCpTYN5h07yOXZbo5IERfNWe6/SDnRrBpzLvzdkSaro4Ray PftA== X-Gm-Message-State: AE9vXwPniQNTmmTgFbQS9w5YK0+60AHrlcxMcE4Uy168bm1Bi6Ev8cidfRu3qcM0yDotIw== X-Received: by 10.66.237.71 with SMTP id va7mr10567156pac.124.1472256034984; Fri, 26 Aug 2016 17:00:34 -0700 (PDT) Received: from autobvt-1p7qt1t.corp.netflix.com ([69.53.245.200]) by smtp.gmail.com with ESMTPSA id y9sm31368002pay.25.2016.08.26.17.00.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Aug 2016 17:00:34 -0700 (PDT) Subject: Re: Time to enable partial relro Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_12AA4AEC-110D-4270-9C25-0530546B1392"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Warner Losh In-Reply-To: <2e5bee0b-0102-8454-9975-e997bd5229ae@FreeBSD.org> Date: Fri, 26 Aug 2016 18:00:32 -0600 Cc: Warner Losh , Konstantin Belousov , "freebsd-toolchain@FreeBSD.org" Message-Id: <04514DD6-F431-490D-9ED6-EBFC9DCE97BF@bsdimp.com> References: <20160826105618.GS83214@kib.kiev.ua> <2e5bee0b-0102-8454-9975-e997bd5229ae@FreeBSD.org> To: Pedro Giffuni X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 00:00:35 -0000 --Apple-Mail=_12AA4AEC-110D-4270-9C25-0530546B1392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 26, 2016, at 12:25 PM, Pedro Giffuni wrote: >=20 >=20 >=20 > On 26/08/2016 11:48, Warner Losh wrote: >>> On Aug 26, 2016, at 9:14 AM, Pedro Giffuni wrote: >>>=20 >>> Hello; >>>=20 >>> On 08/26/16 10:06, Warner Losh wrote: >>>> On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni = wrote: >>>>>=20 >>>>> On 08/26/16 05:56, Konstantin Belousov wrote: >>>>>> On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: >>>>>>> Hello; >>>>>>>=20 >>>>>>> GNU RELRO support was committed in r230784 (2012-01-30) but we = never >>>>>>> enabled it by default. >>>>>>>=20 >>>>>>> There was some discussion about it on >>>>>>> https://reviews.freebsd.org/D3001 >>>>>>>=20 >>>>>>> By now, all Linux distributions, NetBSD and DragonFly support it = and >>>>>>> it is the default for most systems in binutils 2.27. >>>>>>>=20 >>>>>>> This doesn't affect performance, I ran it through an exp-run = last >>>>>>> year, no other OS has had issues etc ... seems safe and can be >>>>>>> disabled if needed when linking. >>>>>> Exp-run does not test anything interesting about relro. If all = testing >>>>>> that was done is basically just an exp-run, then there was no = useful >>>>>> runtime testing done. >>>>>>=20 >>>>> The exp-run does cover Java and other VM-type thingies that = bootstrap. >>>>> For upstream binutils this is now the default (at least for linux, >>>>> they never ask us if we want to follow). So the change has been = tested >>>>> extensively but perhaps not on cases that are relevant to us. >>>>>=20 >>>>> Note that the "fix" for any port is ultimately trivial: >>>>> LDFLAGS+=3D "-z norelro" >>>>>=20 >>>>>>> I think it's time to enable it be default in our base binutils. = If >>>>>>> there are no objections, I will just commit the attached patch = over >>>>>>> the weekend. >>>>>>=20 >>>>>> There are objections, the change must be runtime tested on large = and >>>>>> representative set of real-world applications before turning the = knob. >>>>>>=20 >>>>> You are not giving any hint on what would be a "representative set = of >>>>> real-world applications". Given that you committed the initial = support your >>>>> objection stands very high and is a blocker. :( >>>>>=20 >>>>> As I see it committing it now would give ample time to test this = in current >>>>> before it hits any release. If you want more extensive testing = merging it in >>>>> -stable right after the 11-Release is guaranteed to help >>>>> weed out any remaining update ports may need. >>>> I'd say a minimum is 'buildworld' + a test boot on at least Intel = (i386 and >>>> amd64), armv6 and mips (both 32-bit and 64-bit) before we proceed. = How >>>> many of those have we done? >>>>=20 >>> I have been running it my desktop (amd64) for a year now. I can test = i386 in a VM but I doubt it will affect anything. The issue, and it's = probably kib's worry are some rarely used but important ports. Stuff = like erlang, or virtualbox maybe, but as I wrote, the fix (if needed) >>> is trivial by adding a flag to the link command. >>>=20 >>> FWIW, but it is largely irrelevant to us, RELRO is the default on >>> OpenBSD and there is no way out of it there. >> What I=E2=80=99m worried about is that our run time linker may get = the RELRO stuff wrong and that=E2=80=99s a very platform specific thing = and needs to be validated. I also share Kib=E2=80=99s worry about = different ports being broken, but that=E2=80=99s a different issue. = Recent compilers have broken our run time linker on mips, for example, = because they generate new / different relocations than those before. = It=E2=80=99s easy enough to test to make sure that we=E2=80=99re good on = at least the fairly active platforms (i386, amd64, armv6, mips and = mips64) to make sure that nothing bad happens. The others can be tested = in due time (though the powerpc ones likely can be tested easily enough = by the powerpc guys since they are quite active). >>=20 >> I get very nervous when I see =E2=80=9Cshould work=E2=80=9D or = =E2=80=9Cshould be platform independent=E2=80=9D for such a low-level = thing. >=20 > OK, the doubts are very reasonable and it is critical for us to = effectively test > that the runtime linker does the right thing on all platforms = (independent on > their Tier status). >=20 > Now that I think about it, even if I/we do commit the change, it is = perfectly > likely that it won't see the light of a Release: the plans for 12 are = to replace > GNU ld with lld (no ETA) so what ever we do with ld on -current can = stay > in current. It does seem important to have the chance to test ld+RELRO > at least for a while before moving to lld to make sure things work as = they > should. I think we should move forward, just want to make sure it doesn=E2=80=99t = break some arch completely before moving ahead. While lld is a goal, the = goal is also to have a ld.bdf installed for 12, iirc, as a fallback. Warner --Apple-Mail=_12AA4AEC-110D-4270-9C25-0530546B1392 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXwNggAAoJEGwc0Sh9sBEAmaIQAN7qgSJerQvZ3vqi2ogmJ0jy Qz+M7Vm11gqj79ppQx0jvWpGY+R2q8mDahd398/quJ6b4VDTJQlu3knCdja0Sdo+ fEVbfuB6lqXOwMmi5Jm0gM38S6I1AHndnkR+Wg4TXZVXxcZFVll/UHr+nfKOn4Xz 1mM3l1QYVOm0u4vs8rN+XfIUCNUtrvh9KWr50FauKLZ5jHeP3qAsmMMKEqOz0PCD GSf06ufPtjZ+7pr1/HCGC5ARXY2qWbW+F52rdgE1IdA+IE3uW3J/fRVAxk6JlIap mQRgtpNcwTS3IjnzHzZCUlxhEDf0fUqqidY5xGHurxL9W79ld2hCQERqf39+xwm+ HDsNUAHqlcScbCSf+33Ii+kD90qPbuIl4KxAvgvIneSRj1mbThDRFKr5xxU6FmEu F5wV+sEVXk0Ytob5czrMPARPjLXuE1du2EDx1PnsBHj+LkI3B8W59rG2IzajSF0V SpgDe94K9TiBdHOAgwsw39Z+hMjNhBNwGXkw9m+OBLshMQzNPWrzgc9+GCVmgDfz ps1eag1nXS/2qxoNwo9f2QJwZmvCocfWQkXALMW7V3HhMBn0AKQOe9saihEtLsHM DY8WYbh+B/CgSZ3FieCi5w8u4w+WyScHh6bt96q3uKVG+8qk8nupf5dsA/yHSIJs AYzFzxVAMkJOMtQO8UsE =6p/W -----END PGP SIGNATURE----- --Apple-Mail=_12AA4AEC-110D-4270-9C25-0530546B1392-- From owner-freebsd-toolchain@freebsd.org Sat Aug 27 01:13:37 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DC4BA947B4 for ; Sat, 27 Aug 2016 01:13:37 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01DC4D9C for ; Sat, 27 Aug 2016 01:13:36 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472260229; bh=MVz6vY4Azg8A0+p0VeUOC8tBxMUYcdte8z0t7CcilFI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=V/rcOGI6y3hh431OgbWGWXovdAsBOcNTI85CAr4J9Ifph88LoJXXFJYebMXS9M51qfAzPkZiUQLRHA4dyoy+awpTlqu/ucxy95seR1QxuOgCIBksjRfMGepGUKjuXQ1jOmrr6e8XTO4tgbnY2Wyb7Sv83fDJIvFZYCmRQelS8eHlv8T1TLaB8QdUbjnbh1d+KLcPT8WVpYpObI7XoED/d4Af1Q6b6AXv7rj4qo13kON6WHPE7bD+NR6ozUtyHE7DgfhfvfemBA2Ex/sJXksXTvcygWPC9aZMVCFV7hrPTdrS3P7NOSrVgdHWJrBHqCVjeaTa5r4G0rSQZLJONVVN8A== Received: from [66.196.81.173] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2016 01:10:29 -0000 Received: from [68.142.230.76] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2016 01:10:29 -0000 Received: from [127.0.0.1] by smtp233.mail.bf1.yahoo.com with NNFMP; 27 Aug 2016 01:10:29 -0000 X-Yahoo-Newman-Id: 1369.60269.bm@smtp233.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vKNtDlcVM1l5puuOsP8My3jeObKZFw_sFRrO7hCYASyszjk ZUpqe1Q26pbEF.ilZrnuXXGxESNSYoUhx3U99f_nrOOf0jJs52.LVfKSZyO7 J3gvC27L4YV3SMZel2QLvtEFcNpKyAcO4mVnmk7agRAkM.oLE7oZ.UOBF4Zc BR7hdu908M_CHV8yftFoC7fp0zIRwEWBkaD76NTBvwXuO71CwU3GZ9jAo.GW AjQNc1aiXCL8kdjDM6uKd1ZtT40UAW9BEEHuDHBZEgEFENOhuZloPL199Xth nOPgPiJ87lNs8_wj8PRqFzdJF91dYvQ8WcsfNCFJZkHUgCGz4OKKdAxMQBE6 vtqgVhaJFnzlAWx8cCW.qwP2NR8p9gzImUX83gCX51Cr2Ut2ZmOqVnH1Bg86 URMoweJ936vtBnNbshIZycjUKUw7QE2xlUFx1UHPqVLawQ6x9n01Lq5mhzgb 1bitKzrEwx5VUWWczkTPIm2KcSobdXX2uoQTdmD8iDO2IB.5k1sH7IOw8Y.p v5v4hmH5fYgxh66wbSrVROrCZKfvGTnHWfdv3OFIHzRNxUg-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: Time to enable partial relro To: Warner Losh References: <20160826105618.GS83214@kib.kiev.ua> <2e5bee0b-0102-8454-9975-e997bd5229ae@FreeBSD.org> <04514DD6-F431-490D-9ED6-EBFC9DCE97BF@bsdimp.com> Cc: Warner Losh , Konstantin Belousov , "freebsd-toolchain@FreeBSD.org" From: Pedro Giffuni Message-ID: Date: Fri, 26 Aug 2016 20:10:37 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <04514DD6-F431-490D-9ED6-EBFC9DCE97BF@bsdimp.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 01:13:37 -0000 On 26/08/2016 19:00, Warner Losh wrote: >> On Aug 26, 2016, at 12:25 PM, Pedro Giffuni wrote: >> >> >> >> On 26/08/2016 11:48, Warner Losh wrote: >>>> On Aug 26, 2016, at 9:14 AM, Pedro Giffuni wrote: >>>> >>>> Hello; >>>> >>>> On 08/26/16 10:06, Warner Losh wrote: >>>>> On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni wrote: >>>>>> On 08/26/16 05:56, Konstantin Belousov wrote: >>>>>>> On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: >>>>>>>> Hello; >>>>>>>> >>>>>>>> GNU RELRO support was committed in r230784 (2012-01-30) but we never >>>>>>>> enabled it by default. >>>>>>>> >>>>>>>> There was some discussion about it on >>>>>>>> https://reviews.freebsd.org/D3001 >>>>>>>> >>>>>>>> By now, all Linux distributions, NetBSD and DragonFly support it and >>>>>>>> it is the default for most systems in binutils 2.27. >>>>>>>> >>>>>>>> This doesn't affect performance, I ran it through an exp-run last >>>>>>>> year, no other OS has had issues etc ... seems safe and can be >>>>>>>> disabled if needed when linking. >>>>>>> Exp-run does not test anything interesting about relro. If all testing >>>>>>> that was done is basically just an exp-run, then there was no useful >>>>>>> runtime testing done. >>>>>>> >>>>>> The exp-run does cover Java and other VM-type thingies that bootstrap. >>>>>> For upstream binutils this is now the default (at least for linux, >>>>>> they never ask us if we want to follow). So the change has been tested >>>>>> extensively but perhaps not on cases that are relevant to us. >>>>>> >>>>>> Note that the "fix" for any port is ultimately trivial: >>>>>> LDFLAGS+= "-z norelro" >>>>>> >>>>>>>> I think it's time to enable it be default in our base binutils. If >>>>>>>> there are no objections, I will just commit the attached patch over >>>>>>>> the weekend. >>>>>>> There are objections, the change must be runtime tested on large and >>>>>>> representative set of real-world applications before turning the knob. >>>>>>> >>>>>> You are not giving any hint on what would be a "representative set of >>>>>> real-world applications". Given that you committed the initial support your >>>>>> objection stands very high and is a blocker. :( >>>>>> >>>>>> As I see it committing it now would give ample time to test this in current >>>>>> before it hits any release. If you want more extensive testing merging it in >>>>>> -stable right after the 11-Release is guaranteed to help >>>>>> weed out any remaining update ports may need. >>>>> I'd say a minimum is 'buildworld' + a test boot on at least Intel (i386 and >>>>> amd64), armv6 and mips (both 32-bit and 64-bit) before we proceed. How >>>>> many of those have we done? >>>>> >>>> I have been running it my desktop (amd64) for a year now. I can test i386 in a VM but I doubt it will affect anything. The issue, and it's probably kib's worry are some rarely used but important ports. Stuff like erlang, or virtualbox maybe, but as I wrote, the fix (if needed) >>>> is trivial by adding a flag to the link command. >>>> >>>> FWIW, but it is largely irrelevant to us, RELRO is the default on >>>> OpenBSD and there is no way out of it there. >>> What I’m worried about is that our run time linker may get the RELRO stuff wrong and that’s a very platform specific thing and needs to be validated. I also share Kib’s worry about different ports being broken, but that’s a different issue. Recent compilers have broken our run time linker on mips, for example, because they generate new / different relocations than those before. It’s easy enough to test to make sure that we’re good on at least the fairly active platforms (i386, amd64, armv6, mips and mips64) to make sure that nothing bad happens. The others can be tested in due time (though the powerpc ones likely can be tested easily enough by the powerpc guys since they are quite active). >>> >>> I get very nervous when I see “should work” or “should be platform independent” for such a low-level thing. >> OK, the doubts are very reasonable and it is critical for us to effectively test >> that the runtime linker does the right thing on all platforms (independent on >> their Tier status). >> >> Now that I think about it, even if I/we do commit the change, it is perfectly >> likely that it won't see the light of a Release: the plans for 12 are to replace >> GNU ld with lld (no ETA) so what ever we do with ld on -current can stay >> in current. It does seem important to have the chance to test ld+RELRO >> at least for a while before moving to lld to make sure things work as they >> should. > I think we should move forward, just want to make sure it doesn’t break some arch completely before moving ahead. While lld is a goal, the goal is also to have a ld.bdf installed for 12, iirc, as a fallback. And very right you are, this has all the chances of breaking MIPS*: "A configure option --enable-relro={yes|no} to decide whether -z relro should be the default behaviour for the linker in ELF based targets. If this configure option is not specified then relro will be enabled automatically for all Linux based targets except FRV, HPPA, IA64 and MIPS." _____ I will update the patch to exclude MIPS (and MIPS64 JIC). Pedro. *https://gcc.gnu.org/ml/gcc/2016-08/msg00134.html From owner-freebsd-toolchain@freebsd.org Sat Aug 27 01:48:58 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CFBAB70151 for ; Sat, 27 Aug 2016 01:48:58 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 236A9F56 for ; Sat, 27 Aug 2016 01:48:57 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472262531; bh=AtE+R5qfnGEjAdvO1rPdVPOhoCIWEdCMjKAfImnXjfw=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=oW9XYGxMmVm+r75hD61ajz67EozhQRrg7PxVbbtuJ72hrC2cAo63aPV+N4TCKrsDIGxxj6jLk5LqhX8RkNEBPNOJe3H+iXTcHBaI49AvZsNxTvhSQU26FDsUlKfImc62BAEkKOaA7Zygvsr8zKxMFT5ASMOUpDTNGQXK7v0WePVfr9V5XoLFex341qEGALV+mEW+uUJeNIOYGjBEmOH8QmlSheJPempKFMh3qP6rkuhkXffJr+1XvziO2AG6egJzYidMI3fG0ApOtCXCnUV0r5EFeoBZR5uk5meCeQHQTTmCaDvj8ZK6/4iMfwICSsC2/lUf20cco4WQyyXv62QF9w== Received: from [66.196.81.174] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2016 01:48:51 -0000 Received: from [98.139.213.11] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2016 01:48:50 -0000 Received: from [127.0.0.1] by smtp111.mail.bf1.yahoo.com with NNFMP; 27 Aug 2016 01:48:50 -0000 X-Yahoo-Newman-Id: 985046.28140.bm@smtp111.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Z.8287IVM1kp2niYumUMi_MCdQ52Q8WE.VCGSb2IKxI72dI bGaP0oxnK.mDI_le_wjP1OTfYhmbpFVEq.QGejdq67rVMPVzA59HLb3zX9PY gSOwV3uLhRuyiVE17Ez7i0AOzY2QUUlOiYnviviY0GUJ8XGaqX7pLowkXJEu yjD7Xula1jFcXLJMpZe6eVKWNAmDCLVGqXVFol7YzIx601Z5Bb8DyYmkkbfE COwPC4_Le3KSKQPBP3y56buSHj6a37xO4bLFyOfkFUGFFKf4Dwm2ZJUZRGJK ADZgPNwzfz9GSeJ1c7v8qOchKR3xrgj0LFjpItblAdNl3y.N9YPybx9LvjJg l86uK_wb2b3pI1BNXufJDpzGhI3ZXNrjW0fvXCFnHdri.t2rvFeTR3987KhT PrXrsCcUgOyjANJk5xSthaYO4yCD1nXjKvV00_fTzmyPY9ERTk7ScfkMfeMj s7JNxLjPl1NUR2gzLr3_MaPQolzq3tEQYEWsRyJ_atXZDcadbllCd.Vm94Nd DORSP7G.PLhduJzmzmY1h1SqIMtrfXozuhKM9vK6kQeqXww-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: Time to enable partial relro To: "freebsd-toolchain@FreeBSD.org" References: <20160826105618.GS83214@kib.kiev.ua> <2e5bee0b-0102-8454-9975-e997bd5229ae@FreeBSD.org> <04514DD6-F431-490D-9ED6-EBFC9DCE97BF@bsdimp.com> From: Pedro Giffuni Message-ID: Date: Fri, 26 Aug 2016 20:49:01 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 01:48:58 -0000 For the record ... On 08/26/16 20:10, Pedro Giffuni wrote: > > > On 26/08/2016 19:00, Warner Losh wrote: ... >> I think we should move forward, just want to make sure it doesn’t >> break some arch completely before moving ahead. While lld is a goal, >> the goal is also to have a ld.bdf installed for 12, iirc, as a fallback. > > And very right you are, this has all the chances of breaking MIPS*: > > "A configure option --enable-relro={yes|no} to decide > whether -z relro should be the default behaviour for > the linker in ELF based targets. If this configure > option is not specified then relro will be enabled > automatically for all Linux based targets except FRV, > HPPA, IA64 and MIPS." > > _____ > > I will update the patch to exclude MIPS (and MIPS64 JIC). > The new patch is here: https://people.freebsd.org/~pfg/patches/partial-relro.diff If we were ever to MFC this, we would have to add IA64 to the exclusion list. Pedro. From owner-freebsd-toolchain@freebsd.org Sat Aug 27 10:35:39 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F50AA93C22 for ; Sat, 27 Aug 2016 10:35:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-14.reflexion.net [208.70.210.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 072EE384 for ; Sat, 27 Aug 2016 10:35:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19090 invoked from network); 27 Aug 2016 10:35:31 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 27 Aug 2016 10:35:31 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Sat, 27 Aug 2016 06:35:34 -0400 (EDT) Received: (qmail 18782 invoked from network); 27 Aug 2016 10:35:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Aug 2016 10:35:34 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 4F9751C4379; Sat, 27 Aug 2016 03:35:29 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: Time to enable partial relro [a stable/11 -r304029 armv6 "PT2MAP abort" (copyout+0x2c4) panic possibly related to enabling RELRO?] Date: Sat, 27 Aug 2016 03:35:29 -0700 Message-Id: <1178F89E-F1A3-4B72-8906-EFB8EFCE9F7D@dsl-only.net> Cc: FreeBSD Current To: FreeBSD Toolchain , freebsd-arm , freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 10:35:39 -0000 [I've no solid evidence of what the panic is tied to. = OPTIONS_FILE_SET+=3DRELRO ise is just what was new/unusual in the = portmaster -DKa that was going on when the rpi2 had the panic.] The console history shows (the cc quoted just gives a ball park for = where it was in the binutils build): > cc -DHAVE_CONFIG_H -I. -I. -I. -I../bfd -I./../bfd -I./../include = -pipe -mcpu=3Dcortex-a7 -I/usr/local/include -g -fno-strict-aliasing = -DENABLE_PLUGINS -DLOCAL > EDIR=3D"\"/usr/local/share/locale\"" -mcpu=3Dcortex-a7 -W -Wall = -Wstrict-prototypes -Wmissing-prototypes -Wshadow = -DELF_LIST_OPTIONS=3DTRUE -DELF_SHLIB_LIST_OPTIONS=3DT > RUE -DELF_PLT_UNWIND_LIST_OPTIONS=3DTRUE -pipe -mcpu=3Dcortex-a7 = -I/usr/local/include -g -fno-strict-aliasing -MT eavrxmega2.o -MD -MP = -MF .deps/eavrxmega2.Tpo -c=20 > -o eavrxmega2.o eavrxmega2.c > panic: pmap_fault: PT2MAP abort > cpuid =3D 3 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc =3D 0xc06b2ad0 lr =3D 0xc014edf4 = (db_trace_self_wrapper+0x30) > sp =3D 0xed27c880 fp =3D 0xed27c998 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc =3D 0xc014edf4 lr =3D 0xc0336968 (vpanic+0x13c) > sp =3D 0xed27c9a0 fp =3D 0xed27c9c0 > r4 =3D 0x00000100 r5 =3D 0xc4125a50 > r6 =3D 0xc076ab91 r7 =3D 0x00000001 > vpanic() at vpanic+0x13c > pc =3D 0xc0336968 lr =3D 0xc033682c (vpanic) > sp =3D 0xed27c9c8 fp =3D 0xed27c9cc > r4 =3D 0xc0991ba0 r5 =3D 0x00000000 > r6 =3D 0xbfefefe8 r7 =3D 0x00000007 > r8 =3D 0x00000013 r9 =3D 0x00000007 > r10 =3D 0xc41daf44 > vpanic() at vpanic > pc =3D 0xc033682c lr =3D 0xc06ce40c (pmap_fault+0x638) > sp =3D 0xed27c9d4 fp =3D 0xed27ca08 > r4 =3D 0x00000007 r5 =3D 0x00000013 > r6 =3D 0x00000007 r7 =3D 0xc41daf44 > r8 =3D 0xed27c9cc r9 =3D 0xc033682c > r10 =3D 0xed27c9d4 > pmap_fault() at pmap_fault+0x638 > pc =3D 0xc06ce40c lr =3D 0xc06d30f8 (abort_handler+0xbc) > sp =3D 0xed27ca10 fp =3D 0xed27caa0 > r4 =3D 0xc0991ba0 r5 =3D 0x00000007 > r6 =3D 0x00000000 r7 =3D 0x00000007 > r8 =3D 0x00000013 r9 =3D 0xc4125a50 > r10 =3D 0xed27caa8 > abort_handler() at abort_handler+0xbc > pc =3D 0xc06d30f8 lr =3D 0xc06b53b8 (exception_exit) > sp =3D 0xed27caa8 fp =3D 0xed27cb60 > r4 =3D 0xc0991ba0 r5 =3D 0x00000000 > r6 =3D 0xbfbfaa04 r7 =3D 0x00000006 > r8 =3D 0xc41daf54 r9 =3D 0x00000806 > r10 =3D 0xc41daf44 > exception_exit() at exception_exit > pc =3D 0xc06b53b8 lr =3D 0xc03131e8 (__mtx_lock_sleep+0x220) > sp =3D 0xed27cb38 fp =3D 0xed27cb60 > r0 =3D 0x002fefe8 r1 =3D 0xbfc00000 > r2 =3D 0xc41daf44 r3 =3D 0x00000001 > r4 =3D 0xc0991ba0 r5 =3D 0x00000000 > r6 =3D 0xbfbfaa04 r7 =3D 0x00000006 > r8 =3D 0xc41daf54 r9 =3D 0x00000806 > r10 =3D 0xc41daf44 r12 =3D 0xed27ca78 > pmap_fault() at pmap_fault+0x1b4 > pc =3D 0xc06cdf88 lr =3D 0xc06d30f8 (abort_handler+0xbc) > sp =3D 0xed27cb68 fp =3D 0xed27cbf8 > r4 =3D 0x00000030 r5 =3D 0x00000006 > r6 =3D 0x00000000 r7 =3D 0x00000806 > r8 =3D 0x00000013 r9 =3D 0xc4125a50 > r10 =3D 0xed27cc00 > abort_handler() at abort_handler+0xbc > pc =3D 0xc06d30f8 lr =3D 0xc06b53b8 (exception_exit) > sp =3D 0xed27cc00 fp =3D 0x00000000 > r4 =3D 0x00000030 r5 =3D 0x00000000 > r6 =3D 0x00000000 r7 =3D 0xed27ccb4 > r8 =3D 0xed27ce00 r9 =3D 0x00000000 > r10 =3D 0xed27cea0 > exception_exit() at exception_exit > pc =3D 0xc06b53b8 lr =3D 0xc06ad77c (copyout+0x9c) > sp =3D 0xed27cc94 fp =3D 0x00000000 > r0 =3D 0xed27ccb8 r1 =3D 0xbfbfaa04 > r2 =3D 0x00000000 r3 =3D 0x00000000 > r4 =3D 0x00000030 r5 =3D 0x00000000 > r6 =3D 0x00000000 r7 =3D 0xed27ccb4 > r8 =3D 0xed27ce00 r9 =3D 0x00000000 > r10 =3D 0xed27cea0 r12 =3D 0x00000000 > copyout() at copyout+0x2c4 > pc =3D 0xc06ad9a4 lr =3D 0xc06ad77c (copyout+0x9c) > sp =3D 0xed27cc94 fp =3D 0x00000000 > copyout() at copyout+0x9c > pc =3D 0xc06ad77c lr =3D 0xc06ad77c (copyout+0x9c) > sp =3D 0xed27cc94 fp =3D 0x00000000 > Unwind failure (no registers changed) > KDB: enter: panic > [ thread pid 54457 tid 100158 ] > Stopped at $d.6: ldrb r15, [r15, r15, ror r15]! > db>=20 The portmaster -DKa attempt to rebuild binutils-2.27 on the rpi2 got my = first armv6 stable/11 panic (and it has been much longer then that since = I've gotten a 11.0-CURRENT panic). I was not around when the panic = happened but it is still sitting at the db> serial console prompt and I = can enter commands if appropriate. FreeBSD 11.0 context: The rpi2 was/is at /usr/src/ stable/11 -r304029 : = it has been a while since I've updated to track stable/11 . The few = differences in my /usr/src are mostly for powerpc and powerpc64 specific = changes: I normally use the same tree content everywhere that I build = FreeBSD. The build used -mcpu=3Dcortex-a7 as I've been doing since I = started tracking the clang 3.8.0 project before it was merged. Ports context: I had not updated by ports on the rpi2 in a while and I = "svnlite updated" my /usr/ports to -r420950, picking the newer option to = enable RELRO by default for things that have it. I enabled those = defaults. (Doing similarly on amd64 first has had no troubles for me so = far, not that I've done much after the portmaster -DKa .) =46rom the amd64 environment that I did an /usr/ports/ portmaster -DKa = update to first, also tied to -r420950: > # more /var/db/ports/devel_binutils/options > # This file is auto-generated by 'make config'. > # Options for binutils-2.27,1 > _OPTIONS_READ=3Dbinutils-2.27,1 > _FILE_COMPLETE_OPTIONS_LIST=3DNLS RELRO > OPTIONS_FILE_SET+=3DNLS > OPTIONS_FILE_SET+=3DRELRO > # svnlite info /usr/ports | grep Re[lv][ai:] > Relative URL: ^/head > Revision: 420950 > Last Changed Rev: 420950 > # more /etc/make.conf > WANT_QT_VERBOSE_CONFIGURE=3D1 > # > DEFAULT_VERSIONS+=3Dperl5=3D5.22 > WRKDIRPREFIX=3D/usr/obj/portswork > WITH_DEBUG=3D > WITH_DEBUG_FILES=3D > MALLOC_PRODUCTION=3D If I remember right the above are accurate for the rpi2 as well. I'll note that arm-none-eabi-binutils-2.27,1 built and installed fine = earlier in the portmaster -DKa activity. As did pkgconf-1.0.1 and = sqlite3-3.14.1 . (The console history goes not go back to earlier then = that. (sqlite3 is via dependencies, not something I directly select to = build.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Aug 27 13:53:41 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A10FFB76103 for ; Sat, 27 Aug 2016 13:53:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-14.reflexion.net [208.70.210.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 616F5881 for ; Sat, 27 Aug 2016 13:53:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16641 invoked from network); 27 Aug 2016 13:54:22 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Aug 2016 13:54:22 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Sat, 27 Aug 2016 09:53:31 -0400 (EDT) Received: (qmail 26769 invoked from network); 27 Aug 2016 13:53:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Aug 2016 13:53:31 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id D6AAD1C407B; Sat, 27 Aug 2016 06:53:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Time to enable partial relro [a stable/11 -r304029 armv6 "PT2MAP abort" (copyout+0x2c4) panic possibly related to enabling RELRO?] From: Mark Millard In-Reply-To: <1178F89E-F1A3-4B72-8906-EFB8EFCE9F7D@dsl-only.net> Date: Sat, 27 Aug 2016 06:53:37 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <71722159-7E12-4EAD-BD29-669C1F6C8061@dsl-only.net> References: <1178F89E-F1A3-4B72-8906-EFB8EFCE9F7D@dsl-only.net> To: FreeBSD Toolchain , freebsd-arm , freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 13:53:41 -0000 Quick top post: retrying "portmaster -DKa" after rebooting did not = repeat the panic. OPTIONS_FILE_SET+=3DRELRO likely has nothing to do with the unusual = panic. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Aug-27, at 3:35 AM, Mark Millard wrote: [I've no solid evidence of what the panic is tied to. = OPTIONS_FILE_SET+=3DRELRO ise is just what was new/unusual in the = portmaster -DKa that was going on when the rpi2 had the panic.] The console history shows (the cc quoted just gives a ball park for = where it was in the binutils build): > cc -DHAVE_CONFIG_H -I. -I. -I. -I../bfd -I./../bfd -I./../include = -pipe -mcpu=3Dcortex-a7 -I/usr/local/include -g -fno-strict-aliasing = -DENABLE_PLUGINS -DLOCAL > EDIR=3D"\"/usr/local/share/locale\"" -mcpu=3Dcortex-a7 -W -Wall = -Wstrict-prototypes -Wmissing-prototypes -Wshadow = -DELF_LIST_OPTIONS=3DTRUE -DELF_SHLIB_LIST_OPTIONS=3DT > RUE -DELF_PLT_UNWIND_LIST_OPTIONS=3DTRUE -pipe -mcpu=3Dcortex-a7 = -I/usr/local/include -g -fno-strict-aliasing -MT eavrxmega2.o -MD -MP = -MF .deps/eavrxmega2.Tpo -c=20 > -o eavrxmega2.o eavrxmega2.c > panic: pmap_fault: PT2MAP abort > cpuid =3D 3 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc =3D 0xc06b2ad0 lr =3D 0xc014edf4 = (db_trace_self_wrapper+0x30) > sp =3D 0xed27c880 fp =3D 0xed27c998 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc =3D 0xc014edf4 lr =3D 0xc0336968 (vpanic+0x13c) > sp =3D 0xed27c9a0 fp =3D 0xed27c9c0 > r4 =3D 0x00000100 r5 =3D 0xc4125a50 > r6 =3D 0xc076ab91 r7 =3D 0x00000001 > vpanic() at vpanic+0x13c > pc =3D 0xc0336968 lr =3D 0xc033682c (vpanic) > sp =3D 0xed27c9c8 fp =3D 0xed27c9cc > r4 =3D 0xc0991ba0 r5 =3D 0x00000000 > r6 =3D 0xbfefefe8 r7 =3D 0x00000007 > r8 =3D 0x00000013 r9 =3D 0x00000007 > r10 =3D 0xc41daf44 > vpanic() at vpanic > pc =3D 0xc033682c lr =3D 0xc06ce40c (pmap_fault+0x638) > sp =3D 0xed27c9d4 fp =3D 0xed27ca08 > r4 =3D 0x00000007 r5 =3D 0x00000013 > r6 =3D 0x00000007 r7 =3D 0xc41daf44 > r8 =3D 0xed27c9cc r9 =3D 0xc033682c > r10 =3D 0xed27c9d4 > pmap_fault() at pmap_fault+0x638 > pc =3D 0xc06ce40c lr =3D 0xc06d30f8 (abort_handler+0xbc) > sp =3D 0xed27ca10 fp =3D 0xed27caa0 > r4 =3D 0xc0991ba0 r5 =3D 0x00000007 > r6 =3D 0x00000000 r7 =3D 0x00000007 > r8 =3D 0x00000013 r9 =3D 0xc4125a50 > r10 =3D 0xed27caa8 > abort_handler() at abort_handler+0xbc > pc =3D 0xc06d30f8 lr =3D 0xc06b53b8 (exception_exit) > sp =3D 0xed27caa8 fp =3D 0xed27cb60 > r4 =3D 0xc0991ba0 r5 =3D 0x00000000 > r6 =3D 0xbfbfaa04 r7 =3D 0x00000006 > r8 =3D 0xc41daf54 r9 =3D 0x00000806 > r10 =3D 0xc41daf44 > exception_exit() at exception_exit > pc =3D 0xc06b53b8 lr =3D 0xc03131e8 (__mtx_lock_sleep+0x220) > sp =3D 0xed27cb38 fp =3D 0xed27cb60 > r0 =3D 0x002fefe8 r1 =3D 0xbfc00000 > r2 =3D 0xc41daf44 r3 =3D 0x00000001 > r4 =3D 0xc0991ba0 r5 =3D 0x00000000 > r6 =3D 0xbfbfaa04 r7 =3D 0x00000006 > r8 =3D 0xc41daf54 r9 =3D 0x00000806 > r10 =3D 0xc41daf44 r12 =3D 0xed27ca78 > pmap_fault() at pmap_fault+0x1b4 > pc =3D 0xc06cdf88 lr =3D 0xc06d30f8 (abort_handler+0xbc) > sp =3D 0xed27cb68 fp =3D 0xed27cbf8 > r4 =3D 0x00000030 r5 =3D 0x00000006 > r6 =3D 0x00000000 r7 =3D 0x00000806 > r8 =3D 0x00000013 r9 =3D 0xc4125a50 > r10 =3D 0xed27cc00 > abort_handler() at abort_handler+0xbc > pc =3D 0xc06d30f8 lr =3D 0xc06b53b8 (exception_exit) > sp =3D 0xed27cc00 fp =3D 0x00000000 > r4 =3D 0x00000030 r5 =3D 0x00000000 > r6 =3D 0x00000000 r7 =3D 0xed27ccb4 > r8 =3D 0xed27ce00 r9 =3D 0x00000000 > r10 =3D 0xed27cea0 > exception_exit() at exception_exit > pc =3D 0xc06b53b8 lr =3D 0xc06ad77c (copyout+0x9c) > sp =3D 0xed27cc94 fp =3D 0x00000000 > r0 =3D 0xed27ccb8 r1 =3D 0xbfbfaa04 > r2 =3D 0x00000000 r3 =3D 0x00000000 > r4 =3D 0x00000030 r5 =3D 0x00000000 > r6 =3D 0x00000000 r7 =3D 0xed27ccb4 > r8 =3D 0xed27ce00 r9 =3D 0x00000000 > r10 =3D 0xed27cea0 r12 =3D 0x00000000 > copyout() at copyout+0x2c4 > pc =3D 0xc06ad9a4 lr =3D 0xc06ad77c (copyout+0x9c) > sp =3D 0xed27cc94 fp =3D 0x00000000 > copyout() at copyout+0x9c > pc =3D 0xc06ad77c lr =3D 0xc06ad77c (copyout+0x9c) > sp =3D 0xed27cc94 fp =3D 0x00000000 > Unwind failure (no registers changed) > KDB: enter: panic > [ thread pid 54457 tid 100158 ] > Stopped at $d.6: ldrb r15, [r15, r15, ror r15]! > db>=20 The portmaster -DKa attempt to rebuild binutils-2.27 on the rpi2 got my = first armv6 stable/11 panic (and it has been much longer then that since = I've gotten a 11.0-CURRENT panic). I was not around when the panic = happened but it is still sitting at the db> serial console prompt and I = can enter commands if appropriate. FreeBSD 11.0 context: The rpi2 was/is at /usr/src/ stable/11 -r304029 : = it has been a while since I've updated to track stable/11 . The few = differences in my /usr/src are mostly for powerpc and powerpc64 specific = changes: I normally use the same tree content everywhere that I build = FreeBSD. The build used -mcpu=3Dcortex-a7 as I've been doing since I = started tracking the clang 3.8.0 project before it was merged. Ports context: I had not updated by ports on the rpi2 in a while and I = "svnlite updated" my /usr/ports to -r420950, picking the newer option to = enable RELRO by default for things that have it. I enabled those = defaults. (Doing similarly on amd64 first has had no troubles for me so = far, not that I've done much after the portmaster -DKa .) =46rom the amd64 environment that I did an /usr/ports/ portmaster -DKa = update to first, also tied to -r420950: > # more /var/db/ports/devel_binutils/options > # This file is auto-generated by 'make config'. > # Options for binutils-2.27,1 > _OPTIONS_READ=3Dbinutils-2.27,1 > _FILE_COMPLETE_OPTIONS_LIST=3DNLS RELRO > OPTIONS_FILE_SET+=3DNLS > OPTIONS_FILE_SET+=3DRELRO > # svnlite info /usr/ports | grep Re[lv][ai:] > Relative URL: ^/head > Revision: 420950 > Last Changed Rev: 420950 > # more /etc/make.conf > WANT_QT_VERBOSE_CONFIGURE=3D1 > # > DEFAULT_VERSIONS+=3Dperl5=3D5.22 > WRKDIRPREFIX=3D/usr/obj/portswork > WITH_DEBUG=3D > WITH_DEBUG_FILES=3D > MALLOC_PRODUCTION=3D If I remember right the above are accurate for the rpi2 as well. I'll note that arm-none-eabi-binutils-2.27,1 built and installed fine = earlier in the portmaster -DKa activity. As did pkgconf-1.0.1 and = sqlite3-3.14.1 . (The console history goes not go back to earlier then = that. (sqlite3 is via dependencies, not something I directly select to = build.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Aug 27 17:45:58 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16999B77991 for ; Sat, 27 Aug 2016 17:45:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2A92EAA; Sat, 27 Aug 2016 17:45:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u7RHjj3U020081 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 27 Aug 2016 20:45:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7RHjj3U020081 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7RHjj9P020076; Sat, 27 Aug 2016 20:45:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 27 Aug 2016 20:45:45 +0300 From: Konstantin Belousov To: Pedro Giffuni Cc: "freebsd-toolchain@FreeBSD.org" , Warner Losh , Baptiste Daroussin , Mark Millard Subject: Re: Time to enable partial relro Message-ID: <20160827174544.GC83214@kib.kiev.ua> References: <20160826105618.GS83214@kib.kiev.ua> <2e5bee0b-0102-8454-9975-e997bd5229ae@FreeBSD.org> <04514DD6-F431-490D-9ED6-EBFC9DCE97BF@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 17:45:58 -0000 On Sat, Aug 27, 2016 at 11:06:54AM -0500, Pedro Giffuni wrote: > > > On 08/26/16 20:10, Pedro Giffuni wrote: > > > > > ...>> I think we should move forward, just want to make sure it doesn???t > >> break some arch completely before moving ahead. While lld is a goal, > >> the goal is also to have a ld.bdf installed for 12, iirc, as a fallback. > > > > And very right you are, this has all the chances of breaking MIPS*: > > > > "A configure option --enable-relro={yes|no} to decide > > whether -z relro should be the default behaviour for > > the linker in ELF based targets. If this configure > > option is not specified then relro will be enabled > > automatically for all Linux based targets except FRV, > > HPPA, IA64 and MIPS." > > > > _____ > > > > I will update the patch to exclude MIPS (and MIPS64 JIC). > > > > Pedro. > > > > *https://gcc.gnu.org/ml/gcc/2016-08/msg00134.html > > > > Looking more into this, and the arm report from Mark Millard (thanks!), > binutils has tests for RELRO in their testsuite that would be an > important indicator before enabling the option. > > It surprises me that we don't have an easy way to run those checks from > the port, so I borrowed the regression-test mode from GCC and I am > attaching it. > > The tests may depend on some gnu-isms but we don't appear to do too > well on the tests: > > === ld Summary === > > # of expected passes 511 > # of unexpected failures 78 > # of expected failures 4 > # of unresolved testcases 35 > # of untested testcases 1 > # of unsupported tests 9 > /usr/ports/devel/binutils/work/binutils-2.27/ld/ld-new 2.27 And ? In which way this data is useful or indicative of anything ? Why this tests are relevant to the proposed change ? AFAIK, binutils tests typically compare ld output against expected binary. And, number of the unexpected failures in your showcase is quite worrying. From owner-freebsd-toolchain@freebsd.org Sat Aug 27 18:32:17 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8896FB775E4 for ; Sat, 27 Aug 2016 18:32:17 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm37-vm0.bullet.mail.bf1.yahoo.com (nm37-vm0.bullet.mail.bf1.yahoo.com [72.30.238.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BB238C4 for ; Sat, 27 Aug 2016 18:32:16 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472322735; bh=0uM4DFZ9hIByzXpaTKSywBPAxGi88SiEdeFxj4ZM3OM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=BhytqLkB8hB08fDWioKeG91L8XpJyKv+E4Z2TTnblQ0PaC5cxZVzReQtV7HhWzV0we21wuIKS+qQKadelfaQ73fv7bU0oCNwhN3iSPoWnTdT8bPdChXoGTSCiTfJPYhLSVOHmz78NsBn3ShixCwkMl9WXAmQx81ruAzl/XD+agrSzVzihlLrpSJPDbtJrYgpSQMPwrIeA/A3RBeeiiIIDBkt8ymhOQH7JeJrpo7dMGlF5L16qWLpFfOpgEpE/XpxvIZ4j3KkB6pqlKiSyndc7COu4uG7mlNlVVGj3kiPotxZqPsvI29ddP1ENHSfziDNOSL2zlWYajDM3z7mzy4Idw== Received: from [66.196.81.170] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2016 18:32:15 -0000 Received: from [98.139.213.9] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2016 18:32:15 -0000 Received: from [127.0.0.1] by smtp109.mail.bf1.yahoo.com with NNFMP; 27 Aug 2016 18:32:15 -0000 X-Yahoo-Newman-Id: 586754.47094.bm@smtp109.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: jeDJ4vEVM1ldWb_Sexk5P4zvA3DfiPiy4f7GDmGyvoBchyt .EeJDhPAoXy5lMC1oKTE_rmazelLLVYPhtHJl.FISK91LM4640bNwmcHC8bY FSo04F3xcT6ZPzkefqgVuSnEaHlS7AfUiSiL8RUtra_jtvodqQ_u9FJKTK.Z ezxVTn1uRr4f_Nnhxxsc.Q4pnQkaJvqJhjWjoznC4abCUj.1w8fne1yu.o.0 zNI1sExcxyO5dYqJxzOJbGhYHeqhhiNZ1aWoSLeHSCPh7P4KUF_sBRM6ht6O i1EgLW2TlBgyGdUk289goTceGCZVzcfAPCztGjdTXKcxXYOjQS019l8vqfB_ vdkfseDAVfWy2JQofJIEJQXTnASRUubKdrxaFp_8ElJughOiH9sqtfu0epu7 eIqrk34jB4XeawDxfGOJPHTWP1jKXvlLQq4SNdKYUcjM2G_BbkY37udB9z6z YHXxv6Xl0aH0c.XUe1gQDvtS8ODypbOZAVsJSilET3i7pZ4GhVbe5z2m_VFc pX3b3xihSkmMycUoNM1RP_9tOKZxO8.NnI92oDjlHBs0X2Q-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: Time to enable partial relro To: Konstantin Belousov References: <20160826105618.GS83214@kib.kiev.ua> <2e5bee0b-0102-8454-9975-e997bd5229ae@FreeBSD.org> <04514DD6-F431-490D-9ED6-EBFC9DCE97BF@bsdimp.com> <20160827174544.GC83214@kib.kiev.ua> Cc: "freebsd-toolchain@FreeBSD.org" , Warner Losh , Baptiste Daroussin , Mark Millard From: Pedro Giffuni Message-ID: <5fe3c09d-7a01-25c7-43de-c7176755a96b@FreeBSD.org> Date: Sat, 27 Aug 2016 13:32:23 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160827174544.GC83214@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 18:32:17 -0000 On 08/27/16 12:45, Konstantin Belousov wrote: > On Sat, Aug 27, 2016 at 11:06:54AM -0500, Pedro Giffuni wrote: >> >> >> On 08/26/16 20:10, Pedro Giffuni wrote: >>> >>> >> ...>> I think we should move forward, just want to make sure it doesn???t >>>> break some arch completely before moving ahead. While lld is a goal, >>>> the goal is also to have a ld.bdf installed for 12, iirc, as a fallback. >>> >>> And very right you are, this has all the chances of breaking MIPS*: >>> >>> "A configure option --enable-relro={yes|no} to decide >>> whether -z relro should be the default behaviour for >>> the linker in ELF based targets. If this configure >>> option is not specified then relro will be enabled >>> automatically for all Linux based targets except FRV, >>> HPPA, IA64 and MIPS." >>> >>> _____ >>> >>> I will update the patch to exclude MIPS (and MIPS64 JIC). >>> >>> Pedro. >>> >>> *https://gcc.gnu.org/ml/gcc/2016-08/msg00134.html >>> >> >> Looking more into this, and the arm report from Mark Millard (thanks!), >> binutils has tests for RELRO in their testsuite that would be an >> important indicator before enabling the option. >> >> It surprises me that we don't have an easy way to run those checks from >> the port, so I borrowed the regression-test mode from GCC and I am >> attaching it. >> >> The tests may depend on some gnu-isms but we don't appear to do too >> well on the tests: >> >> === ld Summary === >> >> # of expected passes 511 >> # of unexpected failures 78 >> # of expected failures 4 >> # of unresolved testcases 35 >> # of untested testcases 1 >> # of unsupported tests 9 >> /usr/ports/devel/binutils/work/binutils-2.27/ld/ld-new 2.27 > > And ? In which way this data is useful or indicative of anything ? This is just informational. According to the GNU ld commit [1], passing the tests is the criteria used to decide whether the RELRO should be enabled on a particular platform. We don't complete all the tests and it appears the tests break before I get to the relro part: ... .PASS: test-strtol-20. gmake[2]: Target 'check-host' not remade because of errors. gmake[1]: *** [Makefile:2204: do-check] Error 2 gmake[1]: Target 'check' not remade because of errors. *** Error code 2 Stop. make: stopped in /usr/ports/devel/binutils > Why this tests are relevant to the proposed change ? I will drop the proposed change. We should evaluate individually each platform before enabling RELRO. At this time I am more worried about the failing tests and our lack of testing of binutils. AFAIK, binutils > tests typically compare ld output against expected binary. > > And, number of the unexpected failures in your showcase is quite worrying. > It is. Having a knob in the port to run the tests seems important. Pedro. [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=647e4d46495f2bfb0950fd1066c8a660173cca40