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=-23.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham 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 77F82C433E6 for ; Tue, 12 Jan 2021 22:00:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 43449221FF for ; Tue, 12 Jan 2021 22:00:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437241AbhALVeR (ORCPT ); Tue, 12 Jan 2021 16:34:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2436636AbhALUGJ (ORCPT ); Tue, 12 Jan 2021 15:06:09 -0500 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D020C061786 for ; Tue, 12 Jan 2021 12:05:29 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id y12so2305221pji.1 for ; Tue, 12 Jan 2021 12:05:29 -0800 (PST) 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=zL6WgU5Xs4gBKlOeTyyYJxfsUDm2s7KXGqsTMwbacGQ=; b=wPsXp3Ms+9EG1G2s8Vph8Xwk1B8VZYND0uude8zcWLUg4+owazggV+vpjAf+tzTgdC W8z3dx3wqpnqzj+clMUqZ5w32P12JqYLB7GGqKQS20jYZUYXLbBPX+nWFcoS+ytaCgfa ps9VzSsZn4MKGUaHATXr6ILJ1S41IjhM9JP1Z6sZj2SmTTb1Y0zl640U45qm+Bo5Hu4M U/ysBYw5lPnASZUCeG4IppqXWhMinJNkXvYVH8dIrQQBUgOFXvVB1SFZuyquAdrPSXXZ IIXjjQrJrG1GtenX2Ohzzx4r5y0UQTJQV50f04e+n/urAEsIXZxxDOldEga5JSxuu6WB U+MA== 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=zL6WgU5Xs4gBKlOeTyyYJxfsUDm2s7KXGqsTMwbacGQ=; b=BRwt+hZyOfyme2uRY+3m+Zl9zGLUi0Dq5Hw2AFu3mH6VuWNNf+G159BizyCS0XZ8Oq nXzbtp2W1xleMS7Z9a2jY7k4+xOIREFbzX9Ohb6ZGmr6DibbioAtLFVPeLxAkyuF1o/+ 7o3ZiY7ZdIMquPaHhR5eN5PWIYL2k5TwX7dEL9Z18EksuRx6ZgmNnSo9ocE5t6CzACht Cg5DYsCSyV6IYNa4nhDn8kIKwfa9l7Ypz6k3NCuFEgkz1Y5opuw+CYmeM7UKAqH0HMM/ XaqcPolBoeDld8Df/awUlLXo0rKF4QlZpUZEg/wOe8RtMnPnkzf9wP9mXCyBMFtYpnK1 tILQ== X-Gm-Message-State: AOAM531sbW5b+6Etqymg1NhnLBpQUCcyFlMwUhO2grV5K904SfEe07kJ qm/Mq2KE9hMETxjveOIl7oMXWceGAw9SMySpQRy7gQ== X-Google-Smtp-Source: ABdhPJwYQTFzqikue18gpW9umL0WcFvbyoNK1QEUuE6kEZf85DaGVaLKgmWEvox10SpVBdo9Ni4n/BW0mjJiejzq8OY= X-Received: by 2002:a17:90b:1087:: with SMTP id gj7mr814111pjb.41.1610481928938; Tue, 12 Jan 2021 12:05:28 -0800 (PST) MIME-Version: 1.0 References: <9a4f47fe8717b4b249591b307cdd1f26c46dcb82.1609871239.git.andreyknvl@google.com> In-Reply-To: From: Andrey Konovalov Date: Tue, 12 Jan 2021 21:05:18 +0100 Message-ID: Subject: Re: [PATCH 08/11] kasan: adopt kmalloc_uaf2 test to HW_TAGS mode To: Marco Elver Cc: Catalin Marinas , Vincenzo Frascino , Dmitry Vyukov , Alexander Potapenko , Andrew Morton , Will Deacon , Andrey Ryabinin , Evgenii Stepanov , Branislav Rankov , Kevin Brodsky , kasan-dev , Linux ARM , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 12, 2021 at 2:39 PM Marco Elver wrote: > > On Tue, Jan 05, 2021 at 07:27PM +0100, Andrey Konovalov wrote: > > In the kmalloc_uaf2() test, the pointers to the two allocated memory > > blocks might be the same, and the test will fail. With the software > > tag-based mode, the probability of the that happening is 1/254, so it's > > hard to observe the failure. For the hardware tag-based mode though, > > the probablity is 1/14, which is quite noticable. > > > > Allow up to 4 attempts at generating different tags for the tag-based > > modes. > > > > Signed-off-by: Andrey Konovalov > > Link: https://linux-review.googlesource.com/id/Ibfa458ef2804ff465d8eb07434a300bf36388d55 > > --- > > lib/test_kasan.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/lib/test_kasan.c b/lib/test_kasan.c > > index b5077a47b95a..b67da7f6e17f 100644 > > --- a/lib/test_kasan.c > > +++ b/lib/test_kasan.c > > @@ -375,7 +375,9 @@ static void kmalloc_uaf2(struct kunit *test) > > { > > char *ptr1, *ptr2; > > size_t size = 43; > > + int counter = 0; > > > > +again: > > ptr1 = kmalloc(size, GFP_KERNEL); > > KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr1); > > > > @@ -384,6 +386,13 @@ static void kmalloc_uaf2(struct kunit *test) > > ptr2 = kmalloc(size, GFP_KERNEL); > > KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr2); > > > > + /* > > + * For tag-based KASAN ptr1 and ptr2 tags might happen to be the same. > > + * Allow up to 4 attempts at generating different tags. > > + */ > > + if (!IS_ENABLED(CONFIG_KASAN_GENERIC) && ptr1 == ptr2 && counter++ < 4) > > + goto again; > > + > > Why do we even need a limit? Why not retry until ptr1 != ptr2? Then the test will hang if it's failing. Let's do up to 16 attempts, it should be more than enough in practice. Thanks!