From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 8DE74385840A for ; Mon, 14 Feb 2022 02:18:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8DE74385840A Received: by mail-pl1-x634.google.com with SMTP id u12so9381708plf.13 for ; Sun, 13 Feb 2022 18:18:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+jqswFdn4RcdUrk5vdPj0Pc8FUnfzgrDVcn4zq5rxrY=; b=yrR5axedXvGQgh55hH6qNahrTo6Cn+cN0Mn+rDjsw9itkJPsqPQrcxcLDD7uxp9M3Q WhvN6flk/26io9IRK8tQzHFHY5qw0hJF0aiIV81WVMsHP+2+KWJkLX+hzDcn8wT7XZIP npPdYTX8F0Wu0UzzSaUM4heBUTjMCx6k/HHfFoNVK3hhJd2kd2qNkAdA0koTpWqrjXxA GI606kKxWv4K7t3SmOS65xN/pb+UY+QWdGaFgU4OKgoliZQkz1RjCJl5pnei4zKmdqRM h+5CXePlMjT88E+0sv1jUC8HOYsq8hDnghOS/Gr3+xRWkzGXaXYxHz2hJT89GTRN8GwU NOqg== X-Gm-Message-State: AOAM532e6V4k7k6ppoT/QXcobOEF8o/MiivdAW7p4JXJZyYyV0ePYP2c 1B0ut/xgtiU49ECaNT3Kr1Q= X-Google-Smtp-Source: ABdhPJzsFTzesAgjTdjNDeHTneR2GXQ4KvKU3m14sGo9QAXzk63gRBU6rUw+h1bSUubC9VjwBYSnUg== X-Received: by 2002:a17:902:f54d:: with SMTP id h13mr6493742plf.5.1644805096693; Sun, 13 Feb 2022 18:18:16 -0800 (PST) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id o1sm4051765pgv.47.2022.02.13.18.18.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Feb 2022 18:18:16 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 123041140133; Mon, 14 Feb 2022 12:48:12 +1030 (ACDT) Date: Mon, 14 Feb 2022 12:48:12 +1030 From: Alan Modra To: binutils@sourceware.org Subject: Re: [PATCH 2/4] PR28824, relro security issues, x86 keep COMMONPAGESIZE relro Message-ID: References: <20220208010833.2103874-1-amodra@gmail.com> <20220208010833.2103874-3-amodra@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220208010833.2103874-3-amodra@gmail.com> X-Spam-Status: No, score=-3031.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 02:18:19 -0000 On Tue, Feb 08, 2022 at 11:38:31AM +1030, Alan Modra wrote: > x86 treats MAXPAGESIZE as a memory optimisation parameter, actual > hardware paging is always COMMPAGESIZE of 4k. Use COMMONPAGESIZE for > the end of the relro segment alignment. HJ, you may like to revert this patch and make x86 also align the end of the relro segment to MAXPAGESIZE. That's why I extracted this part into a separate patch. I'm not anywhere near 100% sure about my claim that x86 always uses (or can use) 4k hardware memory pages. -- Alan Modra Australia Development Lab, IBM