Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp316268pxb; Wed, 13 Jan 2021 04:32:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJx3JCXg2TgSpzrgHcoC51WIU3kb2SrlCMos0KcL+welo5329KJSmRqIYx5KaQ9sbE7KU6pF X-Received: by 2002:a50:d6dc:: with SMTP id l28mr1630341edj.105.1610541141961; Wed, 13 Jan 2021 04:32:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610541141; cv=none; d=google.com; s=arc-20160816; b=ovtN2+RFC7hdVVLZxMn/9C4EXaueGJ7pkPNLNHJ8Y9XJG/GMAPiuyRRZX7aHeRGfe1 BYL2xC7WGIaW5s9FYpm0e02iwQgwjdvB24ZiwmAXrlBQ0HavZ1nQ6yFUffqxJzNol2OC vBqZDhjih+SiJ7/3VGN7ZQkfjJhc3C3/trMe6MRRQzQ//CgV1mSXDYtT9l8Nql33y9ei qK3zCkXDQ4xLcjJrchp+4ADrk8a45cW2ZkTRYDXbPGDX3F3gHS95KVMdKKsTk0rYjpKz EOF9wg0gygugyb0E7yYvKPlUaU1n8ruJRXM+NlIjVzY9ifZal54SK32LUB3ReGRbpu19 j+gA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=YHb853OW+nOYLu/IE6QCDFLb71LosLe9lCUBT46DGFo=; b=vvotVy4zm/E0mDDx2cNWs4jdmq2tnsBL+wOhFqyaV+A9TLs4YISmzdHAcIQdVGdi0n SBPxgxt3rKVrhHciuopqC/VTIC58+ELuvQDvcYyZRmz4nXzdcAcLGoQefSxZiUx31PpV oCN2bPNpeG+VUCUDrecGiRrwzJyWmYtVDpBZ00BYXmsZbpvRACJljQzSExzmVYAqrvEc 0/gtm5HLFJXNy0WAzc6y8qlPDVPtm2EVJv141jeOmGMKv18M+/Fr+0oYFPRtnrbc9BTp VYtu2LCoosyllZV1M48vSIchrRd7rHnyuO0JTce9kcl8JSiqG88tBmu/rslfwXGktS+d YdEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=A4DDeU2V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lz20si829043ejb.451.2021.01.13.04.31.57; Wed, 13 Jan 2021 04:32:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=A4DDeU2V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725801AbhAMMbP (ORCPT + 99 others); Wed, 13 Jan 2021 07:31:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725773AbhAMMbO (ORCPT ); Wed, 13 Jan 2021 07:31:14 -0500 Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D632C061575 for ; Wed, 13 Jan 2021 04:30:34 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id z20so952376qtq.3 for ; Wed, 13 Jan 2021 04:30:34 -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=YHb853OW+nOYLu/IE6QCDFLb71LosLe9lCUBT46DGFo=; b=A4DDeU2VTnUM/WugpeuuSLcq9DsDKZjW0otZi4DeSSn3tJzX8FHHFbhlUurXyQRR4p PiIgYMuNq97TrI5EQsmI1BzT66qkEfU5AuW1i02BlbKZ44VFVxHmLB9rjtDfH7/RK9OJ FS3SOC1fw1P/VWiCX6FK2U1QqrbCQVIGSgqu/KDe+h5MaJ7GTRNQZ+1+0I9k4t6+LOBl PNDRukfZWdk3Ue13Ow6DENqwIhn7TeIkUR0nTSBygPjK6T4TFDqPsVlTpMDWXvjkR9IM /Dsn21BJ3wSZnwOAW9hc1ZXARRdSKj9vniM1aNMeir7rOy4EIsqw3ss75pR+mlAQMC5p K6Sg== 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=YHb853OW+nOYLu/IE6QCDFLb71LosLe9lCUBT46DGFo=; b=TWm1DDAzi5vGtx23Uy82NuNNva1k5oGK6lxPc6aH2Xz65nWDBu1p6Le3rYrNvDnCEj uzy2NQXYZvr0Hn6ZtnjkoE+hIte+NChB0P3CpMMs1O2IPAwgVerdH/7RoM1oQMlzkbAB lOGAmOjkL5InEl5bsYvu/l1MOMTMTt3aylG1NC5qULKVaASUNycRX37F+h8X5WZho+yD 4VMVfgQSYxxIIFtFcDx2ch74yQdt4TPV/aj6kF6Cv4J97RUNpXii/jcMxTQITnqDsJX4 mx3gWGTE6bTOljVhJQab/L5JnyAS1d0NXYK0oTbUh9xVnvWehut3y/PtHwTXRsvnHXtD 1MUg== X-Gm-Message-State: AOAM532Z8kBibH3v1/jKuZpAefNQYRSUPP8NG0E54ox6YhfFYaI6Sh4L V+1huHl3okcWFf9UdwaM784IW5/qlfev3QZzT2EfPQ== X-Received: by 2002:ac8:6f32:: with SMTP id i18mr1908368qtv.175.1610541033304; Wed, 13 Jan 2021 04:30:33 -0800 (PST) MIME-Version: 1.0 References: <0c51a7266ea851797dc9816405fc40d860a48db1.1609871239.git.andreyknvl@google.com> In-Reply-To: From: Alexander Potapenko Date: Wed, 13 Jan 2021 13:30:22 +0100 Message-ID: Subject: Re: [PATCH 09/11] kasan: fix memory corruption in kasan_bitops_tags test To: Andrey Konovalov Cc: Catalin Marinas , Vincenzo Frascino , Dmitry Vyukov , Marco Elver , 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 9:07 PM 'Andrey Konovalov' via kasan-dev wrote: > > On Tue, Jan 12, 2021 at 9:30 AM Alexander Potapenko wrote: > > > > On Tue, Jan 5, 2021 at 7:28 PM Andrey Konovalov wrote: > > > > > > Since the hardware tag-based KASAN mode might not have a redzone that > > > comes after an allocated object (when kasan.mode=prod is enabled), the > > > kasan_bitops_tags() test ends up corrupting the next object in memory. > > > > > > Change the test so it always accesses the redzone that lies within the > > > allocated object's boundaries. > > > > > > Signed-off-by: Andrey Konovalov > > > Link: https://linux-review.googlesource.com/id/I67f51d1ee48f0a8d0fe2658c2a39e4879fe0832a Reviewed-by: Alexander Potapenko > > > --- > > > lib/test_kasan.c | 12 ++++++------ > > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > > > diff --git a/lib/test_kasan.c b/lib/test_kasan.c > > > index b67da7f6e17f..3ea52da52714 100644 > > > --- a/lib/test_kasan.c > > > +++ b/lib/test_kasan.c > > > @@ -771,17 +771,17 @@ static void kasan_bitops_tags(struct kunit *test) > > > > > > /* This test is specifically crafted for the tag-based mode. */ > > > if (IS_ENABLED(CONFIG_KASAN_GENERIC)) { > > > - kunit_info(test, "skipping, CONFIG_KASAN_SW_TAGS required"); > > > + kunit_info(test, "skipping, CONFIG_KASAN_SW/HW_TAGS required"); > > > return; > > > } > > > > > > - /* Allocation size will be rounded to up granule size, which is 16. */ > > > - bits = kzalloc(sizeof(*bits), GFP_KERNEL); > > > + /* kmalloc-64 cache will be used and the last 16 bytes will be the redzone. */ > > > + bits = kzalloc(48, GFP_KERNEL); > > > > I think it might make sense to call ksize() here to ensure we have > > these spare bytes. > > Calling ksize() will unpoison the whole object. Ah, that's right. > I think it's OK to make assumptions about KASAN internals in tests. I > would actually say that we need more tests that check such internal > properties. Agreed.