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 D8DD4C47258 for ; Tue, 23 Jan 2024 22:35:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 04ECD6B0071; Tue, 23 Jan 2024 17:35:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F41876B0078; Tue, 23 Jan 2024 17:35:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E088F6B007B; Tue, 23 Jan 2024 17:35:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id CEE3D6B0071 for ; Tue, 23 Jan 2024 17:35:18 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8EC2A14010F for ; Tue, 23 Jan 2024 22:35:18 +0000 (UTC) X-FDA: 81712033116.06.C597ED3 Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by imf14.hostedemail.com (Postfix) with ESMTP id BF209100018 for ; Tue, 23 Jan 2024 22:35:16 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=g5H9PLEa; spf=pass (imf14.hostedemail.com: domain of keescook@chromium.org designates 209.85.167.169 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706049316; 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=c6AnvGe+nDcHjURBPGcdHvtcORYZs9pMI2C+Mc0vQNM=; b=m7spO98y8NbMZ4KId3OpHC4nNVHkzn3/3ZxeBCMXuajIeHBXi6pJHn2VxOmX7alKK6Qgt/ tN1AVSjzqid7IaHI7su0LV1pJkge8D11+FsZvHNAhqWS4fzhXo47RByo+Q8hIRwn56s/wQ hcz6flUdlWg1dHZ8RFtDiMQO4ue5LH0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706049316; a=rsa-sha256; cv=none; b=lJ7scOqhIq7Qv9GzGyBWzlYcdqBk33CQ/ZvQXItw457zoGmZFSXepqlQZV6RZw39cOADh9 4DQfYfqGEf38Ii3FE4xVP5A0R14Sv2/iYN6hBoA8fsM02W4CPHXnlvIA4/DRT2o7MJcs2Q v3hUIpPYSMd19Ut9k/mKhKN1uu8+Wqo= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=g5H9PLEa; spf=pass (imf14.hostedemail.com: domain of keescook@chromium.org designates 209.85.167.169 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-oi1-f169.google.com with SMTP id 5614622812f47-3bda4bd14e2so3762460b6e.2 for ; Tue, 23 Jan 2024 14:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706049316; x=1706654116; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=c6AnvGe+nDcHjURBPGcdHvtcORYZs9pMI2C+Mc0vQNM=; b=g5H9PLEaGwFFffPCOHTMc9YA2RB+Pf8vcfN+pyiK52r1wXbDn82WM4PTNzz05Go11i PPMGF3bNTNDeFjZaiqlToNvtSoli9QMbPoTeQ+aN2pPdTq1ECAZCKDqOSJAGmOUTjA8j 0st8x9CzvA+DXfbTP1n7tjCDdH+NYqiXQAIJI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706049316; x=1706654116; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=c6AnvGe+nDcHjURBPGcdHvtcORYZs9pMI2C+Mc0vQNM=; b=tLBtn3twnCBH14GhoSSaNJtBBmQ33uIFjlF5UgTTIs3xnJaAjjDxM3gvKK1C/5zzQM WwvLU/3L6FPNxPKPhjMNSJ1KYezkk50nQxOK7GECeC05Gi78sKb7Fwua2f1qlzHb278B Zo3XpzzBB4DAijzedz6yJqByHZUw4In2J1GzlKRo2OID5AjUhSGRGE10rkkiBfaS0Qz5 bn5q3is+uLWB+pk0/sei59Bja9ZQq5JcZkoXqFrZI8i47F9tqmSfyBp9MvbXBO77Fw61 +rA2rNaIqzjsi3Pi5gXRKroxxCq7RTuQ62Vh8K4vjYAzR6WunlmeyPCHEzCVHdy13xnN 1DUA== X-Gm-Message-State: AOJu0YzECVut5OTIVtL+Stji6GBQRHka5w11aHh532okaVQCWq6t2D02 qDKo7/BUBG1BjbO/pztm0qtA6u5w90scieK9Auf++8bIbYYidBgoijnLkrnv6g== X-Google-Smtp-Source: AGHT+IH6Wm9LU//CqVYjGKX/7agKx4Kncxxv9iSw1pxwiuakH0Ny/I7WoORPxMG+l0RwGcmkYq8/tg== X-Received: by 2002:a05:6808:1450:b0:3bd:b8d0:99e7 with SMTP id x16-20020a056808145000b003bdb8d099e7mr759504oiv.1.1706049315889; Tue, 23 Jan 2024 14:35:15 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id b20-20020aa78114000000b006dbd787aa8csm5484970pfi.67.2024.01.23.14.35.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jan 2024 14:35:15 -0800 (PST) Date: Tue, 23 Jan 2024 14:35:14 -0800 From: Kees Cook To: Ard Biesheuvel Cc: Matthew Wilcox , Linux ARM , 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 Message-ID: <202401231433.FB2D7FBD@keescook> References: <69fa6015256613ed10aee996e181ebd4@horotw.com> <87il3ur1ik.fsf@gentoo.org> <07c348caaf6b4c457ab4b452f53ed048@horotw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: on8cb761tnckomcjy6984rda3iidxqhj X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: BF209100018 X-Rspam-User: X-HE-Tag: 1706049316-816364 X-HE-Meta: U2FsdGVkX18S5i63t9z3XPdEOQ/TJbFhPRPV81TI0fBmJYJqeLh7i+S5nQSGrqmF/JE+wqo029QSw9JS8qfZO0Cp548Zk8Ujin5CmWB7QO0NLry+0mGUNf8DWXkUDxVjdgeU+de8ZEY0a59+Y/lQQDIrJc3lvqt0H1c6fEUlR90GkGS5Q7mY8v/cmKCTGYRma0HsWbLkPTJ+uAIVlOnF+tm1tEZj1oufuvgX5L7ym6fRMjqOV9z89APVdOxaRcacPPGQmq6bsIgImi6I5Uc7ONjFCrycHCMWFbFIfCGRpNH/ruuZip2Mda9Cq4fBYkNGGDNcg78dfZxA6z7HCRPFevCQQ6WZpkE8AgcaFBIRB5ZW7oRhTvBDU1frKdLNdgtT54UgX23CTENMdAyIHm/bT2Eex9Eg5vMQyB70qpblQ7y8piZMc0fMGOHF9dl0af40wTTXxYckKuHovF2oU4Cdl7zCxaHMshD5TPaCUoOwm88fZE4vxCWwbJWHSv9XUHEgShhsMJuyvxmPnvUJV+DnTDhEfNc1ASZZV7MHUm5YXygaRwFwA1+stePhNvcuYrPYUxagOV3ptprx5xA6DxmQ926+8+UY7YUNoufUMwu8+r0CWC4duA93zFL0BmeGJM6Xk+aCNfJldy8MX4sWZraMw6G4EtrLQvt1WNf7F1Y1OxEla+OdZMIXGI/D3AymMC1B6QoYvr+XA+UwadDQw2FAPG6CwAviJw3785DYWC2uUBU7DSKTiwg/+C/aD2Csb2ueH5SEr//Q0+rfoedZhwhlW635OsLDvvp1BGwI6ceebskFvEstaKL67FF84vjijQAyzkgGagOAix7corUJecRvoudL+bza7uj2GpsX69XGsnwe1xNQ8aMCCSjNoxxAfsZJxmD7M/NMIyLeWncTbhDDF9VKfnd4oCMJEX9Y1JceLhsBDhehLzW/bkBHRtIUil9WiBWpfKQbHcNZpVx7ZEK lxN3DeTe PUaziWsQt5DoKgF5PDVliKj0MRsWX8FFM6VOHhvQWanlaZ7ljDpfLwhRaX6RukNr7ZRk0A79IPSWmcSrmfF7zE6GRbjtIXFFXvimsstB8oBZzXt0xQA8BFWd5aaCmwWwS+A0/yRcFKa9vMf3ym1VztT9AZ/DUnjelf9Y2lKZysTWUAYGoHXJ0yS7AzwhD9fnySBBlFdfqNRGtViTEOT2ZA6CDKKhQkQfl1eqb65PyX5NQeu2wQ4FzIYXpIuLY5a/WSIS4xPOelrXkLk7d4zWqqpzFe1DeqPf1DZ1I7Tt7CXNkPdJ51M2jmqbfr8ax1pFnkT2jMy9oZUwcqoRWo23fSJknsfHnC5/OqhCEbDaMmFKUIJ/we8i0lC3Ekvk1XuFCInUNBEbKyjh++Z9RRD4eNGsPDErmnhGE84iL5IVSe8SVl8Z9tA7g7KYBk9Q8wSc7CtWnfZ8tiEiUD2zauGY635ZZi9UiP6w+BlCLpYahIzLllx4rxkL8xrlcjIQg1m7lO7hbFBZJC9NtGY5xCbBNN6JeDSGZ8Z88yOFJsLu1OVqLkMQbNO+ZXCRvtcOXhehkUInPSgWQvAvdFe9ODGbB/p+cPbczZvjR3UTmrGabVG3+A8Q= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000037, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jan 16, 2024 at 09:09:45AM +0100, Ard Biesheuvel wrote: > (cc Kees, LAKML) > > https://lkml.kernel.org/r/69fa6015256613ed10aee996e181ebd4%40horotw.com > > On Mon, 15 Jan 2024 at 21:46, Matthew Wilcox wrote: > > > ... > > Yeah, I don't know either. Outside my scope of expertise. > > > > 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. > > > > For context, the culprit is > > commit 1854bc6e2420472676c5c90d3d6b15f6cd640e40 > Author: William Kucharski > Date: Sun Sep 22 08:43:15 2019 -0400 > > mm/readahead: Align file mappings for non-DAX > > When we have the opportunity to use PMDs to map a file, we want to follow > the same rules as DAX. > > Signed-off-by: William Kucharski > Signed-off-by: Matthew Wilcox (Oracle) > > which affects *all* 32-bit architectures not just i686. 32-bit ARM > user space is still being deployed widely, even on arm64 Chromebooks > running 64-bit kernels (at least up until recently) so unfortunately, > we're not quite at the point yet where we can just let it rot. Is this related at all to this thread as well? https://lore.kernel.org/lkml/20220809142457.4751229f@imladris.surriel.com/ Can we avoid this on 32-bit or at least not mislead userspace about the available entropy visible in /proc/sys/vm/mmap_rnd*_bits ? -Kees -- Kees Cook