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