Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp69983ybz; Tue, 21 Apr 2020 04:58:09 -0700 (PDT) X-Google-Smtp-Source: APiQypJqNb5aGPxB/htCMRIza8+Onf3ElbSKECgVT7155hVI1QWx7RwHfxA2w1CFxj37THp69Cqu X-Received: by 2002:a17:906:31d7:: with SMTP id f23mr20555541ejf.118.1587470289450; Tue, 21 Apr 2020 04:58:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587470289; cv=none; d=google.com; s=arc-20160816; b=hflPN/Bg17S5y9xf7CLJ7dQK4f90uBE8fj/qYZaYwSuGbyzgC0ldmi7p1LZuudvOHz OMRjoiHSvmNocLjh/xSdFwbAlv2E0lna2NPcgaRHCZ0kqNiVeEMlyzciM+l0igYd8cB8 Elj1JUEUIoZFbR2ydUL/5pukw9QXFAJo2+g8LRSiORSj2RzjWoR4aFRstYRDGm9bX6f8 ju2iSIPgxkHGeA8m+WvAGee6Qx39ZABuQaMfAWGZYaCYx0dJUuoriDWSJNM/d9ObMKVF ePeLD05rl+GaBWEUzExh1C6X+cbvcRfIGJAfv4q0R2W9oRFZ0pEMKdptqG07erf8NYAp 4sjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Gy/qiieN90UJKr/c+cYCi+ub2I5kQwPARkN3XL1JRak=; b=XUc5JhQO/KIqOHOrQlcM22MfWrCoNIZjRKTntZe9ZRoh92ujkBMA8ThsAykkNRUkhy Q4eHNazOIYJWpLn1PPID1nX1RznMUcdZ427wDqDhdCqjS9wWwMGPmwnn0GtC0Fd0SNPn TY7cyaiFgd9pOZNRhl1GVr1qkD+ELa6U+PFqX1jUzRAqppYnfAlUt49gG2rPx6zkLPpv HLgZNZKrEJtherJyjUL6JJK00w4u7to8P1lOFeu0xdzbpTF7WtXU/K5zHgSr6CZt1OM1 IEQobkFZAb6Qm86XtKf6+uTbydCJ8/jZs+wZCmk0DPBrSx/CQpD/pSbheTu+ExP8V3rY gc2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=aCc5+8+A; 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 t5si1423746ejb.231.2020.04.21.04.57.45; Tue, 21 Apr 2020 04:58:09 -0700 (PDT) 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=aCc5+8+A; 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 S1728645AbgDUL41 (ORCPT + 99 others); Tue, 21 Apr 2020 07:56:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726018AbgDUL40 (ORCPT ); Tue, 21 Apr 2020 07:56:26 -0400 Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7622FC061A0F for ; Tue, 21 Apr 2020 04:56:26 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id l25so14161416qkk.3 for ; Tue, 21 Apr 2020 04:56: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=Gy/qiieN90UJKr/c+cYCi+ub2I5kQwPARkN3XL1JRak=; b=aCc5+8+A8yLcK/QqnugFhTCfuQH8ZptGrOL5KoB4qPjfHfg455c5bxR2ErMEoPapf5 uswTC5LyF+tq3Acydm/mOkThdTzi4W6FFRu209tSF2BEofynt+8R7+A4/fZHeT6zhJzm ckM5RBxLwpV7Q3sk4bicpgtLknywP1ick8tWtuQkvzjoON229ZmaaSlmzEBc6wXUJvCo 5SROV55sCPT1NhDKKKVvb9+y64jLWx4R8VRDsSi0+KWkDukc9Z8u3dZhUm6Xmob2XhaT eYr5kOqL+dl22xCD4d68H+iRq1GB4bxtUOqvdo63JvGbIc52n7b78xxmC7J3+1INySvY h7Aw== 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=Gy/qiieN90UJKr/c+cYCi+ub2I5kQwPARkN3XL1JRak=; b=WuKm7SMjQcRzWN0uwedNu1b3v2e4EZ1XO/4FWp2dVPBzOaBHEoVoQB7Ul/z3a/XZVd w42r5GbBAYBpi4dogwOlZvHxTl6LYrgApoiFddlcd0zugJKrGmeUDBQrXO/dRiYIArnX 7CRVSMfzzHYKTKxkDltVpLKayLmDDaMLCjWT9LrBySkuVhR3WsgKUtmOQdWnnAwbgBbw S2i2RWKXIOTFXwKRQkMilZXjWlqa7X7D+AlNDD9ypz4IXwz6nSPKnKoVxJef6jKWSHB7 pTyHHWWY7fMxy0tX+/sQW4d3yWOiYr8XT+ynt7EHSygMgjNjbrsxgRrHGPdB8XSp+SoS 0ATw== X-Gm-Message-State: AGi0PuZo0lUl1ZQEp6S/jmpvWvZ0CGp2onggWO9ILjrTr1xjVuyW7EU9 wXeGX1H4YiWoqvuIU3tA6oh6lRHztZgcK0l9nbvF0A== X-Received: by 2002:a37:bc47:: with SMTP id m68mr21780368qkf.8.1587470184030; Tue, 21 Apr 2020 04:56:24 -0700 (PDT) MIME-Version: 1.0 References: <20200421014007.6012-1-walter-zh.wu@mediatek.com> In-Reply-To: <20200421014007.6012-1-walter-zh.wu@mediatek.com> From: Dmitry Vyukov Date: Tue, 21 Apr 2020 13:56:12 +0200 Message-ID: Subject: Re: [PATCH] kasan: fix KASAN unit tests for tag-based KASAN To: Walter Wu , David Gow , Brendan Higgins , Patricia Alfonso Cc: Andrey Ryabinin , Alexander Potapenko , Matthias Brugger , Andrey Konovalov , Andrew Morton , kasan-dev , Linux-MM , LKML , Linux ARM , wsd_upstream , linux-mediatek@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 21, 2020 at 3:40 AM Walter Wu wrote: > > When we use tag-based KASAN, then KASAN unit tests don't detect > out-of-bounds memory access. Because with tag-based KASAN the state > of each 16 aligned bytes of memory is encoded in one shadow byte > and the shadow value is tag of pointer, so we need to read next > shadow byte, the shadow value is not equal to tag of pointer, > then tag-based KASAN will detect out-of-bounds memory access. > > Signed-off-by: Walter Wu > Cc: Andrey Ryabinin > Cc: Dmitry Vyukov > Cc: Alexander Potapenko > Cc: Matthias Brugger > Cc: Andrey Konovalov > Cc: Andrew Morton > --- > lib/test_kasan.c | 62 ++++++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 55 insertions(+), 7 deletions(-) > > diff --git a/lib/test_kasan.c b/lib/test_kasan.c > index e3087d90e00d..a164f6b47fe5 100644 > --- a/lib/test_kasan.c > +++ b/lib/test_kasan.c > @@ -40,7 +40,12 @@ static noinline void __init kmalloc_oob_right(void) > return; > } Hi Walter, This would be great to have! But I am concerned about these series that port KASAN tests to KUNIT: https://lkml.org/lkml/2020/4/17/1144 I suspect it will be one large merge conflict. Not sure what is the proper way to resovle this. I've added authors to CC. > +#ifdef CONFIG_KASAN_GENERIC > ptr[size] = 'x'; > +#else > + ptr[size + 5] = 'x'; > +#endif > + For this particular snippet I think we can reduce amount of idef'ery and amount of non-compiled code in each configuration with something like: ptr[size + 5] = 'x'; if (ENABLED(CONFIG_KASAN_GENERIC)) ptr[size] = 'x'; One check runs always (it should pass in both configs, right?). The only only in GENERIC, but it's C-level if rather than preprocessor. KUNIT should make 2 bugs per test easily expressable (and testable). > kfree(ptr); > } > > @@ -92,7 +97,12 @@ static noinline void __init kmalloc_pagealloc_oob_right(void) > return; > } > > +#ifdef CONFIG_KASAN_GENERIC > ptr[size] = 0; > +#else > + ptr[size + 6] = 0; > +#endif > + > kfree(ptr); > } > > @@ -162,7 +172,11 @@ static noinline void __init kmalloc_oob_krealloc_more(void) > return; > } > > +#ifdef CONFIG_KASAN_GENERIC > ptr2[size2] = 'x'; > +#else > + ptr2[size2 + 13] = 'x'; > +#endif > kfree(ptr2); > } > > @@ -180,7 +194,12 @@ static noinline void __init kmalloc_oob_krealloc_less(void) > kfree(ptr1); > return; > } > + > +#ifdef CONFIG_KASAN_GENERIC > ptr2[size2] = 'x'; > +#else > + ptr2[size2 + 2] = 'x'; > +#endif > kfree(ptr2); > } > > @@ -216,7 +235,11 @@ static noinline void __init kmalloc_oob_memset_2(void) > return; > } > > +#ifdef CONFIG_KASAN_GENERIC > memset(ptr+7, 0, 2); > +#else > + memset(ptr+15, 0, 2); > +#endif > kfree(ptr); > } > > @@ -232,7 +255,11 @@ static noinline void __init kmalloc_oob_memset_4(void) > return; > } > > +#ifdef CONFIG_KASAN_GENERIC > memset(ptr+5, 0, 4); > +#else > + memset(ptr+15, 0, 4); > +#endif > kfree(ptr); > } > > @@ -249,7 +276,11 @@ static noinline void __init kmalloc_oob_memset_8(void) > return; > } > > +#ifdef CONFIG_KASAN_GENERIC > memset(ptr+1, 0, 8); > +#else > + memset(ptr+15, 0, 8); > +#endif > kfree(ptr); > } > > @@ -265,7 +296,11 @@ static noinline void __init kmalloc_oob_memset_16(void) > return; > } > > +#ifdef CONFIG_KASAN_GENERIC > memset(ptr+1, 0, 16); > +#else > + memset(ptr+15, 0, 16); > +#endif > kfree(ptr); > } > > @@ -281,7 +316,11 @@ static noinline void __init kmalloc_oob_in_memset(void) > return; > } > > +#ifdef CONFIG_KASAN_GENERIC > memset(ptr, 0, size+5); > +#else > + memset(ptr, 0, size+7); > +#endif > kfree(ptr); > } > > @@ -415,7 +454,11 @@ static noinline void __init kmem_cache_oob(void) > return; > } > > +#ifdef CONFIG_KASAN_GENERIC > *p = p[size]; > +#else > + *p = p[size + 8]; > +#endif > kmem_cache_free(cache, p); > kmem_cache_destroy(cache); > } > @@ -497,6 +540,11 @@ static noinline void __init copy_user_test(void) > char __user *usermem; > size_t size = 10; > int unused; > +#ifdef CONFIG_KASAN_GENERIC > + size_t oob_size = 1; > +#else > + size_t oob_size = 7; > +#endif > > kmem = kmalloc(size, GFP_KERNEL); > if (!kmem) > @@ -512,25 +560,25 @@ static noinline void __init copy_user_test(void) > } > > pr_info("out-of-bounds in copy_from_user()\n"); > - unused = copy_from_user(kmem, usermem, size + 1); > + unused = copy_from_user(kmem, usermem, size + oob_size); > > pr_info("out-of-bounds in copy_to_user()\n"); > - unused = copy_to_user(usermem, kmem, size + 1); > + unused = copy_to_user(usermem, kmem, size + oob_size); > > pr_info("out-of-bounds in __copy_from_user()\n"); > - unused = __copy_from_user(kmem, usermem, size + 1); > + unused = __copy_from_user(kmem, usermem, size + oob_size); > > pr_info("out-of-bounds in __copy_to_user()\n"); > - unused = __copy_to_user(usermem, kmem, size + 1); > + unused = __copy_to_user(usermem, kmem, size + oob_size); > > pr_info("out-of-bounds in __copy_from_user_inatomic()\n"); > - unused = __copy_from_user_inatomic(kmem, usermem, size + 1); > + unused = __copy_from_user_inatomic(kmem, usermem, size + oob_size); > > pr_info("out-of-bounds in __copy_to_user_inatomic()\n"); > - unused = __copy_to_user_inatomic(usermem, kmem, size + 1); > + unused = __copy_to_user_inatomic(usermem, kmem, size + oob_size); > > pr_info("out-of-bounds in strncpy_from_user()\n"); > - unused = strncpy_from_user(kmem, usermem, size + 1); > + unused = strncpy_from_user(kmem, usermem, size + oob_size); > > vm_munmap((unsigned long)usermem, PAGE_SIZE); > kfree(kmem); > -- > 2.18.0 > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200421014007.6012-1-walter-zh.wu%40mediatek.com.