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 2C7C1C433F5 for ; Mon, 6 Dec 2021 21:09:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ACFBC6B0088; Mon, 6 Dec 2021 16:09:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A7F946B0089; Mon, 6 Dec 2021 16:09:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91FA66B008A; Mon, 6 Dec 2021 16:09:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0036.hostedemail.com [216.40.44.36]) by kanga.kvack.org (Postfix) with ESMTP id 833A66B0088 for ; Mon, 6 Dec 2021 16:09:21 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 4837A18105253 for ; Mon, 6 Dec 2021 21:09:11 +0000 (UTC) X-FDA: 78888609702.23.56A9024 Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by imf03.hostedemail.com (Postfix) with ESMTP id E5CAA20005 for ; Mon, 6 Dec 2021 21:09:10 +0000 (UTC) Received: by mail-io1-f50.google.com with SMTP id q72so9950007iod.12 for ; Mon, 06 Dec 2021 13:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eOK4K4S7Jgnn22bwENxP9eeLDVw5lq+Zz6heR9P+gtQ=; b=CD1fMPDEKBCxndODtqRsbXTz3vws2TAkx518ckSyqOK0qinOz2lWs7dwdfPUR2Q96f 8D0zmV+ENSpmSX3DTg6oqAeda2v9twolMxe/Cc2OnzpxnrfuLzpWNEsx5zRTHX3Ul6kO XN/1bRJbmXQDRL0+XwX3i+aHPRHaM2ecnkGkOr7tYnf9cyoVDuN4/sZHeP7UCa2duFwK TKb41SQNNXZyr5CyMsFrngHhx7foY6Kxd2AHOmX1LExIXBLyP3eAxgH3gIsjI7cdFKON H563Iu6PgFxTct20MCfMEKONwoYLAZ3k+hPvEP0GG2gbSAvB3HnzLRLs8nJdtk9xiJC3 mY/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eOK4K4S7Jgnn22bwENxP9eeLDVw5lq+Zz6heR9P+gtQ=; b=CTbR5/yWB+TBygeVe+m1E6hNEkPbcLrCtS2jKHDCYMa/Cjaz/L+N3XHfgCcpZV8HLD KPkel7daAakTViNWxv+w68y4Xjs9Lg2FY6qplFp7S5CLQoBjESbajJPtZr0mAAxPYnFE C50nj4OPc8XfHA6r+U0uBa5cEiUJbCFrZoIhWq1ZUPjFJmYwtNu3vjbIwwVRmLV5bGtD L8VjU+mPxxabFCD8ccZn9vtEmY5oD4VQk5Xf1UKrUrT6pUvvm2ISsPblIkXhzjh7bKxe Gl0dzjT1riV8acsAI2BoIrdFCQE3FXIrbSz9m1UxoPbHpEobKY/C2H/TimnHZt5t+z5K F/8A== X-Gm-Message-State: AOAM532+6sL926eMW3G3ljw9hLyTLpTrrDaVFRe7mpXiLD3lxSsA/SRt ORldKsEXLNFJvzSkCqIbr/o/sVtaosrW0uEqEJ+7plj3Wtk= X-Google-Smtp-Source: ABdhPJw9EkmCf6QkZW91s5gMVFfWkYgjJogZWLnXjuDYz8eTQxFEDEt9uCWBrQjtqwa7QBLraFvVdJghV1GRrBt3u5I= X-Received: by 2002:a5e:d502:: with SMTP id e2mr38326764iom.118.1638824950346; Mon, 06 Dec 2021 13:09:10 -0800 (PST) MIME-Version: 1.0 References: <4fbc6668845e699bf708aee5c11ad9fd012d4dcd.1638308023.git.andreyknvl@google.com> In-Reply-To: From: Andrey Konovalov Date: Mon, 6 Dec 2021 22:08:59 +0100 Message-ID: Subject: Re: [PATCH 21/31] kasan, fork: don't tag stacks allocated with vmalloc To: Marco Elver Cc: andrey.konovalov@linux.dev, Alexander Potapenko , Vincenzo Frascino , Catalin Marinas , Peter Collingbourne , Dmitry Vyukov , kasan-dev , Andrew Morton , Linux Memory Management List , Will Deacon , Linux ARM , Evgenii Stepanov , LKML , Andrey Konovalov Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E5CAA20005 X-Stat-Signature: ypdnf4un6zirejiu4xb7dm9k9bxo6ekp Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=CD1fMPDE; spf=pass (imf03.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1638824950-586152 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: On Thu, Dec 2, 2021 at 3:28 PM Marco Elver wrote: > > On Tue, Nov 30, 2021 at 11:07PM +0100, andrey.konovalov@linux.dev wrote: > > From: Andrey Konovalov > > > > Once tag-based KASAN modes start tagging vmalloc() allocations, > > kernel stacks will start getting tagged if CONFIG_VMAP_STACK is enabled. > > > > Reset the tag of kernel stack pointers after allocation. > > > > For SW_TAGS KASAN, when CONFIG_KASAN_STACK is enabled, the > > instrumentation can't handle the sp register being tagged. > > > > For HW_TAGS KASAN, there's no instrumentation-related issues. However, > > the impact of having a tagged SP pointer needs to be properly evaluated, > > so keep it non-tagged for now. > > Don't VMAP_STACK stacks have guards? So some out-of-bounds would already > be caught. True, linear out-of-bounds accesses are already caught. > What would be the hypothetical benefit of using a tagged stack pointer? > Perhaps wildly out-of-bounds accesses derived from stack pointers? Yes, that's the case that comes to mind. > I agree that unless we understand the impact of using a tagged stack > pointers, it should remain non-tagged for now. Ack. I'll file a KASAN bug for this when the series is merged. > > Note, that the memory for the stack allocation still gets tagged to > > catch vmalloc-into-stack out-of-bounds accesses. > > Will the fact it's tagged cause issues for other code? I think kmemleak > already untags all addresses it scans for pointers. Anything else? Tagging stack memory shouldn't cause any stability issues like conflicts with kmemleak. Tagging memory but not the pointers is not worse than leaving memory tags uninitialized/random with regards to this kind of issues. Thanks!