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 16B1FC47077 for ; Tue, 16 Jan 2024 23:14:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 70FB66B00AC; Tue, 16 Jan 2024 18:14:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6BF636B00B0; Tue, 16 Jan 2024 18:14:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5874D6B00B1; Tue, 16 Jan 2024 18:14:57 -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 43B1E6B00AC for ; Tue, 16 Jan 2024 18:14:57 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1455240352 for ; Tue, 16 Jan 2024 23:14:57 +0000 (UTC) X-FDA: 81686731434.14.82A7EC1 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf30.hostedemail.com (Postfix) with ESMTP id 39D6580013 for ; Tue, 16 Jan 2024 23:14:54 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=b+N694zi; spf=pass (imf30.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705446894; 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=J9Z3MXcjroiy9i57xyVJiTSgypswwDTIzH0vhnXYwck=; b=MayXfZzbqUFilU2Z9hb2DIHTJi2SJwByNJFEB83nElGVhn1DP9EBlp96PfJef5fXsZ0PQ2 DiJ7UK7107mW2bDW1rZlJ0jjuQvWbD2i+aWOWBabR+S8EAaPjrutu7D0dFkzjKfD+0qbSS /ohobcFJsgokTvlJBr1DloePT8mxCwU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705446894; a=rsa-sha256; cv=none; b=LhSKDt0thCJJp2xJ+xMBe4BkACH4sornzb3WP2Q4emdVWgmh8Mrwyk/ISQUJsinKxYXhmL SKNu54XIIG5m3IhuxIhR51EDueM9GwaHaq7ga2bVLFnfKyyHmN4jKTqFpG1N0/Tz0JfTuR 16u7sbATPP14b+5Qu+wIuSDrb2uadH0= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=b+N694zi; spf=pass (imf30.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-28e33266e86so1470718a91.0 for ; Tue, 16 Jan 2024 15:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705446893; x=1706051693; 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=J9Z3MXcjroiy9i57xyVJiTSgypswwDTIzH0vhnXYwck=; b=b+N694ziH53S88vEsTGEyOWZu+3+LUKPKjN7F/Gb5S3tPsd1s+Ozz28h56SaIJt0yH omnMR6VTWNjB+MOlEaqnAfCoP5BpulLzu6MPfQpI6qWREtnkjrpAC/I/9K1cBsWEooCn jybZ9npTB3hDTKzVrcJ6DalHOQOIH/UFzw4alQZ755Kg4KFPDsiorBuCtLPRgNJkVrSm V3P3Pi5EjCTGu+7xYYKmbT/J3PhjVwiEgLdiDQqtLqcq05aWBQNjrPQMqHSJ4IGhiGOB PtwMPSxwoLjBoYM4fYnBnKceHssUH+9z0beNGIaeFcRxRtr+CL0LF/FvDLJH3X8Vu0fS 0N2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705446893; x=1706051693; 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=J9Z3MXcjroiy9i57xyVJiTSgypswwDTIzH0vhnXYwck=; b=wG2kc+IHgWgJom054v5cLK1ZI/eYINw4A2OBVMM7st8QW6v0vs/Mj4/Z1SvwEi6n4t /s3BBavLzyvxTHY+VSxYk01P8ptk5ThDkMV+CgzR4Jrt8TfSaWBKTvl4wtYeXpdg2lFC nOOpcBicKt/InuAwu/ZgMsV2zCsJZE1LhsSrSMQYC27k6iCVDp3jsCzgq0DJxIONmn/J +MsLr9mm0d90O9AO8sAKlDpsPhYhwYyPFRfW3BiBAER5NHupt39Bezf2NIqsWO9GUNV/ 2uVDRXnuRe/jFHjPQeskEgNM/KuDEi1xr8I7xGlpoRJKFaEdCcftURqkfiK9weQ/IAof aVEA== X-Gm-Message-State: AOJu0YyZNjZvnVkKJnoOE/JpsvaWHwP5TnVgEV40MtcCXxiZujorvnwd 5/aGkZuk73X1iS9AfLvUIHLoD9zg70W2j86fOJ+gwNPB X-Google-Smtp-Source: AGHT+IFSPAdOss9OUVk/3MV1NNKRhquNEgTUBhu8TCFWEVWXaSWD0A0eq/DOkUrsgOZPuLTX4gUD+GwBynThYugNSfc= X-Received: by 2002:a17:90a:49cf:b0:28e:7b66:73e4 with SMTP id l15-20020a17090a49cf00b0028e7b6673e4mr1239524pjm.5.1705446893001; Tue, 16 Jan 2024 15:14:53 -0800 (PST) MIME-Version: 1.0 References: <20220809142457.4751229f@imladris.surriel.com> <3193bf5b-4e22-412f-8c5b-68574942d9bc@kernel.org> In-Reply-To: From: Yang Shi Date: Tue, 16 Jan 2024 15:14:40 -0800 Message-ID: Subject: Re: [PATCH v2] mm: align larger anonymous mappings on THP boundaries To: Suren Baghdasaryan Cc: Jeffrey Vander Stoep , Kees Cook , 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: 39D6580013 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: osd8wsrx6tz7d9j715uz7c5xe7t6z9wc X-HE-Tag: 1705446894-982532 X-HE-Meta: U2FsdGVkX19HS7GxRxbixETk2wVj3xm4X3JnHUItgdlEXHccyakQ9vGBsuWrKTFsM0Atb6AOzs8e2T70fjSzVLc9rOv31OiF2TS23eg0NaoK9hdwewERBrGNNRV3PKI1cloxgVokOfVojwujdnH13JhWW9suMDUMGS9fr4rbryL37jL3+rJ8ktB83G3Jjiwb7wXkZeWJp85O17K4lrOrL/mvh3kOeM53oXhsasEjTbQBK0YM+8Dxb0XAjLJK4sUlbf+oTWTXgeRDoPQdi6l18KBowOZw1Jj8dtMSj2k1Y2DDc770c0gQGZQZk7jjuKRqPTCQOkSL7bQoKH4xMaJWaEFyIG9W3pfCfvz/O680Z2nBRG4GR1IqdqaKU8e/PzthSeCiNfT/d4oxF2AUgthsYgOvT+ROzspSNt20PRwTw3bUiu0nqOeeQGwLTEKNWZ2vFGdCrQ3KNM3cBT/4BEbacoixZJ6555fzHQJGgafyUupVqfWnwVowtbonEqfOXHYA/4OITMFRFdfNzeRQtBQ58g4xnD2AshT49Tw/QDMTi5fzlDRODKE4fW4SZ7Wevpwma4r5SwHYCs2+qy3V9GJr5m5Q02VTL5WXtatL8RRRZZu0wpr5V5IFvpJa9W3/0bM94VddXL5UVLYXRC6atc7VE4Jumq6Hy0C/wIbc6ra+muZutMfOrRelhpx70uAotucMSlN8+uMa/MBouKOLZy31fP98k/YgNWTXPDPCH+72e1b8EEuY0i3Va2j/YUgr//E8NFhiEeyYxBxzRzKktwFMo83E9bWIoflS+BJ1jmJuMb7lg2AboV3zwh2d44yzUDbwDbx5Ia4QDVdQ6pCliiQf4HdwX2WSF70ny5MssvGJBLe0npdBrTPf7v2qKEQHZ//WucjqPAfpNMD08Rxv3EExlQWDQ60v9ka5+99p/7F4b+IyPkF3nATaHW4kBzI391INTxzricBU/Ch3XIubjv2 VQo0tQfM pRtcCjg+x5fustnDBYr4eXtgiJWekomUFEJK9uI+AE6mZqsL8JrE/6SzMUId5nszOJcRx6KfaAVRrK+819jasGQGYBikZvy2WPTbEI3LlYykUNSNXPaGxNTPupEPreR6dZv3wERD32TuxNaGNWWsj3UixcfsSAK2p8/ZUiyFP6Q9JsYoaXOdeQ92tsyJVyiYSsVKi4iv4/V5daCX+x8btNvTrGbL1eNlDVaiGWooKKG2GFxH67GZrlu2DZwI2zi1FXYvIPnGy2YPi6DUH7tlmrZej0H8Lqs7a+6VprbZLBcFJu7lJJXtYNRmHEwzXJsVPARkcaEA4S4D9OC4kBF89YcoGpsuVt/IGhvoA28p+S6sq4UAktjIyQ4hzb3lciteeQ9GapYKHYUD5CXoETGaRo3jaTnJ/V4+SiSGR4L0xbougpel2nymTQAgAx1ucYeZHeaLL9GUalpZOIa3E2DMWEPkdvSjqwR7TwdwmVPuqOrkIyYHqTQak9/ktl5Q/2l6DEt99MjdIWJLnOiH56EIrCTIT/a/dxPmPMfZc38LEaiPUAja6+RnftEuMqrFi9Izw/rW9Y5vpygJ21eomUNbvzmIHvBCJ+SWCJBlg 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:30=E2=80=AFPM Suren Baghdasaryan wrote: > > On Tue, Jan 16, 2024 at 2:25=E2=80=AFPM Yang Shi wr= ote: > > > > 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 align= ed. > > > > > > >> When a malloc library allocates a 2MB or larger arena, that > > > > > > >> arena can now be mapped with THPs right from the start, whic= h > > > > > > >> can result in better TLB hit rates and execution time. > > > > > > > > > > > > > > This appears to break 32bit processes on x86_64 (at least). I= n > > > > > > > particular, 32bit kernel or firefox builds in our build syste= m. > > > > > > > > > > > > > > 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 .t= mp_vmlinux.btf > > > > > > > > > > > > > > crashes or errors out with some random errors: > > > > > > > [182671] STRUCT idr's field 'idr_next' offset=3D128 bit_size= =3D0 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= 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, no= t a fix): > > > > > > > > > > > > --- a/mm/mmap.c > > > > > > +++ b/mm/mmap.c > > > > > > @@ -1829,7 +1829,7 @@ get_unmapped_area(struct file *file, unsi= gned 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 stuff.= .. > > > > > > > > > > This change also affects the entropy of allocations. With this pa= tch > > > > > 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 necessar= y 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 allocate= d > > > > by malloc() is kind of randomized, right? > > > > > > Yes, correct, the test expects a certain level of address randomizati= on. > > > 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 don't think the kernel guarantees address randomization if I read the kernel code correctly although it may look like it has a certain level of randomization somehow. If I remember correctly PaX has an ASLR patch, but it is out of tree. > I admit I'm not a security expert, so I'm looping in Jeff and Kees to chi= me in. > Thanks, > Suren. > > > > > > > > > > > > > > > > > > > > Could this change be either reverted or made optional (opt-in/opt= -out)? > > > > > Thanks, > > > > > Suren. > > > > > > > > > > [1] https://cs.android.com/android/platform/superproject/main/+/m= ain:cts/tests/aslr/src/AslrMallocTest.cpp;l=3D130 > > > > > > > > > > > > > > > > > regards, > > > > > > -- > > > > > > js > > > > > > suse labs > > > > > > > > > > > >