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 5F1E1C4829E for ; Thu, 15 Feb 2024 17:20:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E06A88D0007; Thu, 15 Feb 2024 12:20:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D8E9C8D0001; Thu, 15 Feb 2024 12:20:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C2E918D0007; Thu, 15 Feb 2024 12:20:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id AB8D18D0001 for ; Thu, 15 Feb 2024 12:20:24 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 70263A10D0 for ; Thu, 15 Feb 2024 17:20:24 +0000 (UTC) X-FDA: 81794701968.15.BCB0D17 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf10.hostedemail.com (Postfix) with ESMTP id 95AB9C001C for ; Thu, 15 Feb 2024 17:20:22 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kGiczWag; spf=pass (imf10.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=andreyknvl@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=1708017622; 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=wsy/rTXATJpQPiJZK0atMbxDxFPdAPeYrtGGTVAUIDQ=; b=XQzKPfP2hHpRDrVUqCiul8bhWCDcceCsj7kXoO73lc+LqUa+uCQOBTVH0x/Qsa5YnFoSxN CGDgMLEQm0kIaLkqA3vU2qyuwGB6e3NhnkAG3uumLPLfa6Ua0M+wPJZNLHzxk4U5XUHA84 TRSLqAdy/fFmnusPgV3FWMZEam+kCVc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708017622; a=rsa-sha256; cv=none; b=hr7C2FHcKA2FeAxLgkFIUN8dydceRUPUH2Y8qPmhJdc4vuPEQYo+yt38LpZ6EiHjoIXqVp ZOZ4hTkR7fzmxHc70DiCCUb0Ba3gdtuxANgNJ7+7t0H9/ksYNzj0rIojCUmB7UC5uORG7Z +Jtn/2Ja9MOK0WBmMVCDwW/BQFXa0OM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kGiczWag; spf=pass (imf10.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-410e820a4feso12835425e9.1 for ; Thu, 15 Feb 2024 09:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708017621; x=1708622421; 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=wsy/rTXATJpQPiJZK0atMbxDxFPdAPeYrtGGTVAUIDQ=; b=kGiczWagFHgGJCIthLvt+I8tgL3k57UDG712tHMUVJgcIsA5eduCuAB6Z/eLbCPq8q HQPAsv2mXjXf4fs690N4D9vcCo0QP8xpGlsghV+CZeV0IDgWuyYEZUQhh9OBVy0JTPzt V6Gk4cDmkcZBEtNKbbbEyHZcC/P1+aBb698v6CEmSxXlNMBCCfVt0gI43YPkRqzj/ejg eK+6ruDMxWTO/OvploC7HQdUK3rSWZii+UL2dIbDCbHglSxhnDjE5e0quBiudoly/1S9 Fo2mslGO42rvt12nLDB+3bnWqwAxOFrBQ8KWFBkmuBmgrk/UwQYMcmOez7Q2XPkPnKmy nGAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708017621; x=1708622421; 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=wsy/rTXATJpQPiJZK0atMbxDxFPdAPeYrtGGTVAUIDQ=; b=VkDjd8yj5r8KQghjRiLnYswNcqgYKgrL66fMH9Q2n0MXbV08KnQv+exkYQVTwPEXR9 Sh7AKK6fk78M53CqUGnTtKvSGp+TBUEwjP7MfdJgf7awVfOHzZ3N3PMo7/UPyGDvA0J4 H3+pqJH17ms+MDmcu8UfUsd/m6Y0kLLe56dZNQiPn8nytlKOAj39YXopHRtoo+I7S8YE nAw1+grFNRZw4UvPwGTjD2OB38eWqtFGmWzOtKLW+hVf2Y4ou7O58DgcB7BtdHX8v/Hr gh7D/ZgjEbIg3Tz8g3ahdaveCiW066LM1rCcyHfpxb1D/WRVj/TsgiNX5g+LkbMozsXk Wphg== X-Forwarded-Encrypted: i=1; AJvYcCWb4VMv4ZMlpeLo/FOIusUEOFgQFrcjaMxAk/VyrozJxVSOGtJK7piUFegwXqvwlSbdGo9su6ffjOvK4LrH9LN6eqc= X-Gm-Message-State: AOJu0Yz9YcwgE9TLk6gBmC8Nsn+UMaiAGo1V7hEg5E9JXg+LYWCDx+Aj m6YNkYahs1jn2jDwz3gQVT8AgqenVJvlbaDd26pdyPXVp4fg5X1R0658oN4DdIgxePMnn/i1z2f OVKNL4twife1Pebl166mYoXZ5JMM= X-Google-Smtp-Source: AGHT+IEUOIxJBqoWo66OzIp5cdhGQrCTDIW6DasRu/uoFIPgTVgcYgVHEwYDnl87oHPnB5nHHtCF8ZGCMSsAEv4HISs= X-Received: by 2002:adf:fd42:0:b0:33c:e075:b075 with SMTP id h2-20020adffd42000000b0033ce075b075mr1938968wrs.33.1708017620752; Thu, 15 Feb 2024 09:20:20 -0800 (PST) MIME-Version: 1.0 References: <20240213033958.139383-1-bgray@linux.ibm.com> <37d83ab1b6c60b8d2a095aeeff3fe8fe68d3e9ce.camel@linux.ibm.com> In-Reply-To: <37d83ab1b6c60b8d2a095aeeff3fe8fe68d3e9ce.camel@linux.ibm.com> From: Andrey Konovalov Date: Thu, 15 Feb 2024 18:20:09 +0100 Message-ID: Subject: Re: [PATCH] kasan: guard release_free_meta() shadow access with kasan_arch_is_ready() To: Benjamin Gray Cc: kasan-dev@googlegroups.com, mpe@ellerman.id.au, ryabinin.a.a@gmail.com, glider@google.com, dvyukov@google.com, vincenzo.frascino@arm.com, akpm@linux-foundation.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 95AB9C001C X-Rspam-User: X-Stat-Signature: ybxub77pcy1n3nnrqbg43zqtyngyiy5o X-Rspamd-Server: rspam03 X-HE-Tag: 1708017622-715227 X-HE-Meta: U2FsdGVkX18JuO+GhmNR1JCErEbKmLn0iXrfbh0duKfVnht46amjEAzZrHDjHukCtJVVQd4heiBbPcAhlZhuJCg6REEWU24v+J0Kk8rl8gbvHYEO2cINsmFaujS8Z/2RtQlh2CElt1ehuQDh5lHIvNj7PJye78DWFxGZKFN6g+RZ5It9dAXT2q/L/rFACQ2ztyw9suQyMSVpHiXyEf2mk/3tYPij1ntUjdxYOhhv7HEVa2TTQDGRCeKhZfRrHwQcQxIr+EsOt5Rqe68hhgbVNZhny09Z2dvURs7L7tfJ6FaP7h+X5NOCYUHzpb5osefAHLGUqWUutpuG4JQ1eqfbf2TdoaC/iLv5DXOASTXs9sIE96IO11BFB4je8L0HKFmTxYrZPA0yka8cZP51ao9ooejGdj1PSWKoX2fee5IVmHzjnxX1pUEmF4xVLlHbPwdaTkEq8uz8ly3DkC9227uaqrNb9oqLPwcfd7FumxafHa8DaM3QlqdZQ5FcwnEOfy9NCclbZiQytVE+T7isXn1MNGjpcsBDMEnf8t7PuZpdyTvag2Lx0m830XaGZUg8jLMfTlQDOx1yn7yGpdELOA8zb06k9tWqkV6hbSkeJ+7W0vvxNM7jR9inMV/gZP8smaAmvaEOvrlwJJji+tXZ/oYWOE+MM+qfMTdudiElRN/CgG4qB6Zf+ISFG9QDCrMx+wET22/i9ZzJnYZP0bIAiHEn2xbdErD5S5GQU5kTNKSNd8H5uDKej69FB34sMtO3sSXo2XOGm3V6pVkM7noREKlfwrlTCWTpazfFwNHzB0DCZexA/1Ea4mvktSwsaIklrFndbJjK1sRj9LMyojoCxtvdJcDap7py+Tp6djyMPlUeka3sjS2611p7VNchZiQ3VxMigLIDdHGPgG1P6vBEv6BYaGrGmIw6umol4lCXKbok3Knfzx/Y4KN0ND11rP3fe+zWJmFPcxsnAuiZ+wJDke2 vZ0T4upa UlzBUzDLkPVUgQ6vuUQODkwLFTTCDsXyewz4X0ecnKuacvBJw8jTh3ABLyFQST+ocEjKMYiguHttpE29/2dSb4xeB/DAuJ5hiVPlyxuRtY3z7H034R0reEuKhMBFFfDepHDjqWD+4IHFCRbc2pwPfjep0YIuDoHHiuHPI8nLqb4fmRgM0UDlU7XlKLXrf5DZhuByTTxRjKuWWysBvChwseOSB2U7ttwMDHQUuf3qRa5001ivkrbXWLlOdu53kWklkC7F3bwK0G94ZVwcYQhLTDm1iAmWKqHb+L1XMOPVvzx7NjGmzs4XMvqqHaGrBvg2qZy4/cTQlyJZMT5zokWkhPbz1kQ4+uXhqbDRWOJ9PMgCjcA9asFaDdYijLZ1n64T9c6eBs0PpY7DuITd91uJ6velbw/HYv+tdrXJc2+KMYSGg9FOO6VfjEsS+qOR4V/e6ybxtpdbwGM57DYB2WzqPQ2b19dgK8vb7s4XmrZe+jhCCIFs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.064395, 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 Thu, Feb 15, 2024 at 12:25=E2=80=AFAM Benjamin Gray wrote: > > > We can also add something like CONFIG_ARCH_HAS_KASAN_FLAG_ENABLE and > > only use a static branch only on those architectures where it's > > required. Perhaps CONFIG_ARCH_USES_KASAN_ENABLED would be a better name. > That works too, PowerPC should only need a static branch when > CONFIG_KASAN is enabled. > > Loongarch is also a kasan_arch_is_ready() user though, so I'm not sure > if they'd still need it for something? And UM as well. We can start with a change that makes kasan_flag_enabled and kasan_enabled() work for the Generic mode, define a kasan_init_generic() function that switches kasan_flag_enabled (and prints the "KernelAddressSanitizer initialized" message?), and then call kasan_init_generic() from kasan_init() in the arch code (perhaps even for all arches to unify the "initialized" message?). And then we can ask Loongarch and UM people to test the change. Both Loongarch and UM define kasan_arch_is_ready() as the value of their global enable flags, which they switch in kasan_init(). So I would think using kasan_enabled() should just work (minding the metadata-related parts). > > What was this data access? Is this something we need to fix in the > > mainline? > > I don't believe so (though I spent a while debugging it before I > realised I had introduced it by changing kasan_enabled() dynamically). > > In kasan_cache_create() we unconditionally allocate a metadata buffer, > but the kasan_init_slab_obj() call to initialise it is guarded by > kasan_enabled(). But later parts of the code only check the presence of > the buffer before using it, so bad things happen if kasan_enabled() > later turns on (I was getting some error about invalid lock state). Ah, makes sense. Yeah, these metadata init functions should work even before kasan_flag_enabled is switched on then.