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 X-Spam-Level: X-Spam-Status: No, score=-9.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A9C4C433E2 for ; Fri, 11 Sep 2020 13:02:47 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0703E22229 for ; Fri, 11 Sep 2020 13:02:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="S7T8diB4"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="T96RFKKM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0703E22229 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=cVOdpe0H5w4rAMonmg2+5I/4ZQbBRbbT6SitNN9XEWs=; b=S7T8diB4d1IL3WgNCB24C+CLy cgvOf6JxlwtgnUJQmNxl5C82O4eHfEvNGq8XKo26HlbOmk6tUWbeXmEGGD9JbRfDAy1Nxl9Noc4E9 R35PiHrwBCQNV0EyxKhXFYZFSgB19h/6pXvA9pz/cxMwyVoLmV7hIUmtnC3UHPhFvbT6LICMtsmNQ b4BxXnhmzYxoiWqZTPrQR0quRsEJRyE84JMWJImsYOySCIOUlFd+yRUAu9a9I43GRIi2AL9DjLcb+ M0oDHIbKhuZo5HLO6ix6CZ7+nEWDxjyenL6T8onhDIF41+CyPO0z/NhKdkMyqFqvWclMzNLBZHY11 NSiEzcL7A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGifx-0007VP-AA; Fri, 11 Sep 2020 13:01:13 +0000 Received: from mail-ot1-x343.google.com ([2607:f8b0:4864:20::343]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGifs-0007Tn-9Y for linux-arm-kernel@lists.infradead.org; Fri, 11 Sep 2020 13:01:11 +0000 Received: by mail-ot1-x343.google.com with SMTP id a2so8218050otr.11 for ; Fri, 11 Sep 2020 06:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ge/FjJXhyj8+NsSSsvCMLGtUiAk37fA1+cTelebZ4Go=; b=T96RFKKMbfGXmGKQW/wQkQusFFYQX5igqwU6L75Yeso5+r11VBgv0lztFH9rNbHlY3 5B0LrTTcrBZveyQWzWcwQCKeRcyEas+n8CGz3zVLjk3BHBmngz6iniRoFzLHyeCEKgD0 SfihZ41/sKpTvQWRFJLJgc9OiULTEBppsdBLOZxSHyOPU/g9QcvvDXQh4dY//h83F68D ESzkFo2LP1uYXPiZlMAQQce8uhNDJFIRPkcEU8JQ+J90kOfx32MrFwTnj/mS1FW0RD1e qGrx8cYDqjBlz9uoLUveNlE+9hLQk8moh/ndBUm2Yp5Ev3Kn7jiVpo/Fnwdz/WXss1W+ TXHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ge/FjJXhyj8+NsSSsvCMLGtUiAk37fA1+cTelebZ4Go=; b=eAYlH0cxs3vYsjxYKjtXJyFFl6ro4xGlXcWqMxWUhbfAjpBt9Ruz7poy8/Th8ZlYsj nBLqoZqfYy5BfSnhgTgWCIx2rapwEkcTHQAadVg9cKcawoqG6Ll4BUC8n/5PP8GqUiwZ hW4jEIVmym1eTk3Q8dblIgJ03bUV9TDmDYdkO0Qpyst9pv1BvjAEW/nTVJpxnN+4GwmE wKKUzt/+MukT38Jb3vnDEhETAEN6FHca3Wu9bnD67x/Y/FdPPRqyD263E2FOUQ7NmWzv hu/Btq2D9ghbG1ty3dvUNi3YbAFGzzTuwO7aUgJz0IldERYJUZJ7jBWxZtbLkDJDwjd1 YLug== X-Gm-Message-State: AOAM533eSg6JTG3+LAYLokc9eiGCagArPBJBjOmDf9yv1Dtdq1Zw+7Qo 7Jk91gf8JeJ4mQvoZXFs6lX6eNoB0zsyN+3JohaACw== X-Google-Smtp-Source: ABdhPJyvnEkxpzeJQj2l5oqacEmEr9jCCxehUw6cPnNOvxF93kxRylc4qW/tdBx2vsUZCsc/aeHXDTxenucOjpbTbWU= X-Received: by 2002:a9d:758b:: with SMTP id s11mr1038835otk.251.1599829266141; Fri, 11 Sep 2020 06:01:06 -0700 (PDT) MIME-Version: 1.0 References: <20200907134055.2878499-1-elver@google.com> <20200907134055.2878499-7-elver@google.com> In-Reply-To: From: Marco Elver Date: Fri, 11 Sep 2020 15:00:54 +0200 Message-ID: Subject: Re: [PATCH RFC 06/10] kfence, kasan: make KFENCE compatible with KASAN To: Dmitry Vyukov X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200911_090108_480592_394849AE X-CRM114-Status: GOOD ( 31.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , "open list:DOCUMENTATION" , Peter Zijlstra , Catalin Marinas , Dave Hansen , Linux-MM , Eric Dumazet , Alexander Potapenko , "H. Peter Anvin" , Christoph Lameter , Will Deacon , Jonathan Corbet , the arch/x86 maintainers , kasan-dev , Ingo Molnar , David Rientjes , Andrey Ryabinin , Kees Cook , "Paul E. McKenney" , Jann Horn , Andrey Konovalov , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , Andrew Morton , Linux ARM , Greg Kroah-Hartman , LKML , Pekka Enberg , Qian Cai , Joonsoo Kim Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 11 Sep 2020 at 09:05, Dmitry Vyukov wrote: > > On Mon, Sep 7, 2020 at 3:41 PM Marco Elver wrote: > > > > From: Alexander Potapenko > > > > We make KFENCE compatible with KASAN for testing KFENCE itself. In > > particular, KASAN helps to catch any potential corruptions to KFENCE > > state, or other corruptions that may be a result of freepointer > > corruptions in the main allocators. > > > > To indicate that the combination of the two is generally discouraged, > > CONFIG_EXPERT=y should be set. It also gives us the nice property that > > KFENCE will be build-tested by allyesconfig builds. > > > > Co-developed-by: Marco Elver > > Signed-off-by: Marco Elver > > Signed-off-by: Alexander Potapenko > > --- > > lib/Kconfig.kfence | 2 +- > > mm/kasan/common.c | 7 +++++++ > > 2 files changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/lib/Kconfig.kfence b/lib/Kconfig.kfence > > index 7ac91162edb0..b080e49e15d4 100644 > > --- a/lib/Kconfig.kfence > > +++ b/lib/Kconfig.kfence > > @@ -10,7 +10,7 @@ config HAVE_ARCH_KFENCE_STATIC_POOL > > > > menuconfig KFENCE > > bool "KFENCE: low-overhead sampling-based memory safety error detector" > > - depends on HAVE_ARCH_KFENCE && !KASAN && (SLAB || SLUB) > > + depends on HAVE_ARCH_KFENCE && (!KASAN || EXPERT) && (SLAB || SLUB) > > depends on JUMP_LABEL # To ensure performance, require jump labels > > select STACKTRACE > > help > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c > > index 950fd372a07e..f5c49f0fdeff 100644 > > --- a/mm/kasan/common.c > > +++ b/mm/kasan/common.c > > @@ -18,6 +18,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -396,6 +397,9 @@ static bool __kasan_slab_free(struct kmem_cache *cache, void *object, > > tagged_object = object; > > object = reset_tag(object); > > > > + if (is_kfence_address(object)) > > + return false; > > Is this needed? > At least in the slab patch I see that we do : > > if (kfence_free(objp)) { > kmemleak_free_recursive(objp, cachep->flags); > return; > } > > before: > > /* Put the object into the quarantine, don't touch it for now. */ /* > Put the object into the quarantine, don't touch it for now. */ > if (kasan_slab_free(cachep, objp, _RET_IP_)) if > (kasan_slab_free(cachep, objp, _RET_IP_)) > return; return; > > > If it's not supposed to be triggered, it can make sense to replace > with BUG/WARN. It is required for SLUB. For SLAB, it seems it might not be necessary. Making the check in kasan/common.c conditional on the allocator seems ugly, so I propose we keep it there. Thanks, -- Marco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel