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 30159C47077 for ; Tue, 16 Jan 2024 22:30:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B5F3E6B00B3; Tue, 16 Jan 2024 17:30:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B0EB76B00B4; Tue, 16 Jan 2024 17:30:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D6756B00B5; Tue, 16 Jan 2024 17:30:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8E78E6B00B3 for ; Tue, 16 Jan 2024 17:30:55 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 63D8F12063E for ; Tue, 16 Jan 2024 22:30:55 +0000 (UTC) X-FDA: 81686620470.15.13376C8 Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) by imf07.hostedemail.com (Postfix) with ESMTP id A3AF54000C for ; Tue, 16 Jan 2024 22:30:52 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=nZz+7J2X; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 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=1705444252; 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=y7N4JboEtU4jWdz6byN6GCXUwgIkHJrOYqYlkao/tRU=; b=XQi2KdrK5vdeCREW0a1KJqazqqQEaO7DRh+JQSPyUYdtPDgL82wHycWXnjZ0uoNWSQ7IMh EhqcQYMXaZnkITHSS8C+fhoP7tbOsRsWnNaeaObjq6Qp5Kj1ZR5FQa7AtcDFHRXMgHB46J dh6o1SLdLbgmEKgx1XgcLZPNd2yvJuc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705444252; a=rsa-sha256; cv=none; b=mGjkDbyBFTduuY/DoCR99WWgCs3ulJk3CRcnTePM9Ff0Jbrg0LnArJMLXJrT5EQeVoJXrz 61HJRRrBXQe4S7LkbaDHLbHa9hUdWcEGFGU7N96VL78K1QC7SAyMg7A+Nwp/tJ/3DExm0V NejwfXkk+oumHlhAED0bvGb9v+2awaE= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=nZz+7J2X; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-5fa52e173f7so70327987b3.3 for ; Tue, 16 Jan 2024 14:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705444251; x=1706049051; 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=y7N4JboEtU4jWdz6byN6GCXUwgIkHJrOYqYlkao/tRU=; b=nZz+7J2XCtL8ghBO6dTybzHAFxyA/ffGfGd7L+jfFSRzG/4YkOrfzHHPdvIKeErzFx O3POi2fJPtyMf+95hf9IwnKH5lukN+p8pxAOQsx47PmnxfKg2/5NU6gCmfJUhVmepYl5 6yIjNdnphsvC8rXENt7S+pZfgQ486KjOg9EZVIuJQtqEQGG98vKzIsk5xQ8aA0AHxB4D 5sQ+a5t00ijAp2j9oRpwELDWVZs6tCDLyaKGo0M83ZPxmIe8S+6DSOiWKilKXaMgewQY 9jDY7guw6sPy+XJJkapbixK2Af+M5n0XCGbBlVktcnlUStFipl1d3J7q9PdHhsbE7Lpb NVKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705444251; x=1706049051; 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=y7N4JboEtU4jWdz6byN6GCXUwgIkHJrOYqYlkao/tRU=; b=B8SBFji6aAKohjp6AtQ6afQnldSgq+xBfZIHzPirZ97dn43I/qPp7WaKLpQf7eA02q HQoA01cjG5w96ihd6/81KwI0yWk5R/p/HwU+YkUXc2ZxcbGFPXtRmJIoSIHv08xlEh7b Y68sBx2h0AY0vCS7zk7euY6lVtZQdDZCTwqhZjhXUUPOJuxNs/rk2Q8GUKbAE5mGG2Qg ZbvF5IEeZiHkPpKiyjAGHPiefF6Q/UCk3xMRx3hMh4TfCfJ4v/WaFnNLv/tNuq4yIPTB 12IjtBQuYe+/vckcSs4meNVkgwdxJOMc/v84bpu8An2L5C1WokQYnhvahDqqigZbQ8a/ NTmQ== X-Gm-Message-State: AOJu0YyatXiGEpDLj58iGik92nKln3nNjEO/J7/spV0HmHZUezN4f0+t 3+T/KZT8IY+nTLPriQzWyXSBSJIl+YxpaWa1p75Vu0tMvkl31uZyPGehZYT+/Q== X-Google-Smtp-Source: AGHT+IFMSWhX0L9o3vSwlbTPorHKhPhpXS+jBqmQNMi6+lI/YckxrqP/DU0xTHHmyxrTl0aJox+C+lcWljGDjjzruio= X-Received: by 2002:a81:af5e:0:b0:5d3:9f2d:658c with SMTP id x30-20020a81af5e000000b005d39f2d658cmr5577136ywj.24.1705444249248; Tue, 16 Jan 2024 14:30:49 -0800 (PST) MIME-Version: 1.0 References: <20220809142457.4751229f@imladris.surriel.com> <3193bf5b-4e22-412f-8c5b-68574942d9bc@kernel.org> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 16 Jan 2024 14:30:36 -0800 Message-ID: Subject: Re: [PATCH v2] mm: align larger anonymous mappings on THP boundaries To: Yang Shi , Jeffrey Vander Stoep , Kees Cook Cc: Jiri Slaby , Rik van Riel , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Matthew Wilcox , Christoph Lameter Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A3AF54000C X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: mji4ypeqbmmn1zuhtn5fipsg7gyi8wwu X-HE-Tag: 1705444252-891159 X-HE-Meta: U2FsdGVkX1/6wNwveNQoUlVIa9cC92XtTGNIz+5MdJ5Rvjx34CCdArgrSPTXQUKM+m3RQNBwmxmt/9Dytze+JELNObCjdO2SEbQ9rpuI5EKL7GaS3ZwTLyFuR9G+8T6riC5vre3zuJxZFfQYhEq4uNQu+hHiijyCr7yc9P1ffr3Syf+kPDmoTZyHZLhZ6mqkeQ/FUaDmUJcOYwMUMwLnFesCE5sX8l6+q51V0d2vNGYM2VM+Z7tjp6IyIw3f0BgeWddSIH++AcLtlxgd97mZro7o9XN7qBHc659IWEcoGOJviR7dA0u9CWUqGzzEyRL3Ku/x+Wk+MLnVsDFLnCOceKlh4gE4diuiOR5UrUXidrOp0ghXZ9e5WE1Xr3ASP6OI+l+bQzgyaCm0WFp4Sx3Prb8sXM/iwB0fPWKncqEjXK/aUo8Q/oy7F0og9NeH2jOQLQPbe2inmgpOf3qrJa7f6dChXpXv47cKkbCnVwy4yWP7fTm5HzjYkfTtJzHGOn/PlrFfM4rASw8HtuvdpeCvvCPWkErK0Xk/9HN3dfAusuECZt38PTPI3Hh0jKvK8sG6O1Z7GwMvlQ8heNLVKCIs2Pb8l1ZzVpLwk6Rvu2Mtjjqc0QxB2iiHHmBd+irQ9o6qtVKQ93aneIdYAXMZzDkJ7nGI/WTPQGIQh9JMIwdSS1h9lBHBn0epNtmghYtJ+VYcshMVw9pMeSz5cDDqjp+TbKMjzEizssw+stXuPWI8I4kqU4NxP5er2ASAjom6wQ/ANyuLOg3k4H8mMAR3CIWRcy5JVKBYlnYvCRFvGRIr65+PoLdZOnjZ97cZaAZJIK+sYGJEmWapgfLl9iL6/cVYg52H4cd7t6rbgREWYnE8ZV6n+J/f6eMQaQXsyVS3kntYjSvQNtpf4yMmeQLfgihn6ANPXc6Fiz4auQXNN+6x/brz0ttFBRyiQQPgDBcqIbETtonKvhpAZ0Dy6LPN3kz bYxujrom 0+49DTQZMe1qyTaswvk4Mc+SfSz0rFIVPvbukUN/tylbCzLRQ82HnnMd6u/hfMoMm7islVBjhwP7Bwyd0Ze8x+hjskEt+dHnZbX4pzAi70oysCnM3kL+B27NJRZLo7L9NRn0FksWieMTZvrvmDJesdRPl9kWaZYN25aahzuyLHqYBzJ8Ff4E7GuVP/r5WmogkTzwdL71B7H4fCWsfUU+9CGmpF9Bd5VM2D3XiJRfAziF2H2pvAyNPdsvXAqmIjRgEktqBIfbTYHrJj1s1CpImhQukKTnAdQJK4IupzHzs+afGOQ9SoaBnkEz+mlvsScI6E95wAxz7qo+chE+YMSOgsmemMka738qQ8r0BQnkW2ix4RaaoxytRuLEUSs9ZAxZuPbW5PDEiXGAu8EdyXWbJ8EO01uz24s6gP8S0K7DLkapXu0/lMmN9NZ3XgIRW1Bs0XEx2QwzQnwTF+GEH8nxswCypTrYVlZi3xiPB 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 Tue, Jan 16, 2024 at 2:25=E2=80=AFPM Yang Shi wrot= e: > > 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 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=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_size=3D= 0 type=3D181346 > > > > > > Error emitting field > > > > > > > > > > > > strace shows mmap() fails with ENOMEM right before the errors: > > > > > > 1223 mmap2(NULL, 5783552, PROT_READ|PROT_WRITE, > > > > > > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 > > > > > > ... > > > > > > 1223 <... mmap2 resumed>) =3D -1 ENOMEM (Cannot a= llocate > > > > > > memory) > > > > > > > > > > > > Note the .tmp_vmlinux.btf above can be arbitrary, but likely la= rge > > > > > > 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, unsign= ed 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 TH= P > > > > > aligned. */ > > > > > get_area =3D thp_get_unmapped_area; > > > > > } > > > > > > > > > > > > > > > thp_get_unmapped_area() does not take care of the legacy stuff... > > > > > > > > This change also affects the entropy of allocations. With this patc= h > > > > 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 definitely not > > > > acceptable for 64 bit targets. > > > > > > Thanks for the report. Is it 32 bit only or 64 bit is also impacted? > > > If I understand the code correctly, it expects the address 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_x86_64 target > > (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 chime= in. Thanks, Suren. > > > > > > > > > > > > > > Could this change be either reverted or made optional (opt-in/opt-o= ut)? > > > > Thanks, > > > > Suren. > > > > > > > > [1] https://cs.android.com/android/platform/superproject/main/+/mai= n:cts/tests/aslr/src/AslrMallocTest.cpp;l=3D130 > > > > > > > > > > > > > > regards, > > > > > -- > > > > > js > > > > > suse labs > > > > > > > > > >