From patchwork Sat Aug 3 07:46:41 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Gow X-Patchwork-Id: 13752318 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D0BADC52D6D for ; Sat, 3 Aug 2024 07:47:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:Cc:To:From: Subject:Message-ID:Mime-Version:Date:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=W+8zGdX+0w0z65lZvEos03h3yEnQFMCquba341r2hLM=; b=uxKhTWd/cCBlRZalpNldqnkK82 IlEdF7I/EbdJnT9+GOxaV43bL7amnUP6nRNChmmT+TnQI6aGiCsHe1uePCEI/OIaaNti8mHhSm/5r D0eDJVUeuUtoRivIWK2ZTOzJWx6m5MDya/npl2hoJtu2OriwTy+eqD/LsRcKo4BvfprAbyAd4oDoB yHCb884WkTO46K80UHN1reggXUcQkb6EUDJtTiGOd5NYAty3ZMBfzOx+QTN9LHQK18RTcSuWR9KSt QmtorMSP+s/sHtB5QaUjJXcjcLoyo3rQ5cEDR+pXJhC10bb/RGjG5BwTpt+SZncG4xlQWRrXbxFPJ l7I4jkdg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sa9UF-0000000B0P3-1ytN; Sat, 03 Aug 2024 07:47:35 +0000 Received: from mail-yw1-x1149.google.com ([2607:f8b0:4864:20::1149]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sa9Tl-0000000B0Jv-00aP for linux-arm-kernel@lists.infradead.org; Sat, 03 Aug 2024 07:47:06 +0000 Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-66890dbb7b8so192855347b3.0 for ; Sat, 03 Aug 2024 00:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722671223; x=1723276023; darn=lists.infradead.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=W+8zGdX+0w0z65lZvEos03h3yEnQFMCquba341r2hLM=; b=kM+a1+Onxu1w5UYqEHp4oL94I12fa0abZly09NXPRI8su9E/FLobtNlVXAwyTMizO8 l6bXUoqn4ViHq87cQXcQivgIBaxHpbKEmOD4AfeXtMYOj5YnjGRhvxXm8qpKo/R1qDGy hg1VLWbG8oGoKSgL/mVDLSuh2h3KDxd6MzWHgzdeI2id+uPJDItFnGs4jeD1IzeWOLJ9 CrQEEirHzUSMvUlOrgC9Sfho8u4bU5IHuChp8R62ciY7DhcggywSdQikujFSjLCWyCEW BSY6SVEKI70Mtvc9uzKPLBbT0KIxHve3ndLetVWP+TglrCeliYEgHVQ75Et3pXtISt8U oANg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722671223; x=1723276023; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=W+8zGdX+0w0z65lZvEos03h3yEnQFMCquba341r2hLM=; b=X/PPm2svRfnylEwP1ujUp0n1fx+azh4Hn0bE1DmdutIzsHZbbrAAiM2jMle8przj22 T7acFceiZ91DnDxgzHZqXuRuy7SqGyN3S/+FNfWTWAsVuvS25GWJ1KXibBZz6lfmE7f1 /MCKoVATJwKHFqwyz9sthUnObFVAGjaIOUtPJgr17SoI1cbZTRuHrrEylQx7iVVtckO2 a9sdxTvakD7AQp6cIgDVAb9x5/Lliw8WGojFX8PstusZp7n3M9vkJLeSfeB0V+DOLKuo pRZ99fFYPNpBmDCXE3A5nUzmLWftjdcM5KOrv7PrMoU6aQEhhLiXd4Y49+KEQa4Lt2bS J33Q== X-Forwarded-Encrypted: i=1; AJvYcCVUj/IuBKcA8X8CLwcm23XVYAscgkWVLHGQpbNj6fUxgym1owCVpUFCQGGTszdytDXywo242bbzvRIwFkcyf47mDzCe7tTyCuUwDxNekyeCJG/TgeU= X-Gm-Message-State: AOJu0Ywb9WpR2wfjoWEy2LzFkUxQMje0QndH6FYjrKuCcZ+kGsPkJ6lw 8c+NovBxXU5QbnWSzQ/QQ/z4jLIf/WRJsDSytlG3fh1lsruMKQvq4SiUH7cMFRKgGumhLIkWmCB Qzu2Yo/H3/Q== X-Google-Smtp-Source: AGHT+IEFvJMwtbC2qA1hrhSyqEbBOlj9S/WB0A5Ne9EveISmD2Fy+ngxQ6PuxWVSb3UKNzYz23fd8E5vGR776w== X-Received: from slicestar.c.googlers.com ([fda3:e722:ac3:cc00:4f:4b78:c0a8:20a1]) (user=davidgow job=sendgmr) by 2002:a05:690c:84:b0:646:3ef4:6ad2 with SMTP id 00721157ae682-68964d49c8bmr3342287b3.9.1722671222680; Sat, 03 Aug 2024 00:47:02 -0700 (PDT) Date: Sat, 3 Aug 2024 15:46:41 +0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.46.0.rc2.264.g509ed76dc8-goog Message-ID: <20240803074642.1849623-2-davidgow@google.com> Subject: [PATCH] mm: Only enforce minimum stack gap size if it's sensible From: David Gow To: Alexandre Ghiti , Kees Cook , Luis Chamberlain , Russell King , Andrew Morton , Linus Walleij , Mark Rutland Cc: David Gow , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240803_004705_061984_E2A5335B X-CRM114-Status: GOOD ( 19.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org The generic mmap_base code tries to leave a gap between the top of the stack and the mmap base address, but enforces a minimum gap size (MIN_GAP) of 128MB, which is too large on some setups. In particular, on arm tasks without ADDR_LIMIT_32BIT, the STACK_TOP value is less than 128MB, so it's impossible to fit such a gap in. Only enforce this minimum if MIN_GAP < MAX_GAP, as we'd prefer to honour MAX_GAP, which is defined proportionally, so scales better and always leaves us with both _some_ stack space and some room for mmap. This fixes the usercopy KUnit test suite on 32-bit arm, as it doesn't set any personality flags so gets the default (in this case 26-bit) task size. This test can be run with: ./tools/testing/kunit/kunit.py run --arch arm usercopy --make_options LLVM=1 Fixes: dba79c3df4a2 ("arm: use generic mmap top-down layout and brk randomization") Signed-off-by: David Gow Reviewed-by: Kees Cook --- This is one possible fix for an issue with the usercopy_kunit suite (and, indeed, the KUnit user_alloc features) on 32-bit arm. The other options are to: - hack the KUnit allocation to force ADDR_LIMIT_32BIT or ADDR_COMPAT_LAYOUT; or - similarly, use an unlimited stack, which forces the legacy layout behind the scenes; or - adjust MIN_GAP based on either STACK_TOP or architecture. Of them, I made the arbitrary call that this was least hacky, but am happy to go with something else if someone who actually knows what's going on suggests it. (Also, does this issue actually mean some strange legacy binaries have been broken with an rlimit-ed stack for ages? Or am I missing something?) Cheers, -- David --- mm/util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/util.c b/mm/util.c index bd283e2132e0..baca6cafc9f1 100644 --- a/mm/util.c +++ b/mm/util.c @@ -463,7 +463,7 @@ static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack) if (gap + pad > gap) gap += pad; - if (gap < MIN_GAP) + if (gap < MIN_GAP && MIN_GAP < MAX_GAP) gap = MIN_GAP; else if (gap > MAX_GAP) gap = MAX_GAP;