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 D76DBC433F5 for ; Mon, 20 Dec 2021 17:19:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F4C96B0074; Mon, 20 Dec 2021 12:19:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A3FE6B0075; Mon, 20 Dec 2021 12:19:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46B346B0078; Mon, 20 Dec 2021 12:19:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0087.hostedemail.com [216.40.44.87]) by kanga.kvack.org (Postfix) with ESMTP id 364556B0074 for ; Mon, 20 Dec 2021 12:19:50 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E5F5A8249980 for ; Mon, 20 Dec 2021 17:19:49 +0000 (UTC) X-FDA: 78938834898.30.4AF105A Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) by imf08.hostedemail.com (Postfix) with ESMTP id 93471160039 for ; Mon, 20 Dec 2021 17:19:43 +0000 (UTC) Received: by mail-oi1-f179.google.com with SMTP id r26so16808330oiw.5 for ; Mon, 20 Dec 2021 09:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ilrvhX4adeXJIaCdTInuQBtNPjTZg76k+bbb32ZDvfA=; b=oVrue8OuxpTW/U9MiEZXd206fFvNx2LFKTdAoPLpR04XIqpoRSOCQBDhBDBFg3UTt2 LP0voOok9+a4GuL3lnP5oOWkacYA1uiCt5ognuYsA47nsQrIGh9ks/+8HshfmQQdU80Y KYeX2tZygCz1P7LLQb7wYbcWZGzk53UoHaKda3ZUUIvD8YrEnntY1MZZb4yhHzTwaEvU kDFBVffdzS/N12ZkQDfwURwQOPcSKqPwVjpiOrjGzAU9sXSf76qiAjg5ITaDy5gafYyf MM/2lYC+JLHSblgK7p2up7gDBiYxxezefd4TXxht7FUgmSLYI/wYmsC/5Wly6J3eTEKK vdhg== 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=ilrvhX4adeXJIaCdTInuQBtNPjTZg76k+bbb32ZDvfA=; b=VTbRSMmyEeIALJu0V/ngUAhQHpfA5//eVzY+0RLSqtZDWlILmG3gHtSrYxZVA4T44r kxrmkVDWDV0cvW9tXVImVd3R0zzFoWKWj/8P3O5DfW8SQ7MGS/53mD2GpMksEOhu3elD 1hhkZDGSRu1CAWRmp3uP+qxXs3AR+i5g3Ljgc/tNLR1A5tJJkQPleSnn3pgViyxPdMiQ ro41BKCeY1tMI3x7ffevCBwKrujmcasRcIBTHVv42R65MOsSkyX6liD85X7lAc9eklwM 2v90qZqjpi8s+WbVT+TBiiNDMA6SZMmg8gjHtBf6ILHB0YT2+It9KSXnyMCtsXqIwy/k zeiw== X-Gm-Message-State: AOAM532rlMWhAxGsfOuLNddJHziH6wBx+uARE9brD4dBojYkr8ouWbdD GhdyfHJ3Rja+kXp+0UP9XIie+10DU3ddOxTx1+lquQ== X-Google-Smtp-Source: ABdhPJzVPHQTSd85vReZAhk5/xhn8anCH0sWrUGKxyOTm4NJlj66RiGLv/9Ir2GntQIPKa0bOfugKOf4tiMhXK9mc8Y= X-Received: by 2002:aca:af50:: with SMTP id y77mr13111576oie.134.1640020788502; Mon, 20 Dec 2021 09:19:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Marco Elver Date: Mon, 20 Dec 2021 18:19:37 +0100 Message-ID: Subject: Re: [PATCH] kasan: fix quarantine conflicting with init_on_free To: Andrey Konovalov Cc: andrey.konovalov@linux.dev, Alexander Potapenko , Andrew Morton , Dmitry Vyukov , Andrey Ryabinin , kasan-dev , Linux Memory Management List , LKML , Andrey Konovalov Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: i6fuhhj8j9fq38zd5jaxwm6f1fiaem8f X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 93471160039 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=oVrue8Ou; spf=pass (imf08.hostedemail.com: domain of elver@google.com designates 209.85.167.179 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1640020783-258550 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 Mon, 20 Dec 2021 at 18:16, Andrey Konovalov wrote: > > On Mon, Dec 20, 2021 at 6:07 PM Marco Elver wrote: > > > > On Mon, 20 Dec 2021 at 17:37, wrote: > > > > > > From: Andrey Konovalov > > > > > > KASAN's quarantine might save its metadata inside freed objects. As > > > this happens after the memory is zeroed by the slab allocator when > > > init_on_free is enabled, the memory coming out of quarantine is not > > > properly zeroed. > > > > > > This causes lib/test_meminit.c tests to fail with Generic KASAN. > > > > > > Zero the metadata when the object is removed from quarantine. > > > > > > Fixes: 6471384af2a6 ("mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options") > > > Signed-off-by: Andrey Konovalov > > > --- > > > mm/kasan/quarantine.c | 11 +++++++++++ > > > 1 file changed, 11 insertions(+) > > > > > > diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c > > > index 587da8995f2d..2e50869fd8e2 100644 > > > --- a/mm/kasan/quarantine.c > > > +++ b/mm/kasan/quarantine.c > > > @@ -132,11 +132,22 @@ static void *qlink_to_object(struct qlist_node *qlink, struct kmem_cache *cache) > > > static void qlink_free(struct qlist_node *qlink, struct kmem_cache *cache) > > > { > > > void *object = qlink_to_object(qlink, cache); > > > + struct kasan_free_meta *meta = kasan_get_free_meta(cache, object); > > > unsigned long flags; > > > > > > if (IS_ENABLED(CONFIG_SLAB)) > > > local_irq_save(flags); > > > > > > + /* > > > + * If init_on_free is enabled and KASAN's free metadata is stored in > > > + * the object, zero the metadata. Otherwise, the object's memory will > > > + * not be properly zeroed, as KASAN saves the metadata after the slab > > > + * allocator zeroes the object. > > > + */ > > > + if (slab_want_init_on_free(cache) && > > > + cache->kasan_info.free_meta_offset == 0) > > > + memset(meta, 0, sizeof(*meta)); > > > > memzero_explicit() > > > > although in this case it probably doesn't matter much, because AFAIK > > memzero_explicit() only exists to prevent the compiler from eliding > > the zeroing. Up to you. > > I've thought about using memzero_explicit(), but the rest of > init_on_alloc/free code uses memset(0) so I decided to use it as well. > If we decide to switch to memzero_explicit(), it makes sense to do it > everywhere. memzero_explicit() is newer than those existing memset(0) -- new code should probably start using it. So I'd opt for just using it here. Who knows what other optimizations future compilers may come up with.