From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id 4C5CF385828D for ; Tue, 17 Jan 2023 15:56:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4C5CF385828D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x132.google.com with SMTP id br9so12433114lfb.4 for ; Tue, 17 Jan 2023 07:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vMq285xkkH9SAH4lu0lOXQumH7p4YtIx+ituOG2es20=; b=Gz3TEI+wenhE7koWat7IBKKq7cX9sL8822L6F7300qxhXXBhP1zXPCiL9IKXBD1lTP 4VHZnZhS6qKvJ3BLpfgkj7JdoHvavq7GsB2v+P4QTmdI5B5XaFDsdN44xfKZAOWGAu9a Y6tlPe4xB7O/xtZPur2gkV9///rR+GYj2XfYiFXr9AG/JqIgi7EqpNBRjwOiC3I3Xvij eganICju3hMJF8BIOBvuyworMMCdhETlq86/wnbwqqZIp3IdotJfte28b8tRjtRm9fSA chn8j4NRRe3z1L/w6GalyQBxVGcYX8ZOjTeJR4AJPj/p0YKqvrULcNBEREpkJoYiojKf TrNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vMq285xkkH9SAH4lu0lOXQumH7p4YtIx+ituOG2es20=; b=Rs+9fPIliQU3MtRgsWdpcY5Q7ej2+3232I/LTUzql4arP3jZERfN3XHGnsNqqKkLZt Q0ROuCtUDlIXU+9S2iEYLvBak0Xr7FsIdC3TGXXcwB3p5HIGSeADxN5cDr+Ejxf5F+FN Xjkert6drQCyxUQzqVSjCtylKwQM/BDVloIbQIiK4SBL4WetfXjYNqKb1Sr7NTSVROrs GiJbWz8Oi1fnqUeVFHiGQjWLgM6RPm6BqcjuxMHx5TUp3Gp3Sktk0wXYQ8jSRHz0sFMz ugkRIBAF7yEkOmalVuV6t/BibEg3UE3S817C/hvTcrH7+hDiBYgC/MdIFRiUH73S3KYJ Fv6g== X-Gm-Message-State: AFqh2kpUSTW6rVUtbW7M9yMbv6ReMFp4iUo0xQ3TZUnIAIAlzkBspJyR U/7DG7g37VjNGab70zLa7B0Q2gn4KhS4hNZTx/0= X-Google-Smtp-Source: AMrXdXv6m1YffEuoSRppB8vr3+zxo9LcB8vpoOCYYxv3CT7Ew0Hfc/VkQ8sZMPqX+a2NwDAFQmjDBUkQQpYMCNNBTmc= X-Received: by 2002:a05:6512:32a6:b0:4cc:9ee7:68b8 with SMTP id q6-20020a05651232a600b004cc9ee768b8mr381531lfe.328.1673970999625; Tue, 17 Jan 2023 07:56:39 -0800 (PST) MIME-Version: 1.0 References: <87zgah7fv1.fsf@oldenburg.str.redhat.com> <6b782360-131f-df4c-9dc4-6765d0fb8c24@linaro.org> <878ri15jqt.fsf@oldenburg.str.redhat.com> In-Reply-To: From: Joel Molin Date: Tue, 17 Jan 2023 07:56:28 -0800 Message-ID: Subject: Re: Why does _dl_protect_relro align the end address down? To: "H.J. Lu" Cc: Adhemerval Zanella Netto , Florian Weimer , Joel Molin via Libc-help Content-Type: multipart/alternative; boundary="000000000000cc0c9205f277be30" X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000cc0c9205f277be30 Content-Type: text/plain; charset="UTF-8" Thanks, I think I understand the challenge. Maybe I should have realized when I saw the external bug I linked. For as much as my opinion is worth, I guess I would also agree that ALIGN_UP on the start would at least be consistent. Coupled with an explanation such as "// Protect pages that are entirely within the relro region. Since the runtime page size can vary, we can not trust linkers to get this right and must be conservative." I would not have sent my email (though I would have continued being sad). Right now it looks like a worst of both worlds scenario. Joel On Tue, Jan 17, 2023 at 7:49 AM H.J. Lu wrote: > On Tue, Jan 17, 2023 at 6:30 AM Adhemerval Zanella Netto > wrote: > > > > > > > > On 17/01/23 11:16, Florian Weimer wrote: > > > * Adhemerval Zanella Netto: > > > > > >> On 17/01/23 04:57, Florian Weimer via Libc-help wrote: > > >>> * Joel Molin via Libc-help: > > >>> > > >>>> Since mprotect will protect entire pages anyway, wouldn't it make a > lot > > >>>> more sense here to say `end = ALIGN_UP(...)`? Apart from feeling > more > > >>>> intuitive, it also seems like it would avoid page size > inconsistencies > > >>>> between runtime and link editing like the one above. > > >>> > > >>> ALIGN_UP might make memory read-only that should not be. > > >>> > > >>> There's some discussion about the alignment here: > > >>> > > >>> PT_GNU_RELRO is somewhat broken > > >>> > > >>> > > >>> I still think this is fairly broken, but there does not seem to be > much > > >>> desire to fix it. > > >> > > >> It was not clear to me from that discussion what you think it is still > > >> broken with PT_GNU_RELRO. > > > > > > Using ALIGN_DOWN for the start address can't be right. > > > > > > > Do we have a bug report for this? Because H.J explanation [1] only > describes > > ld support for the end of the RO segment. > > > > [1] https://sourceware.org/pipermail/libc-alpha/2022-May/138642.html > > If the end of the PT_GNU_RELRO segment isn't page aligned, > ALIGN_UP may change the executable page to read-only. > > -- > H.J. > --000000000000cc0c9205f277be30--