From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D02D1C47DAF for ; Mon, 22 Jan 2024 09:48:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A1D36B0071; Mon, 22 Jan 2024 04:48:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 152816B0074; Mon, 22 Jan 2024 04:48:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F34CC6B0082; Mon, 22 Jan 2024 04:48:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id DF4776B0071 for ; Mon, 22 Jan 2024 04:48:29 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 69CAA1A049C for ; Mon, 22 Jan 2024 09:48:29 +0000 (UTC) X-FDA: 81706471938.22.3D6B8B5 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 7921A4000B for ; Mon, 22 Jan 2024 09:48:27 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GIGJoAB3; spf=pass (imf11.hostedemail.com: domain of fweimer@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705916907; a=rsa-sha256; cv=none; b=QXQkt89KGoBs4PsV3+HffXy8UZT9qT+hu1/heGBqrRyjM7KDSNoz6cOVq/8EO20di6H6QT BluHbeVbo4hQK7ZKYPVdHxsfTrB3mObsA2wX7UKufIvZI8QXLWe+KMpsaRVEfhBoR2SP3E M2hAVgLeIqmIiprf2TSZ9x7zGS92KLI= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GIGJoAB3; spf=pass (imf11.hostedemail.com: domain of fweimer@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705916907; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7cBs2U0i3D9w9WV8+Pf0nrRzJpAUSveYB1qTpJzpZyk=; b=4pw3gLzj44zZ9tz5fuIE2gRreOEPXhUK7NUMnNPvseCHUlc+OWDOQNeS/+oW4LhNVNuiY2 xgUnsh2Hl3Sr9aerOP3DNOF/xkms9nKCqFTh4Io3Uc6ByC3bBQLGGC4s+VrmKk1WxaKSiI NTGsOQ/nWH6jVc7pq7hN30i/r2XjOrU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1705916906; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7cBs2U0i3D9w9WV8+Pf0nrRzJpAUSveYB1qTpJzpZyk=; b=GIGJoAB3VtBHR7RCkLUBqq9I/y2qacR+/NEotuakrPQ582q3PK9EWdwWiKylReYxDyT0+h ki+4QKBZwW7qeRG7UDFX879nsnLi3Ooc6cPO66pXNwuknUIhYwUvv09s681h/ucDgY5/7U i4pzguGV+XvfEkCXPIDgznA0b+AYFJY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-80-5xGE6WBKMtuBIw6lc2QEbw-1; Mon, 22 Jan 2024 04:48:22 -0500 X-MC-Unique: 5xGE6WBKMtuBIw6lc2QEbw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5E48F88F5A6; Mon, 22 Jan 2024 09:48:21 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.6]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AD3D8111E408; Mon, 22 Jan 2024 09:48:19 +0000 (UTC) From: Florian Weimer To: Matthew Wilcox Cc: mail@horotw.com, linux-hardening@vger.kernel.org, Jakub Wilk , Salvatore Bonaccorso , Linux Memory Management List , William Kucharski Subject: Re: Limited/Broken functionality of ASLR for Libs >= 2MB References: <69fa6015256613ed10aee996e181ebd4@horotw.com> <87il3ur1ik.fsf@gentoo.org> <07c348caaf6b4c457ab4b452f53ed048@horotw.com> Date: Mon, 22 Jan 2024 10:48:17 +0100 In-Reply-To: (Matthew Wilcox's message of "Mon, 15 Jan 2024 20:46:34 +0000") Message-ID: <87ede9pula.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 7921A4000B X-Stat-Signature: 1xgfohsejxauo8ap6u887otj46gm5km4 X-Rspam-User: X-HE-Tag: 1705916907-240372 X-HE-Meta: U2FsdGVkX1+SRqKPXiQfE0wbzlg2bkmXhGew4v9LGIY5b6zFYzdZft6OqKnle/M0p+OPgX2mj9ml095QTY7p+Nf0+3WdWOWLhL/lMHLKirJba9clqWeV35i/W4HbgCOPb/rJZcct+h7/X/+EQr3lYhcN/l1MN4aswENIjDnLPyQ1e9OQPKbvFygq/yUB0Q9uLZTnrnJRl9rYxgoUmRaguVE+H9BPhxjySnQX9qXOpXW+9CMgpduBO9gdV2FMlzSijNEZeNcASqYdALKRxvYOuYFkdmaDs1cXPKOtdPMAcYOrBlphpZmio/Gt0WDMTWgup69OAaIqEaXGZYkbn7Evtcjh2uzakBr5yl1RTXsqY8r/13dNp87pSgT6djD51gMYtNdnFxtZarfdPBSFr+8+qASwQZO3WJpXpsmmpGYH3ankgocAI2NqEX/ATkkWWVhfkJCIW9JaFsVq9yjdCKK41+QMReugOsl84yIMgPS+byei8F7969QKIPMJiII7BeAcDwFmA8zGqK+2FXZ8aY8Zp/ZHKdQwcvF4UPUqkJPHdmluTb82oZZGLYq8es0kXmJJmAEfIkNhT1jVDruLFJ1Pwc0Jq+WGqBHRT6TAcNL1RR5QJoE87lL8oFUaXf2iV/vqHmqXKjNL6vn58cOUA/qW3MzJNKhZNy8PEDIuknzZihE0yvQuZ7uMH31bwnWlks+8nvoalbM+nE/uoBv2OIH1Q3QTTrS/+5NuQEGtP/6WriYL9yJAU8MNkSnc68lH3KMhXyRsMoijhKU+/bGTzPN8f4tVdcLCIk30b62snRLW83RMacncEVp6G0PuCF8fiK/FykEGGDGOL8veU1KZUvaqgQNhpxGFaCs3Y0nfSxQoy8ePlT/6rHsmtAXhK8hBpCn6s9DACBwxzKiDpazhdKCCsvqG0/+KjBBrUF7XTqDLlqC2l3LMBkwYX2IEROKbteir0aCh0oijaMJUMXydjLM bpvP/0DE EQYNSbUTz++tnJvRCJbrr5GNff2QmQjn2pZW99wpW8GXQCgz/P8mtkXadCjyGT5366q/HNXsjTDVd+dPeaPueGo+y/hm2p1sdbNXVvCFXnBtrYCM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: * Matthew Wilcox: > I received a suggestion off-list that we only do the PMD alignment on > 64-bit, which seems quite reasonable to me. After all, I don't care > about performance on 32-bit just as much as I don't care about security > on 32-bit. Perhaps we can we repurpose MAP_DENYWRITE to disable this? For shared objects as loaded by a dynamic linker, the alignment is pointless in many cases even if the original mapping is quite a bit larger than 2 MiB because the individual LOAD segments and their protection settings are smaller than 2 MiB, so hugepages cannot be used in the end after all. The dynamic linker knows the LOAD segments, so it can drop MAP_DENYWRITE if it determines that hugepages could be beneficial. (Current glibc sets MAP_DENYWRITE for historic reasons.) On the other hand, I wouldn't object to more explicit control over mmap pointer alignment, either, for anonymous mappings as well. There are some binutils versions that produce 2 MiB aligned file layout on x86-64, but that change was reverted, presumably because kernel hugepage support for non-anonymous memory wasn't available. But there are likely some iffy details that make these binaries unusable for hugepages in practice, like lack of hugepage alignment at the end of LOAD segments. Unfortunately, BFD ld tends to produce approximate PT_LOAD and PT_GNU_RELRO and relies on the dynamic loader to round things up and down in somewhat questionable ways. Thanks, Florian