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=-14.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,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 9D88DC4363A for ; Fri, 30 Oct 2020 02:50:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 15CB4207EA for ; Fri, 30 Oct 2020 02:50:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="BFe+B8BC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 15CB4207EA 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 A1A726B0083; Thu, 29 Oct 2020 22:50:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A2C96B0085; Thu, 29 Oct 2020 22:50:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86A296B0087; Thu, 29 Oct 2020 22:50:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0206.hostedemail.com [216.40.44.206]) by kanga.kvack.org (Postfix) with ESMTP id 5748F6B0083 for ; Thu, 29 Oct 2020 22:50:27 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id F3AB3181AEF10 for ; Fri, 30 Oct 2020 02:50:26 +0000 (UTC) X-FDA: 77427063294.07.shirt90_18053cf27292 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id D92FD1803F9AA for ; Fri, 30 Oct 2020 02:50:26 +0000 (UTC) X-HE-Tag: shirt90_18053cf27292 X-Filterd-Recvd-Size: 6056 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Fri, 30 Oct 2020 02:50:26 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id v6so5911489lfa.13 for ; Thu, 29 Oct 2020 19:50:26 -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=QNSPCer1UJ6z9F+/9uXH8Oi4/yk+Ks5V2RaOCBC84Eg=; b=BFe+B8BCoqJXOuPrpuUVE7tdWQlIyZYKI6lgD8DdEJw7Fw7hxMafsAOgYEEVUe5bMr ZtqYvhzx1+ZmfCDBA3ge5JqRcpP2Zak/C8k4r+2wYwfndyMxKdBlzpKeMjhev14391YM 30LPsApdaI+vyC/hB8MQAfIaeOBByfXpjIh7XQjg6jzfzBzqzJ0fsxCPtOVt4dqaKlDE HFh9yd5znlsNeBPMJ+7Dg6RUzHxECikYBo4O3jD0b3XIxVaSNyT1Ku/8qSTAuyV0Ruie kNqbSQemBnpsFfIbXPk9LapxT/rFS623ucGXQn8/g3QBY1QuWC/8uU1/Xy9c+HCRrjAe e6Ew== 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=QNSPCer1UJ6z9F+/9uXH8Oi4/yk+Ks5V2RaOCBC84Eg=; b=s8ZnBaTllF4k/cFMQJlLlOSzGUAF/qgOGMqgtGdxIL2OXMXXG4WE9I8+kynbfb7Y2S V5ypH02OWAVRe64KENQAVFvOpYNfxtQv1B8d90Uwj6BwYUQgDNa57h0iVaT11oiPtxov EpkiDPgj63ZUcrUlaBHDQbwnZfmjnlwBGaSfmXfQk9ddY0fUA3fRQkd4yvsm0OdHb7En txMi/JYMo2c+XKw+605efvpY5XNfouojfMuHxzdAWMPWbX6oBJZtmDc/BqzgmjpW1Y4h kwFWZvCKL41/oCpUcvSCFTu2DJwqo4DcpovZ5taKADRIrqgQme/jwAYjCUEIT7H3nGoL 6C8Q== X-Gm-Message-State: AOAM531ZTRVIkGJkQd4KDv0C4VAFpUkS0JErMsFv2uPS/H3vTpb0HAc2 MKnzTGfe+FvWwOTuv+r5i+slpZPvfrfHSMGmdHEvgg== X-Google-Smtp-Source: ABdhPJzZDsWksombIayWMw7AEBuFa0vS0U2LyAiDnt6EXpu4yfnzFsa5p0ZxrTmOgj8g6qibOehM8hv/+sRQ0s+89sc= X-Received: by 2002:a19:e308:: with SMTP id a8mr12857lfh.573.1604026224931; Thu, 29 Oct 2020 19:50:24 -0700 (PDT) MIME-Version: 1.0 References: <20201029131649.182037-1-elver@google.com> <20201029131649.182037-9-elver@google.com> In-Reply-To: <20201029131649.182037-9-elver@google.com> From: Jann Horn Date: Fri, 30 Oct 2020 03:49:58 +0100 Message-ID: Subject: Re: [PATCH v6 8/9] kfence: add test suite 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 , joern@purestorage.com, 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 Thu, Oct 29, 2020 at 2:17 PM Marco Elver wrote: > Add KFENCE test suite, testing various error detection scenarios. Makes > use of KUnit for test organization. Since KFENCE's interface to obtain > error reports is via the console, the test verifies that KFENCE outputs > expected reports to the console. [...] > diff --git a/mm/kfence/kfence_test.c b/mm/kfence/kfence_test.c [...] > +static void *test_alloc(struct kunit *test, size_t size, gfp_t gfp, enum allocation_policy policy) > +{ > + void *alloc; > + unsigned long timeout, resched_after; [...] > + /* > + * 100x the sample interval should be more than enough to ensure we get > + * a KFENCE allocation eventually. > + */ > + timeout = jiffies + msecs_to_jiffies(100 * CONFIG_KFENCE_SAMPLE_INTERVAL); > + /* > + * Especially for non-preemption kernels, ensure the allocation-gate > + * timer has time to catch up. > + */ > + resched_after = jiffies + msecs_to_jiffies(CONFIG_KFENCE_SAMPLE_INTERVAL); > + do { [...] > + if (time_after(jiffies, resched_after)) > + cond_resched(); You probably meant to recalculate resched_after after the call to cond_resched()? > + } while (time_before(jiffies, timeout)); > + > + KUNIT_ASSERT_TRUE_MSG(test, false, "failed to allocate from KFENCE"); > + return NULL; /* Unreachable. */ > +} [...] > +/* > + * KFENCE is unable to detect an OOB if the allocation's alignment requirements > + * leave a gap between the object and the guard page. Specifically, an > + * allocation of e.g. 73 bytes is aligned on 8 and 128 bytes for SLUB or SLAB > + * respectively. Therefore it is impossible for the allocated object to adhere > + * to either of the page boundaries. Should this be "to the left page boundary" instead of "to either of the page boundaries"? > + * However, we test that an access to memory beyond the gap result in KFENCE *results > + * detecting an OOB access. > + */ > +static void test_kmalloc_aligned_oob_read(struct kunit *test)