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=-17.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL 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 0630AC4363A for ; Fri, 30 Oct 2020 15:09:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 71C7E208B6 for ; Fri, 30 Oct 2020 15:09:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GJxiwN9x" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 71C7E208B6 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 805006B005C; Fri, 30 Oct 2020 11:09:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B5496B0074; Fri, 30 Oct 2020 11:09:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67CEE6B0075; Fri, 30 Oct 2020 11:09:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0093.hostedemail.com [216.40.44.93]) by kanga.kvack.org (Postfix) with ESMTP id 37EED6B005C for ; Fri, 30 Oct 2020 11:09:26 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CDBED1F1B for ; Fri, 30 Oct 2020 15:09:25 +0000 (UTC) X-FDA: 77428925490.04.death30_13062e627297 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id AD7C18005A70 for ; Fri, 30 Oct 2020 15:09:25 +0000 (UTC) X-HE-Tag: death30_13062e627297 X-Filterd-Recvd-Size: 6811 Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Fri, 30 Oct 2020 15:09:24 +0000 (UTC) Received: by mail-lf1-f66.google.com with SMTP id 141so8311386lfn.5 for ; Fri, 30 Oct 2020 08:09:24 -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=Mk8TOBtLAUSh5UUmmftefVTpJAKNzTPUbZbR4xmTmm4=; b=GJxiwN9xabxRUEX1wI54H5lalSd1TYmvurtYqc/M2fA6V8U33bHNZ9KUnm+NrEFIZC Qrvcf8Oz1kmgZNU8G9hQ+3LL+ggO/PwDnFadE0BF68AW4sCZ0neyXtjFVi1hvLP2jw7o +tMXm8/POQ6ky6KAGphB5Uqn9dvqIRhiRBJegWSiGd9F0gAwKolszqsF6awnzU/IOT89 CBp89samOLM2uSJ4eB+cN7lZ/Hqu00LAQlRIY8YNBjayjS3ZLFFpVYVGo12j6uLwDEpR lWIWKskV5OFyjvLzv+TFVnFJOmKD/NODIpy3k5jGGi34kLl4uTFGiR9+v0q/Kqcx+q0W QaHA== 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=Mk8TOBtLAUSh5UUmmftefVTpJAKNzTPUbZbR4xmTmm4=; b=mvDgM/q8eEY/YVA7PjcTG+fQJxRn/goMHiIORPm8iTFHX3phN8QXYxeRcB8adNqFM+ Uq7HvR4EIqIY7pmBtvqNxILPCKer65Yi3ePFposYpNkHR8IZj3ZKV97nNrOBwXYH1Aad tcFbkCe2OaJKQcZAmcTAcnJQO42o8suEBgiD4yiUC5wsUTdCsnPovDS+dMXnFhRBVt3K nxCyQNfNVVGii29w+pqee3ybzL7lFmj1j+ZL6PLXKILK49X/JDnhLojVkkhxFR8qYfLY /ZoOv6Bo5VbOf3RdBjUmJVKgzlZftjoL95pbZtuxse3zX9KAGeydwqq6Hu3qdzG7FNOL S0cA== X-Gm-Message-State: AOAM532dfrK7RKpL1LhVlf+4SNlYrJgaprRzu04VdObptJD0sRen5vZg rNY6Tw/ZeiWvD2z8B7w5wefUVzc3c5l1jA49wyeTgQ== X-Google-Smtp-Source: ABdhPJwFpY6gAtBTRZBpckeKfkvLswlZHFXWkaX0WYhbn78B0G6kn/sPe6PzVY5TSbxBhNY24ss2alpqvzB69CmY910= X-Received: by 2002:a05:6512:1182:: with SMTP id g2mr1077748lfr.198.1604070563207; Fri, 30 Oct 2020 08:09:23 -0700 (PDT) MIME-Version: 1.0 References: <20201029131649.182037-1-elver@google.com> <20201029131649.182037-7-elver@google.com> In-Reply-To: From: Jann Horn Date: Fri, 30 Oct 2020 16:08:56 +0100 Message-ID: Subject: Re: [PATCH v6 6/9] kfence, kasan: make KFENCE compatible with KASAN To: Marco Elver Cc: Andrew Morton , Alexander Potapenko , "H . Peter Anvin" , "Paul E . McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christoph Lameter , Dave Hansen , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jonathan Cameron , Jonathan Corbet , Joonsoo Kim , =?UTF-8?Q?J=C3=B6rn_Engel?= , Kees Cook , Mark Rutland , Pekka Enberg , Peter Zijlstra , SeongJae Park , Thomas Gleixner , Vlastimil Babka , Will Deacon , "the arch/x86 maintainers" , "open list:DOCUMENTATION" , kernel list , kasan-dev , Linux ARM , Linux-MM Content-Type: text/plain; charset="UTF-8" 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 Fri, Oct 30, 2020 at 2:46 PM Marco Elver wrote: > On Fri, 30 Oct 2020 at 03:50, Jann Horn wrote: > > On Thu, Oct 29, 2020 at 2:17 PM Marco Elver wrote: > > > 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. > > > > > > Reviewed-by: Dmitry Vyukov > > > Co-developed-by: Marco Elver > > > Signed-off-by: Marco Elver > > > Signed-off-by: Alexander Potapenko > > > > Reviewed-by: Jann Horn > > Thanks! > > > with one nit: > > > > [...] > > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c > > [...] > > > @@ -141,6 +142,14 @@ void kasan_unpoison_shadow(const void *address, size_t size) > > > */ > > > address = reset_tag(address); > > > > > > + /* > > > + * We may be called from SL*B internals, such as ksize(): with a size > > > + * not a multiple of machine-word size, avoid poisoning the invalid > > > + * portion of the word for KFENCE memory. > > > + */ > > > + if (is_kfence_address(address)) > > > + return; > > > > It might be helpful if you could add a comment that explains that > > kasan_poison_object_data() does not need a similar guard because > > kasan_poison_object_data() is always paired with > > kasan_unpoison_object_data() - that threw me off a bit at first. > > Well, KFENCE objects should never be poisoned/unpoisoned because the > kasan_alloc and free hooks have a kfence guard, and none of the code > in sl*b.c that does kasan_{poison,unpoison}_object_data() should be > executed for KFENCE objects. > > But I just noticed that kernel/scs.c seems to kasan_poison and > unpoison objects, and keeps them poisoned for most of the object > lifetime. FWIW, I wouldn't be surprised if other parts of the kernel also ended up wanting to have in-object redzones eventually - e.g. inside skb buffers, which have a struct skb_shared_info at the end. AFAIU at the moment, KASAN can't catch small OOB accesses from these buffers because of the following structure. > I think we better add a kfence guard to > kasan_poison_shadow() as well. Sounds good.