From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2250 invoked by alias); 11 Jun 2018 16:29:34 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 2237 invoked by uid 89); 11 Jun 2018 16:29:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=safer X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qt0-f173.google.com Received: from mail-qt0-f173.google.com (HELO mail-qt0-f173.google.com) (209.85.216.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 Jun 2018 16:29:32 +0000 Received: by mail-qt0-f173.google.com with SMTP id y31-v6so20812601qty.9 for ; Mon, 11 Jun 2018 09:29:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uilBP0HcLjtMU5Jzp3WNfDZL6TouO85D1rR7e4Gwi7g=; b=gkaOO5vNQcM1Wr7ZCJ/oyEoMxIo92G6inoDbVZdtUVA5RHkh/VEYIvQyW7bqvQFuqG Dg7Dk3ZqamY6rKx4U6SkOm+co29lNE9WJXIbie1ty5Q2N4ol3RDww775id86FiYU7zX5 0UAxcZq7t1dN905yix/mD5iab3aMwkyOj2M6t9be9U0wPNWYOfyfvwHWVH2y3VIZgMgS zSwNEL7mlBEhCTbejDbE8njkj2iwQFqBMxVzlOEje7X4Vknat/Z1sziIXPUia0D+A4Oz nqpUpObWE+/kfAPK8oc7NThJtUzSdJgsgEB3YcF/9jfBy3vwjB0zpkarycoveS/dIl03 mtQQ== X-Gm-Message-State: APt69E0P1ZVcYGqnw+fcTVE/IN2pBJdTbzwbomZY95MQnZqNgeaptLhw +eT3ZdaTd69FzI8QX65NvjUHNDLvf9s= X-Google-Smtp-Source: ADUXVKJOyN7BEX3ZqMYir4t+9BiK7zmFxjb2tsDZSuwveynpkQziUtQ7w5KDjktGtfegPtt1lBvdiA== X-Received: by 2002:aed:3bf6:: with SMTP id s51-v6mr17171524qte.186.1528734570214; Mon, 11 Jun 2018 09:29:30 -0700 (PDT) Received: from [192.168.8.100] ([184.151.36.206]) by smtp.gmail.com with ESMTPSA id e97-v6sm3261646qtb.78.2018.06.11.09.29.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 09:29:29 -0700 (PDT) Subject: Re: Flag for late RELRO application To: Florian Weimer , gnu-gabi@sourceware.org References: <0140c64d-ceef-070e-a8f5-95a930984800@redhat.com> From: Carlos O'Donell Message-ID: <7a4054dc-561c-544f-b3d5-4f06580e10dc@redhat.com> Date: Mon, 01 Jan 2018 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <0140c64d-ceef-070e-a8f5-95a930984800@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-q2/txt/msg00001.txt.bz2 On 06/11/2018 07:23 AM, Florian Weimer wrote: > I would like to add a flag to gABI (visible in the dynamic section) > which indicates that the loader shall apply RELRO protection only > after running the ELF constructors from DT_INIT and DT_INIT_ARRAY. I assume that means also after DT_PREINIT_ARRAY? Should the semantics be worded in such a way as to simply say that all constructors have finished running? That could be a lot of code running without RELRO protections. > This would allow applications to allocate a mapping and store a > pointer to it in permanently read-only memory. On the mapping > itself, the application can set the protection flags (and keys) as > needed. Wouldn't it be safer to have some kind of second "type" of RELRO for these particular uses? This way we don't mix what is effectively early RELRO with late RELRO? I know that it's easier to just defer RELRO (all the existing machinery is already in place for it), but I'm wondering if that won't worsen the protection in substantial ways. For example how would an application mark a pointer as read-only but also write to it? If you have to markup existing code with attributes to get this to work, you might as well collect them into a special section and use a 'late RELRO' flag for it, extending the existing RELRO framework. Just a thought. Cheers, Carlos.