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 9ABCCC4725D for ; Thu, 18 Jan 2024 00:02:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1073E6B0083; Wed, 17 Jan 2024 19:02:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B7AD6B0087; Wed, 17 Jan 2024 19:02:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA2166B0088; Wed, 17 Jan 2024 19:02:13 -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 D9B3F6B0083 for ; Wed, 17 Jan 2024 19:02:13 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 93ADA1A0465 for ; Thu, 18 Jan 2024 00:02:13 +0000 (UTC) X-FDA: 81690479346.10.9636AFB Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) by imf14.hostedemail.com (Postfix) with ESMTP id 9682E100004 for ; Thu, 18 Jan 2024 00:02:10 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zKRoaKZd; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.128.169 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705536130; a=rsa-sha256; cv=none; b=E2puq0mQ6DhUvwgYRtZkWphW2x5kPT2UMTv+ebI3qJ4bgqHu7oV97Oy3KytTAZoX639wRX lbHgmAUOmxJx5fEuuI/qz8lT4BzpcLOGDU+jheBmunFaSgNRCeht25wYFKB1Nvy9MMkpm+ qFIC+hvqXCByrn+CxEL+nhiXzJJ5DSU= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zKRoaKZd; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.128.169 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705536130; 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=LuJo17HGWlkmsJh3BmMrEUkGCN7pBDfz8ryumCkF23E=; b=hN6mez2MJ0doao/DuK6iS4BICmCuTTQKENW85zXyKKBXgfZ2KqJD3at8LdQm4nVGjEV3xU w32UlBhBWttKWWYecxTBqeTlcV/Tg09c+oVV66vHRKD9Zx0KyiIYxA8nXCcDOyEsaq2DLj 91N6tjcA2PnCk2rqcmtaEPIW9GZF6P8= Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-5e734251f48so1810837b3.1 for ; Wed, 17 Jan 2024 16:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705536129; x=1706140929; 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=LuJo17HGWlkmsJh3BmMrEUkGCN7pBDfz8ryumCkF23E=; b=zKRoaKZdZTgYTEdgmUhorhDIwnX44UTEb57ODXZGD09MsBYfT4tdpWpVSy/Z+vbRSD nMZGRjzQGnV1PcVff7ubJndEmxXe1DF0xw/QGndEk3ULIsjtxwYsK0/MgAn4TRbOMD81 e9ZU3nYdKTaM+GpWGS6Bv3MkqbOHuDrNWobX7VZqpUQ5VTBtAySDcgRnZiqBWeEX+cE8 36cb72SNW7IqmHh5P4q5GlFlqEl4y+DBJrLDB12NwbX+8AgJympOwkMCTPBCK1oMXVbC W8WHtURYGi/Ulwq8UrLebc5wLhdA8pqO6lI6egVWpbABrZmNbENMZr6/PkudCeHXs4f4 pg8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705536129; x=1706140929; 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=LuJo17HGWlkmsJh3BmMrEUkGCN7pBDfz8ryumCkF23E=; b=gOQVpBtOYOG5DgmTNqnoEcbPNghydeo7TpIdUiZEl6EaAfrQmMT1MgeMfbX0+IHfiz 54Q0RH32OqMnWWJwySlIEpfbp5t9aHhcrlfqjmhX0xTdprwppfS5uLVEmIi+a2a5UurE ZIjgL7z3Y+Wt7iHKivzFv6YzY8R74ZyrYCp8gTusZc3/kKRAfPkGnm5zWS69dC0/1/In j5+Pb6IsKVYEd9aIC2+2xjKwlrcwsbq3FRgHZvpShyf8uf2YVhDRfCEzKVCzqRHOVz7T qXbOpX+axfLtrDIFqhK6nhmRwy/J3FE3kUgVEBokBgVKvbEYOxEwTd6NaApPiX71GBcn PN7Q== X-Gm-Message-State: AOJu0YwSpbYI4kZc9zMLm8XuXvMIuH9haLkxSAvh3E3xoKBZaIo9Zm4v MGYLSxSYmemaH4axyPBtrIVZj5oCOyCxi86wrez6X/htkv8uRFqEUZYo0WFT1q6XOjhGjf4RvK1 +AodyXpwAJV/AjxTItMN2mt+cghlEGYG09jpy X-Google-Smtp-Source: AGHT+IG2O/e+oiZQ/896Ypspajf6K7CKlewGUO0dyo1YSaL0Qv4ne17opY7gWwKea9kuFm9L4RaUnlIJFMbQmJTw/G4= X-Received: by 2002:a0d:e4c5:0:b0:5ea:1ea8:9ca1 with SMTP id n188-20020a0de4c5000000b005ea1ea89ca1mr66440ywe.43.1705536127963; Wed, 17 Jan 2024 16:02:07 -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 16:01:56 -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-Server: rspam08 X-Rspamd-Queue-Id: 9682E100004 X-Stat-Signature: nawrtm71ixppjtcoy8dr5s7gd3gqtdi3 X-Rspam-User: X-HE-Tag: 1705536130-862185 X-HE-Meta: U2FsdGVkX1/7hvfuwsdBe4AX8blTkJgpZp1JEjXARrSwzGdq1z/hWzatic+zDmWafJg/NdptpGSQgBAM5+tulbWP8Q3xZrYgIfGWpyoiJnIfHK2j25I55zO1asmC6O8/LnBKcdlqwxBeWuybusjgUAzwCLuBUQ1EucEfFnxqgcmxM42BKORnv2QB8fOS7wi/P5N2Iqgvx/aGaz7GRxSrLGX62VPXIuPO2UyGRcpMQXLaewM9GYi1Qs+YR06LcEC1algHhWqpCGbq+Q7zZc/ge+rEZLYponIBicp0nfOSAAwdvm5+Tzm7ms9QarzlHLcmeUID2N2DsX55NATdFWMpHCujLUFWuaZzIwxxBC/JYcUUJwYTrmff5Kj5t1qc8xpWj+MJrKoprGtGJ0QDJLuEVWZppZ1lCCZxQevprTaBZaDjF8CyQ6rWhmPJLJ+yPsyaB/cj4CjcDPdKM8asvq2vpMfu3YuKYW0XAsqqg/YI+Ee2RuyQj1/Ky8JdgBHwHSvrxuDFrFvKtbRkyeZa26XgAWDVFxZsa6UUO7k6spfYJSs9WcUDuyMTdG3Hhxo20tKLs/AE8FjxhAim0CbFo2rFGg7RCf/iJx/0hcFfXV+t5cqNz7mRpUMQ/IkWTTuxGkchV8ZdfbsOB1fnkUb/vtAN8oGre7B3KEweCMmV+3mK2QHbKzjJU4lNfc/WVUTfDaXAD7WfS53YNLMBWUAmadeLr0qx8Cx8DcT77HP9ulJ9AlRRjLyXJ/8SXj90L+7arXx6B7jOS+r3qes7nKl1suJl2WvrwkHWhkr6klh3nRLk6NELPWafzM19pF/0kgJUvOTPKvCGUsH8zkyvfx7LjMUz3yTQ+FJODncBgn1pKiMGurfrxVkE9tLcbai9nsqAPm0upDda67OvxtONH3XQqbmfRDnuanRv8AbqClsFYtegECBh3o++XPHS1wqXsFe14RKfkTHXDdzfv/E0nflCQSy qfmNGZkc o5lSDUi+W605SDBbwHWxx6ag1/B8tJAMAae0lBoU4A4t/SB9wLq3OcehtCwup5G5DlHWsBu3vvD89/SsQc0YyZ6KqlqZxMuAL3I5ZZHE00B0vCyGdRZv+eTN9f0pP/iPq3TQZb6+yPNFVGiDv4PCwj6XX1HGrocL0pFJdmwwOnrynwquxGeAg/vmyLVn8TETcUD4KJS2/MuVErgLlIQoyaKt/lmCYehanTLEqUaX4smakfcwS4y81sYqEODqadWgEPS4hh5oKI2g2scPMzh6cEcYwvHewHusi01hieCVRV1t8FMTD0WeIzdmrUFIeXkzF2h8prT11ywFVQq1EE41IsqZ/h67915UQaRZYwD4gLoBbCdICSfbFYWh5TNLc4iqDvpyHwhqTbnYev6jjwLrMg8Z7SNDfFYKFS/6B54Y56G7aFdDDJPbUTwiDi8ptg7ijxcqXD1CNUpm/ldo8w94Mn9lv27l3K6P4q3WGRDXcC7jQQ8LNnYEo+YjtusUgvJz37R9h+3zIRkE4WbuwRSqPc+5/VQ== 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 3:32=E2=80=AFPM Yang Shi wrot= e: > > 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 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= by > > > > > > > > >> going through thp_get_unmapped_area if THPs are enabled = for > > > > > > > > >> the current process. > > > > > > > > >> > > > > > > > > >> With this patch, larger anonymous mappings are now THP a= ligned. > > > > > > > > >> When a malloc library allocates a 2MB or larger arena, t= hat > > > > > > > > >> 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 s= ystem. > > > > > > > > > > > > > > > > > > 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_optimize= d .tmp_vmlinux.btf > > > > > > > > > > > > > > > > > > crashes or errors out with some random errors: > > > > > > > > > [182671] STRUCT idr's field 'idr_next' offset=3D128 bit_s= ize=3D0 type=3D181346 > > > > > > > > > Error emitting field > > > > > > > > > > > > > > > > > > strace shows mmap() fails with ENOMEM right before the er= rors: > > > > > > > > > 1223 mmap2(NULL, 5783552, PROT_READ|PROT_WRITE, > > > > > > > > > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 > > > > > > > > > ... > > > > > > > > > 1223 <... mmap2 resumed>) =3D -1 ENOMEM (Ca= nnot allocate > > > > > > > > > memory) > > > > > > > > > > > > > > > > > > Note the .tmp_vmlinux.btf above can be arbitrary, but lik= ely 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_area; > > > > > > > > - } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))= { > > > > > > > > + } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) = && > > > > > > > > !in_32bit_syscall()) { > > > > > > > > /* Ensures that larger anonymous mappings = are THP > > > > > > > > aligned. */ > > > > > > > > get_area =3D thp_get_unmapped_area; > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > thp_get_unmapped_area() does not take care of the legacy st= uff... > > > > > > > > > > > > > > This change also affects the entropy of allocations. With thi= s 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 nece= ssary for > > > > > > > 32 bit ARM targets with low RAM at the time. It's definitely = not > > > > > > > acceptable for 64 bit targets. > > > > > > > > > > > > Thanks for the report. Is it 32 bit only or 64 bit is also impa= cted? > > > > > > If I understand the code correctly, it expects the address allo= cated > > > > > > by malloc() is kind of randomized, right? > > > > > > > > > > Yes, correct, the test expects a certain level of address randomi= zation. > > > > > The test failure was reported while running kernel_virt_x86_64 ta= rget > > > > > (Android emulator on x86), so it does impact 64bit targets. > > > > > > > > IIUC this breaks the "expectation" for randomized addresses returne= d > > > > by malloc(), but it doesn't break any real Android application, rig= ht? > > > > 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= chime in. > > > > Hi! > > > > Just to chime in, but reduction in ASLR entropy is absolutely a > > regression. This is userspace visible (via /proc/sys/kernel/randomize_v= a_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 checked the configuration on our test harness where the test failed: /proc/sys/vm/mmap_rnd_bits =3D 32 /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 entropy for malloc(8388608) which come from here: https://cs.android.com/android/platform/superproject/main/+/main:cts/tests/= aslr/src/AslrMallocTest.cpp;l=3D127 So, the allocation size for which this test failed was 2^23. > 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