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 6744AC4725D for ; Wed, 17 Jan 2024 23:32:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C47036B008C; Wed, 17 Jan 2024 18:32:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BF7196B0092; Wed, 17 Jan 2024 18:32:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABEB26B0093; Wed, 17 Jan 2024 18:32:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 993556B008C for ; Wed, 17 Jan 2024 18:32:53 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6C814A1D34 for ; Wed, 17 Jan 2024 23:32:53 +0000 (UTC) X-FDA: 81690405426.28.9996ABC Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf04.hostedemail.com (Postfix) with ESMTP id AEC6440004 for ; Wed, 17 Jan 2024 23:32:50 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Km7EU+z1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705534370; 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=9YfAeTmtk679tAu7dzARGO25mtGdcyY5L1KoEcIoCfE=; b=oQJjh5v2S5CDUS5z8ZCk8u3VEBeUZ0bGpm/7cVQIGvacVykTutv6x1+1fwFAlxKfwCu1uZ Noj+zusM5R1an8qg3JjJJ3a4JMQrQFhXyGWVe6aLXRk5l3dGC4RFaFzjbio0+qwjJhrYqf ieSJgOM4sxGpyUfukt4+M6gYI0WaDiw= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Km7EU+z1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705534370; a=rsa-sha256; cv=none; b=ODvkqjHLToJel2JHPQSMZQHieS1i5U8N0wgDz/QRlSL/MguI0U6j1/dHDre7emTbx0HQ+/ WOqnnVMpI966VzR2piA6OTbcwVfr9qfnAmLtlv+5AbMDheVrPjJC1Qsb29waLYeU7V2k4g 6hmcZ1nau2AuexPKyRqB/6kC7v7meis= Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-1d5f388407bso14229255ad.0 for ; Wed, 17 Jan 2024 15:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705534369; x=1706139169; 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=9YfAeTmtk679tAu7dzARGO25mtGdcyY5L1KoEcIoCfE=; b=Km7EU+z1+12oinmyZgvzN8LtHiKwjaBXRoVrmwd4DWKBwaSlmzWa3oREmZ4Odnnz7Z VoBJX38fZVWiENAfM/mHh6SARXj52JolUCNFwY4uwsqb7EnE75W/o87hWZMbhuFvl9w6 P04fZaAjIyeZXRVrZd45s4OJOHeAL1ADTkBn2WrcTyna6aZ4ynA0wEuthjivuRAhyhaX J+dWFDgSyjJRgdpY3sCgvwRkQyTnnCcSm0zMSY2QGThEuP3nHhpzltJ+qszOg9cDBCWk rVP/QfmZ2FFxB8qDf23ie6R80R7ap542s5eLgYBrNMpi1StwR5gNOs2ZX0LE0wUPr9hH TNRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705534369; x=1706139169; 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=9YfAeTmtk679tAu7dzARGO25mtGdcyY5L1KoEcIoCfE=; b=LfQe9i8Fcb3FZrcMMru1axoz3aQJVVfFRVF385xv4h36RcI+gGxd353gzCO6zfzgZ8 cqjR4Qf9FR6Iyy+f8IPRECQEs4+RdPdTdk9C/6IIUI7aPwJ+w9FxRso1T40egZbOPVqA WDvKI9h2pVGWReN4Uj4W03oQBp6QlX/UpwGmzrl7u2kS7j260NPjquLPWMc1BAwq4zYP W6wuCcdRk5NVsPIp/0n1bZPX46WF5vKcOe3Eldqx8dYH2gNApQIbLYCoq8+JEA3an4Pu ddCv0enjhiH64YdjVCURxMFG4n8T9n1B3zCOPkbLH5Qd1Rwj+PVkyr4nT0ltz81XgCOD +kFg== X-Gm-Message-State: AOJu0YxEjiTaUpBJ6LxvToNcdU7T0d0fg2yhgf4xsmj4RnDNczUTIDbn /quV3WRqRsCwoJm224/UvGmVULmk+oDZrdva4PimF5rClmQGFU20jy9oEsg5+zjhtww/RoW9D31 4SVfI5EvEHAFcO1a+mZa/avBKq88= X-Google-Smtp-Source: AGHT+IGSjjjI48LFbJbhuzvKiPU5xKL4kK9o6cxskSzYKYXU8MavbZwvXf8XIz11R03yYXPwR9d+H6HuDPPtKX52Qo0= X-Received: by 2002:a17:90a:a893:b0:28e:44e7:fad6 with SMTP id h19-20020a17090aa89300b0028e44e7fad6mr17619pjq.90.1705534369306; Wed, 17 Jan 2024 15:32:49 -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: <202401170925.015D300A@keescook> From: Yang Shi Date: Wed, 17 Jan 2024 15:32:37 -0800 Message-ID: Subject: Re: [PATCH v2] mm: align larger anonymous mappings on THP boundaries To: Kees Cook Cc: Suren Baghdasaryan , 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-Rspam-User: X-Stat-Signature: 9okh4bj4r7scg6hj53d7uoq8fbdefuiw X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AEC6440004 X-HE-Tag: 1705534370-242702 X-HE-Meta: U2FsdGVkX18f5scrLalAVFcvH/cK/ergnNNDs59lCh8zjiEZKvXJwIDSG50hNhgjq8SQr4kcqrCtSXmQ00Yg10S4CL4vlVcO4GB/lcJg4xmeQ35tncf7JI/hrC0aODOV9lX+SaNzmk6AOdVH4fYI9k+QXWfuGl9HGEVB9XZtd1u4RPqO0p625IbeWGzcmARMqyhUvnJCKrSyS/J4f6Sm/XA1pdAosZYzM2ogaqNGRq+4dXedg31daBK9mG7Fkz5jGw3kEsEaojAM8q2h8u1buqzpZKMuO3gnXzHR2GVIgaDbpmE5RmjoU2tOVteYFrMZP67SMjYpWCqwwxuacpCRo6I1d39ki6iNBntjslLWcCCeMt0BPI/OSNiFAzDyibHNZUtJKtnRSHhv9pGUng5EoWV+KUv5nX9vSafFFsJiaTvR6q5yzUYU5wA5TmR1Gsd78uVnmyp0FgHgsPI4Pzv22afJnt/KYWPCbWODHQyHkws0nQ2/RJD1kcVGCvCp0aHFjp/pRwpwAwzurw4m3EzVGeyjN3Pvuo2eoarzpi456H3+vAN7j8wt4/uLjzYNLw/rbNGiJWAHUezlsX/0GhemsiFI178Ix99dYApb5324bHSdbBxaESPfRQSoyEqmMC0UEgAcBHWVdaF5cLVv+QXOoyX185SJCcXgkkl8Y4ziwpNCtdyY0t2tHdAxmVzwYaQHYiT3QIrl3di64EQQhBE8PyixNpZcPP7kD8vmX+3jJuM/f7JzSohI5dpnHD4o7DF5prJWyCtpAFSOAo1cPR0FJ/NZoRoZ8u83Q/EMt4Ulsq6ktIItozBgU/X526cuZuxohwwBx+m0tCppv88aH1AtXZ3rGnmxVXCdogKg5kti/ippXNjepra1KzdlQVW/GR8ZLT+ZDH7YK/PFJm/MHOUIgvuPy+w1a/75vOoxhl1gl/rJcmumyBe69xyWVorE8cm2mCr2qXUssyqZSH50ZOX vHjI+98l DmyVo2oEHrxR85iwYqWcwXZLEPio10GM+z66mLa/PKzOOJ4kJcV0pqbWkRkvAxyUb9HDdXEmRr+4ODKv+YVpxYaqX90L7tRzvn9H/naGlGaAg+fGNxoXBAK7dISrChrRODH6nZHXryauVSrrYmbCRrjl3Eyxo76S9UGKCetHefHMEh6aCSb2vnSi3VOSjxoWhhRCTzY7VWQP863yEQLm8gKneMicLFspsbUpYt7C4so9oFijlZ3aZc+9+ssfQdgwyFq1Okl8+m6VqSOCBXwXtw8IN5gr9371RdTtt6A4Ky+a/kAuDzx2jp/xywGETYq7xRjbJjzNj0MgzqkiQvqbdPxHPXljWKMOo3tS4qlS6Qu5ZYZdg2oPWUfG32M25Lm18TObvOzQ3NT5VGtroZiRmCxfbAOjGXvP8wlUnEBnbpFQ+19x34VAzCJdXy2SspiIwmNM2+jtSjYo0QgFf9b7Rk4BjJiqxa3ojCWCVCOUc1+6val1SSUiVQExOStjjvEmkE/gCYXmdqsXZtJvGFJPQDKh8OA63KSCBFKqD1AQkd1Y7P4yEKv00fgAZWEFijfbjvFnnEyHyht8WjB/5YBCVgfDLys8zddVApNovmcV9hiKcXgw/lr7Fz11Z5U3TgT3ifhOZ 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 9:40=E2=80=AFAM Kees Cook w= rote: > > On Tue, Jan 16, 2024 at 02:30:36PM -0800, Suren Baghdasaryan wrote: > > 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 Baghdasaryan 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 boundaries b= y > > > > > > > >> going through thp_get_unmapped_area if THPs are enabled fo= r > > > > > > > >> the current process. > > > > > > > >> > > > > > > > >> With this patch, larger anonymous mappings are now THP ali= gned. > > > > > > > >> When a malloc library allocates a 2MB or larger arena, tha= t > > > > > > > >> arena can now be mapped with THPs right from the start, wh= ich > > > > > > > >> 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 sys= tem. > > > > > > > > > > > > > > > > Reverting this on top of 6.7 makes it work again. > > > > > > > > > > > > > > > > Downstream report: > > > > > > > > https://bugzilla.suse.com/show_bug.cgi?id=3D1218841 > > > > > > > > > > > > > > > > So running: > > > > > > > > pahole -J --btf_gen_floats -j --lang_exclude=3Drust > > > > > > > > --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=3D128 bit_siz= e=3D0 type=3D181346 > > > > > > > > Error emitting field > > > > > > > > > > > > > > > > strace shows mmap() fails with ENOMEM right before the erro= rs: > > > > > > > > 1223 mmap2(NULL, 5783552, PROT_READ|PROT_WRITE, > > > > > > > > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 > > > > > > > > ... > > > > > > > > 1223 <... mmap2 resumed>) =3D -1 ENOMEM (Cann= ot allocate > > > > > > > > memory) > > > > > > > > > > > > > > > > Note the .tmp_vmlinux.btf above can be arbitrary, but likel= y 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, un= signed long > > > > > > > addr, unsigned long len, > > > > > > > */ > > > > > > > pgoff =3D 0; > > > > > > > get_area =3D shmem_get_unmapped_area; > > > > > > > - } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) { > > > > > > > + } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && > > > > > > > !in_32bit_syscall()) { > > > > > > > /* Ensures that larger anonymous mappings ar= e THP > > > > > > > aligned. */ > > > > > > > get_area =3D thp_get_unmapped_area; > > > > > > > } > > > > > > > > > > > > > > > > > > > > > thp_get_unmapped_area() does not take care of the legacy stuf= f... > > > > > > > > > > > > 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 necess= ary for > > > > > > 32 bit ARM targets with low RAM at the time. It's definitely no= t > > > > > > acceptable for 64 bit targets. > > > > > > > > > > Thanks for the report. Is it 32 bit only or 64 bit is also impact= ed? > > > > > If I understand the code correctly, it expects the address alloca= ted > > > > > by malloc() is kind of randomized, right? > > > > > > > > Yes, correct, the test expects a certain level of address randomiza= tion. > > > > The test failure was reported while running kernel_virt_x86_64 targ= et > > > > (Android emulator on x86), so it does impact 64bit targets. > > > > > > IIUC this breaks the "expectation" for randomized addresses returned > > > by malloc(), but it doesn't break any real Android application, 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 outweighs > > > security could opt this feature out. However I'm wondering whether > > > Android should implement a general address randomization mechanism > > > 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 c= hime in. > > Hi! > > Just to chime in, but reduction in ASLR entropy is absolutely a > regression. This is userspace visible (via /proc/sys/kernel/randomize_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 the 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 formula doesn't take into account huge page. ARM64 adjusts the mmap_rnd_bits 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 saw 134 unique addresses. Without the patch, I saw 945 unique addresses. So I think the test could replicate what your test does. When I increased the mmap_rnd_bits to 24, I saw 988 unique addresses 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'm wondering whether we should take into account huge page alignment 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