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 E34A7C4725D for ; Thu, 18 Jan 2024 02:10:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 087CC6B007E; Wed, 17 Jan 2024 21:10:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 037836B0080; Wed, 17 Jan 2024 21:10:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E41136B0081; Wed, 17 Jan 2024 21:10:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D1B746B007E for ; Wed, 17 Jan 2024 21:10:31 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A172AC03ED for ; Thu, 18 Jan 2024 02:10:31 +0000 (UTC) X-FDA: 81690802662.02.6D731B0 Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) by imf27.hostedemail.com (Postfix) with ESMTP id DC2174000D for ; Thu, 18 Jan 2024 02:10:29 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=u89pBFHo; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705543829; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xyBr76gK/Clq6PkTT3F/dpMJAQNA2rfRDAOiFvk9ZXo=; b=HDq/F3ysdRYCvFxVFxkrHzd/75ic/jzWgaOlnE70dzI2nCr9sc9dLE63iHfCa2ER5+T9hy eDbyZ2/PTGneT2utgsUXePPvvPFBAj3vAdtGcXZ9n52uT/hje1LmGbpTiQfKRRANdDsMma 4FJA3qKho8KtiZ1fPvICdK3eK81+6lo= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=u89pBFHo; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705543829; a=rsa-sha256; cv=none; b=sMnKDid/5XXITPPYAfQidbjGCJUeG1RrMY7lsiNSlqREePspgt6SEsYDqOkiNPGygYGVL2 YOt4QeHeO0scwApW09ZO9uyiWBaX7i/1mvIoMYCYuxRQJfrHQ2G8yVHo/RbP44M95GF+p8 NHO5Nbi+RzkoayH6thSHy3QF22roryI= Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-5fa4b03f3f5so84677627b3.1 for ; Wed, 17 Jan 2024 18:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705543829; x=1706148629; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xyBr76gK/Clq6PkTT3F/dpMJAQNA2rfRDAOiFvk9ZXo=; b=u89pBFHoorqE4ZyeZ0UNxLPw1pLAcA01u+UEKAZQDpwptJ1XJEpK8cdxJ5mq0ChaT8 6HAYoC6rGZGUmPvofd9jRmSNvC7nqczEzZUHlVj6K6AvoCpknnPK43P+uS8k2LYXOehC Vy70smbMELoCAjF3B8gQ/7MqenD6L32HECiGyhfqcI58if99Qsk4vxDrYULXYzx9JM/3 Ogd1lKYfFAxLlCa4hjk0bVAIKiK2f9qf1hbqznGtNTi1eGR/xPaQ5YXuckk8SvIW6Cfg v0HrObqP6cqUp0/USypuxDQ9lZrvUii9Z8L1KutfBpGy+9o7B1X8Sj65owNMGJ0CxBjK 3dVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705543829; x=1706148629; h=content-transfer-encoding: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=xyBr76gK/Clq6PkTT3F/dpMJAQNA2rfRDAOiFvk9ZXo=; b=JXA2mZROJPSZSiaTihUXu7lINvi38JflftyQUgUDkrDwiYVcv7zIDAAM1PdWOM/xTE bXMMIeBpWNJU6clP5V31gAOCnhRFVmG4RAHT03xfIGaDnaSOx1zETsykqR68HZ4m+Jty UyTNRtWsBkp78ZHETVekuhlf2DcxznNKsACAe9o8+B1J3AOd6huag2uWDtXgCrMW3rub VYKTUAa8mM1UykRJ9H2ewh8tgBJTH0K+HAevD2ma1PSPedqDOCru6uPvb12m/xAzX9vw gg9pxgelYrn4bO3Dn+tGjvCwBYoUkUnDjoAsGwDFE2Iv/UGetEjlw+mUku/AGRflrk7W 7ZqQ== X-Gm-Message-State: AOJu0YzB+CNSoqup9oRyUhelmQVxEPXR5mFgY+DLTTFpkBZS5dYwdBM/ K70GKwMWi3l9JweSwy/Kl4SADgx0vnqwlF3prvDNwZ5lN8/V+ShcwUHOyHHYnhqisqdjTmrPL5A 2Gwd6/x3Ok+A6yvjnDlQPSd00HGlAf5i1/w1I X-Google-Smtp-Source: AGHT+IGdVeN6j6qHtHoIAhsTeueIVNsOEyoxCokeRtPUsHUhApyrNFi9AfYo45DYrqk7QnHDA5Dvu4wYaa2Md2U4GPw= X-Received: by 2002:a81:8584:0:b0:5ff:5dcf:44a5 with SMTP id v126-20020a818584000000b005ff5dcf44a5mr115505ywf.86.1705543828746; Wed, 17 Jan 2024 18:10:28 -0800 (PST) MIME-Version: 1.0 References: <20220809142457.4751229f@imladris.surriel.com> <3193bf5b-4e22-412f-8c5b-68574942d9bc@kernel.org> <202401170925.015D300A@keescook> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 17 Jan 2024 18:10:16 -0800 Message-ID: Subject: Re: [PATCH v2] mm: align larger anonymous mappings on THP boundaries To: Yang Shi Cc: Kees Cook , Jeffrey Vander Stoep , Jiri Slaby , Rik van Riel , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Matthew Wilcox , Christoph Lameter , linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: DC2174000D X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: n1se3i3u1ihscu8pg9ax3k698455w56g X-HE-Tag: 1705543829-797094 X-HE-Meta: U2FsdGVkX19xazw842N6hWtBn5paOJz+tXvGNWsGm7yjIE0FZ/1VOd+giGQx7rVp2tLxBwYuicxeGCc4ik6LDLZS9Ohdvscz1wQw72Bpij6px/68U78OIdUv2MH0Rh5b8rl96DmTh3ZbXpOpkmXlEwEBGEiIuNt04jxPFBjVXnW82Ik9WwNnS+elaFpfA0FPTWMPPqLhMbDrkfLpmNTh6ubhbTPDd331oILuV3hTgJymvUuqstVilG1QCLmJsr+SDbUwA5pmymDMCy74YJzaxbh0sGMF2vaigRxWIM46Q0ZY0hAtvvJ2w9SqBzZzxDkDrX87GBKPc5HGAHwjmMGqs9KfSk+Vt0K+tlDGbLoTdvzUjbYvDEycdeFGiFw8ZWxG1Jm6L1xMzCdfnDYZkeyguZaa5zSa/dNu+DNit4VSOtLWR168UfTEsOkPryuPqh2JiMlM8MxaV2ovm2Qd+78oIUWbwAP3HMXSa5lCuQa9JxHd27pa/J+eo2qdjHwj2nLqD4bYp6psTGXkBxWfxq08r7Sh5kOiWkpzweZ/jhyvLrhZ+IWTePXXIVVD5cZbIzRVi+PXPOUyggLDxE45Oc5M8/4LGgT0ZooilJ4C8nj8T+TpA9+69UWtO4lgzHBSm7ES3C0zmJRM+e2d76AHrFfEHSHbYGCV/gUa+MVTKzWH+cOZf3vf7HH6+d0LsKBQE9NNEG8qv6Aqdzi0zK/DS1Luvn1PmYF39wFZM3PSU2uvFTcTpQc/QosgieG8V/YFHzW60m/tz31KYkdNPpeSOe3sX++vf+n+oRH926i1nviVPoAPc2Gqa0yEUmR8rjREvTb8/TLCW4TdQo0OnXfH91paLwRET5H07JsRMSjMmTn4/t2t41oSF1er9KlhELaYDY154ykCWbm2nPa4lpTpWPyBNLJ+j3MAsTJSTjzf742K4088rfBZUiCznrNj8u5OAHmLxfnn/BW/fGN0hYgFDlb 1muR45vg K5yR7QLRAa+c+QloeuVmx5qsiZgh1cFiSTbKe1pBjPOxkGv7p78l8KsZ2g8EiryTtPXbhu+eFQX8l3GxEZz0JZLqcfFH9Haz9KJzzsEjSlPlTQ4SKhjdDRkzmE5zhSE8Qer5rkGuTnLTqZuhFUSPgivow7vRQOdXyvMqW17gQiZMfDPZfnASxWNgg1Sl34S9v8wSd7stuuADuthHQDSZDQUKlfHVZ2LwRxY6swZnsMOevEtCeWmKlfIlTfcFGaL8bZVYp82xjwOlhrdiWGco4h06U0XWAozvQlxd2Cx6ESUJNNA5moC2oALJfexFw7XbTcrpuJHxXlH93rPqTAOFANuKg1oVkpQIsvdshJWYg0oFuaCnfpSinnjeBh+hCiLItfomIZj0UYfEdO/MC8/H5Zr2zzkhdHbbWLQnBbBMrewfrH1ldHElgOzJ9LnTT1LdwX+jMAWD32MaYHlRX1FU+eTxJHYC03anOstGxO6E3LWy2mQF/8aC575yIb3QWvIV0Mofwf94nR9NiC8nKfPWkPc91XP6bKh5zgcXcJ721Orj5Oban3YfL03sJHcZThZE8cB9hqu/kGXBT2O2qanPgB1NRQA== 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: On Wed, Jan 17, 2024 at 5:34=E2=80=AFPM Suren Baghdasaryan wrote: > > On Wed, Jan 17, 2024 at 4:29=E2=80=AFPM Suren Baghdasaryan wrote: > > > > On Wed, Jan 17, 2024 at 4:13=E2=80=AFPM Yang Shi = wrote: > > > > > > On Wed, Jan 17, 2024 at 4:02=E2=80=AFPM Suren Baghdasaryan wrote: > > > > > > > > On Wed, Jan 17, 2024 at 3:32=E2=80=AFPM Yang Shi wrote: > > > > > > > > > > On Wed, Jan 17, 2024 at 9:40=E2=80=AFAM Kees Cook wrote: > > > > > > > > > > > > On Tue, Jan 16, 2024 at 02:30:36PM -0800, Suren Baghdasaryan wr= ote: > > > > > > > On Tue, Jan 16, 2024 at 2:25=E2=80=AFPM Yang Shi wrote: > > > > > > > > > > > > > > > > On Tue, Jan 16, 2024 at 1:58=E2=80=AFPM Suren Baghdasaryan = wrote: > > > > > > > > > > > > > > > > > > On Tue, Jan 16, 2024 at 12:56=E2=80=AFPM Yang Shi wrote: > > > > > > > > > > > > > > > > > > > > On Tue, Jan 16, 2024 at 11:16=E2=80=AFAM Suren Baghdasa= ryan wrote: > > > > > > > > > > > > > > > > > > > > > > On Tue, Jan 16, 2024 at 4:09=E2=80=AFAM Jiri Slaby wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 16. 01. 24, 12:53, Jiri Slaby wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > On 09. 08. 22, 20:24, Rik van Riel wrote: > > > > > > > > > > > > >> Align larger anonymous memory mappings on THP bo= undaries by > > > > > > > > > > > > >> going through thp_get_unmapped_area if THPs are = enabled for > > > > > > > > > > > > >> the current process. > > > > > > > > > > > > >> > > > > > > > > > > > > >> With this patch, larger anonymous mappings are n= ow THP aligned. > > > > > > > > > > > > >> When a malloc library allocates a 2MB or larger = arena, that > > > > > > > > > > > > >> arena can now be mapped with THPs right from the= start, which > > > > > > > > > > > > >> can result in better TLB hit rates and execution= time. > > > > > > > > > > > > > > > > > > > > > > > > > > This appears to break 32bit processes on x86_64 (= at least). In > > > > > > > > > > > > > particular, 32bit kernel or firefox builds in our= build system. > > > > > > > > > > > > > > > > > > > > > > > > > > Reverting this on top of 6.7 makes it work again. > > > > > > > > > > > > > > > > > > > > > > > > > > Downstream report: > > > > > > > > > > > > > https://bugzilla.suse.com/show_bug.cgi?id=3D121= 8841 > > > > > > > > > > > > > > > > > > > > > > > > > > So running: > > > > > > > > > > > > > pahole -J --btf_gen_floats -j --lang_exclude=3Dru= st > > > > > > > > > > > > > --skip_encoding_btf_inconsistent_proto --btf_gen_= optimized .tmp_vmlinux.btf > > > > > > > > > > > > > > > > > > > > > > > > > > crashes or errors out with some random errors: > > > > > > > > > > > > > [182671] STRUCT idr's field 'idr_next' offset=3D1= 28 bit_size=3D0 type=3D181346 > > > > > > > > > > > > > Error emitting field > > > > > > > > > > > > > > > > > > > > > > > > > > strace shows mmap() fails with ENOMEM right befor= e the errors: > > > > > > > > > > > > > 1223 mmap2(NULL, 5783552, PROT_READ|PROT_WRITE, > > > > > > > > > > > > > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 > > > > > > > > > > > > > ... > > > > > > > > > > > > > 1223 <... mmap2 resumed>) =3D -1 EN= OMEM (Cannot allocate > > > > > > > > > > > > > memory) > > > > > > > > > > > > > > > > > > > > > > > > > > Note the .tmp_vmlinux.btf above can be arbitrary,= but likely large > > > > > > > > > > > > > enough. For reference, one is available at: > > > > > > > > > > > > > https://decibel.fi.muni.cz/~xslaby/n/btf > > > > > > > > > > > > > > > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > > > > > > > > > This works around the problem, of course (but is a = band-aid, not a fix): > > > > > > > > > > > > > > > > > > > > > > > > --- a/mm/mmap.c > > > > > > > > > > > > +++ b/mm/mmap.c > > > > > > > > > > > > @@ -1829,7 +1829,7 @@ get_unmapped_area(struct file= *file, unsigned long > > > > > > > > > > > > addr, unsigned long len, > > > > > > > > > > > > */ > > > > > > > > > > > > pgoff =3D 0; > > > > > > > > > > > > get_area =3D shmem_get_unmapped_ar= ea; > > > > > > > > > > > > - } else if (IS_ENABLED(CONFIG_TRANSPARENT_HU= GEPAGE)) { > > > > > > > > > > > > + } else if (IS_ENABLED(CONFIG_TRANSPARENT_HU= GEPAGE) && > > > > > > > > > > > > !in_32bit_syscall()) { > > > > > > > > > > > > /* Ensures that larger anonymous m= appings are THP > > > > > > > > > > > > aligned. */ > > > > > > > > > > > > get_area =3D thp_get_unmapped_area= ; > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > thp_get_unmapped_area() does not take care of the l= egacy stuff... > > > > > > > > > > > > > > > > > > > > > > This change also affects the entropy of allocations. = With this patch > > > > > > > > > > > Android test [1] started failing and it requires only= 8 bits of > > > > > > > > > > > entropy. The feedback from our security team: > > > > > > > > > > > > > > > > > > > > > > 8 bits of entropy is already embarrassingly low, but = was necessary for > > > > > > > > > > > 32 bit ARM targets with low RAM at the time. It's def= initely not > > > > > > > > > > > acceptable for 64 bit targets. > > > > > > > > > > > > > > > > > > > > Thanks for the report. Is it 32 bit only or 64 bit is a= lso impacted? > > > > > > > > > > If I understand the code correctly, it expects the addr= ess allocated > > > > > > > > > > by malloc() is kind of randomized, right? > > > > > > > > > > > > > > > > > > Yes, correct, the test expects a certain level of address= randomization. > > > > > > > > > The test failure was reported while running kernel_virt_x= 86_64 target > > > > > > > > > (Android emulator on x86), so it does impact 64bit target= s. > > > > > > > > > > > > > > > > IIUC this breaks the "expectation" for randomized addresses= returned > > > > > > > > by malloc(), but it doesn't break any real Android applicat= ion, right? > > > > > > > > So this is a security concern instead of a real regression. > > > > > > > > > > > > > > How is making a system move vulnerabile not a real regression= ? > > > > > > > > > > > > > > > > > > > > > > > I think we can make this opt-in with a knob. Anyone who out= weighs > > > > > > > > security could opt this feature out. However I'm wondering = whether > > > > > > > > Android should implement a general address randomization me= chanism > > > > > > > > instead of depending on "luck" if you do care about it. > > > > > > > > > > > > > > This is not depending on luck. This is checking for possible > > > > > > > vulnerabilities in the system. > > > > > > > I admit I'm not a security expert, so I'm looping in Jeff and= Kees to chime in. > > > > > > > > > > > > Hi! > > > > > > > > > > > > Just to chime in, but reduction in ASLR entropy is absolutely a > > > > > > regression. This is userspace visible (via /proc/sys/kernel/ran= domize_va_space, > > > > > > /proc/sys/vm/mmap_rnd*_bits) with expectations that it work as > > > > > > advertised. So, while 32-bit might be already ASLR-weak, we don= 't want > > > > > > to make things super bad nor break ASLR in compat mode under 64= -bit > > > > > > systems. > > > > > > > > > > > > Having an opt-in sounds reasonable, but we need to wire it to t= he ASLR > > > > > > sysctls in some way so nothing lying about the ASLR entropy. > > > > > > > > > > Thanks for the explanation. IIUC the randomiza_va_space and > > > > > mmap_rnd_bits randomize the mmap_base and start_brk for each exec= () > > > > > call. So the heap allocation is randomized. But it seems the form= ula > > > > > doesn't take into account huge page. ARM64 adjusts the mmap_rnd_b= its > > > > > based on page size. > > > > > > > > > > I did a simple test, which conceptually does: > > > > > 1. call mmap to allocate 8M heap > > > > > 2. print out the allocated address > > > > > 3. run the program 1000 times (launch/exit/re-launch) > > > > > 4. check how many unique addresses > > > > > > > > > > With the default config on my arm64 VM (mmap_rnd_bits is 18), I s= aw > > > > > 134 unique addresses. Without the patch, I saw 945 unique address= es. > > > > > So I think the test could replicate what your test does. > > > > > > > > > > When I increased the mmap_rnd_bits to 24, I saw 988 unique addres= ses > > > > > with the patch. x86_64 should have 28 bits by default, it should > > > > > randomize the address quite well. I don't know why you still saw = this, > > > > > or you have a different setting for mmap_rnd_bits? > > > > > > > > I checked the configuration on our test harness where the test fail= ed: > > > > > > Thanks, Suren. > > > > > > > > > > > /proc/sys/vm/mmap_rnd_bits =3D 32 > > > > > > It is surprising 32 bits still fail. 24 bits on arm64 works for me. O= r > > > the compat bits is used? > > > > Hmm. Let me verify to exclude that possibility. > > Aha! You are correct, the test is using compat syscalls and your > suggestion at https://lore.kernel.org/all/CAHbLzkoL6sCDciHqVMJga288853CHd= OTa5thOPQ9SHKSqjGGPQ@mail.gmail.com/ > seems to fix it. I started a complete set of presubmit tests at > https://android-review.googlesource.com/c/kernel/common/+/2916065 and > will report the results tomorrow morning but I expect them to pass > now. nit: You will need to #include in your fix. Most configurations build fine but one failed. It has only CONFIG_COMPAT_32 enabled: # # Binary Emulations # CONFIG_COMPAT_32=3Dy # end of Binary Emulations Adding the missing include into mm/huge_memory.c fixes the issue. > Thanks, > Suren. > > > > > > > > > > /proc/sys/vm/mmap_rnd_compat_bits =3D 16 > > > > > > > > The failure logs are: > > > > > > > > 10-20 14:37:52.123 7029 7029 V AslrMallocTest: 7 bits of entropy = for > > > > allocation size 8388608 (minimum 8) > > > > 10-20 14:37:52.123 7029 7029 E AslrMallocTest: insufficient entro= py > > > > for malloc(8388608) > > > > > > > > which come from here: > > > > https://cs.android.com/android/platform/superproject/main/+/main:ct= s/tests/aslr/src/AslrMallocTest.cpp;l=3D127 > > > > So, the allocation size for which this test failed was 2^23. > > > > > > The patch just tries to align >=3D 2M allocations. It looks like your > > > test allocates 256 bytes, 64K and 8M. So just 8M is impacted. > > > > Correct. > > > > > > > > > > > > > > > > > > > > > I'm wondering whether we should take into account huge page align= ment > > > > > for mmap_rnd_bits. And I think this is a huge page common problem= , we > > > > > have file mapping huge page aligned as well. > > > > > > > > > > 32 bit is easy, I think I can just make thp_get_unmapped_area() a > > > > > no-op on 32 bit system. > > > > > > > > > > > > > > > > > -Kees > > > > > > > > > > > > -- > > > > > > Kees Cook