Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1006418pxb; Tue, 9 Feb 2021 19:46:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJwDwC6C+UveY3eUbfrHnLmoJ+toSZLehlVrfvjTG044M9e/xbFWgeoEVTiZE//YEDKgYcsO X-Received: by 2002:a17:907:3f13:: with SMTP id hq19mr963547ejc.142.1612928816598; Tue, 09 Feb 2021 19:46:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612928816; cv=none; d=google.com; s=arc-20160816; b=VCZAD3ezPeaBcXaPM/iezOeBJ468wqCWoiH1UNGUuCobAf0enmfKd0xtxO7I+VF3o+ Q6Dsm517B/FcUnZhkNZ5yH6SiuIdtsuxaLliqqbfAMdn7y1pXoyqxMa+w9xH72AoCmcB EN9Op/d7rgpbkBK+lcjyzL4E0XnoMrFn/iLE/zVnvy5ZWQ3khvIIaJ85fcPDG5PPOZI0 77fYsK+dujVCDWay12/XYoH+nc+PUg8x8XRKXaubSLQquSgHrt7MXMAXj5XK8ksO9Cyx 1b9mrOn5pU+F0FwesC3K4bJkQsjB6C9Tss93z58cVeZbmRaPNlttGwzyQKXM+RsDZoQZ mg5w== 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=dLaBmb+gbvYqE7SFoBORWrnKQFbpMrwQooOmjDgpSmc=; b=TZb8BdNcH4siJ+GHhBamHeZ4dBVs2x98aitPjMNCV8PLutfH5VBB14yAYf36mojJTj Mu5TmfyINVTARHm2DrjEozR4xhC0vJfwTme8U9HBbaslRhZoGoBl1TsvLWcIpqDtnztX T4pDEMMIGxbTaHEXg4X6rvaAM+k67KgIH6qFsvCWYEd/8ycg27cKFIjW9i4U2ECCgtD9 t1KFgJgngJIlsK/fd6usAYsixJnnloL5KuwJPZb2P6Gac2Vql+64KrwWJQWHhQqh8Myp G71xph6a2IvYxfZfFgT/GUblrJsYCGZcoeJRCko66Hw+gl1RqyPVo+gRYd/FjrrG9x3j jqdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Aaono0oI; 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 v6si544955edq.183.2021.02.09.19.46.33; Tue, 09 Feb 2021 19:46:56 -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=Aaono0oI; 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 S231343AbhBINZc (ORCPT + 99 others); Tue, 9 Feb 2021 08:25:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230414AbhBINZa (ORCPT ); Tue, 9 Feb 2021 08:25:30 -0500 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16FE0C061786 for ; Tue, 9 Feb 2021 05:24:50 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id x9so9749693plb.5 for ; Tue, 09 Feb 2021 05:24:50 -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=dLaBmb+gbvYqE7SFoBORWrnKQFbpMrwQooOmjDgpSmc=; b=Aaono0oIpDgkEDIXP5mkUIMiyx2/b7W24BRlceYxZTzAfaUlNp8B9UX+B89nU2x2vD w5AQhJHbkQc7SrodWfdoHGKpNfANjseR7lXUrWtEQg6Fd+jAVsVwYK+3NWnVhHO31MOU wtopGP8DbAjxdsMzmLsx/8jzjnDTWiK3BjuRyfmNGyZyvB96ze6+B+TdJtg9JoM8hREG OGBYv+x1b0yJHlr97loq8Ve7tPr+tlHA8VBXsb5pNd4tyMBw78Wme+2LgI2ajXCCoZRQ nS88kYG0AC2v1gXJrKuVg3dUo8zsrHZvn6t2tY/yYTTbq1Ll3SdlGQ1P0gI8dp0x2Bch OIaA== 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=dLaBmb+gbvYqE7SFoBORWrnKQFbpMrwQooOmjDgpSmc=; b=DIc9Vme++jcqE0CsbA0EU/JSUJ+Aj5Cd3lSfzBA7k3559Kz7udjEDX7q8GUrXIOk/y E58sK1JunjnYfrnTdRy8dRmNGuBAA1G6ooU6+Y4eNW25no/IyYM8/cNsBjv3ei9iAB7z dyhi+x6ydPhAZ6wHbTKRUJvPAb4b3JBXvRcErIzBgTIpnIr6igPo1bvzNRPeBwlCHZR6 Y8TM3JSe+68djhgWghscx/iwDOKHONlayeZKOB1Yc7WShbqcJlynY2i27dGCk47r8E1K Nne/l4TUOOFaow0/PZd0lbM+QrLzsAxkBpRoIQYOi2jE6ExgURRhkG+PC7K3mNhGVtyJ R4uQ== X-Gm-Message-State: AOAM532u699I8oPb9FXyE1SCLQ3Ll8PYZqfkTzQ/OwnPuYF6oZTfYxkc jkutn8gP+VD+3SIH+IuLdPcwCgGi/OID4lwx/0Os0g== X-Received: by 2002:a17:903:31d1:b029:de:8361:739b with SMTP id v17-20020a17090331d1b02900de8361739bmr21064623ple.85.1612877089414; Tue, 09 Feb 2021 05:24:49 -0800 (PST) MIME-Version: 1.0 References: <9bef90327c9cb109d736c40115684fd32f49e6b0.1612546384.git.andreyknvl@google.com> In-Reply-To: From: Andrey Konovalov Date: Tue, 9 Feb 2021 14:24:38 +0100 Message-ID: Subject: Re: [PATCH v3 mm 08/13] kasan, mm: optimize krealloc poisoning To: Marco Elver Cc: Andrew Morton , Catalin Marinas , Vincenzo Frascino , Dmitry Vyukov , Alexander Potapenko , Will Deacon , Andrey Ryabinin , Peter Collingbourne , 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 Mon, Feb 8, 2021 at 11:48 AM Marco Elver wrote: > > On Fri, Feb 05, 2021 at 06:34PM +0100, Andrey Konovalov wrote: > > Currently, krealloc() always calls ksize(), which unpoisons the whole > > object including the redzone. This is inefficient, as kasan_krealloc() > > repoisons the redzone for objects that fit into the same buffer. > > > > This patch changes krealloc() instrumentation to use uninstrumented > > __ksize() that doesn't unpoison the memory. Instead, kasan_kreallos() > > is changed to unpoison the memory excluding the redzone. > > > > For objects that don't fit into the old allocation, this patch disables > > KASAN accessibility checks when copying memory into a new object instead > > of unpoisoning it. > > > > Signed-off-by: Andrey Konovalov > > Reviewed-by: Marco Elver > > Clarification below. > > > --- > > mm/kasan/common.c | 12 ++++++++++-- > > mm/slab_common.c | 20 ++++++++++++++------ > > 2 files changed, 24 insertions(+), 8 deletions(-) > > > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c > > index 7ea643f7e69c..a8a67dca5e55 100644 > > --- a/mm/kasan/common.c > > +++ b/mm/kasan/common.c > > @@ -476,7 +476,7 @@ static void *____kasan_kmalloc(struct kmem_cache *cache, const void *object, > > > > /* > > * The object has already been unpoisoned by kasan_slab_alloc() for > > - * kmalloc() or by ksize() for krealloc(). > > + * kmalloc() or by kasan_krealloc() for krealloc(). > > */ > > > > /* > > @@ -526,7 +526,7 @@ void * __must_check __kasan_kmalloc_large(const void *ptr, size_t size, > > > > /* > > * The object has already been unpoisoned by kasan_alloc_pages() for > > - * alloc_pages() or by ksize() for krealloc(). > > + * alloc_pages() or by kasan_krealloc() for krealloc(). > > */ > > > > /* > > @@ -554,8 +554,16 @@ void * __must_check __kasan_krealloc(const void *object, size_t size, gfp_t flag > > if (unlikely(object == ZERO_SIZE_PTR)) > > return (void *)object; > > > > + /* > > + * Unpoison the object's data. > > + * Part of it might already have been unpoisoned, but it's unknown > > + * how big that part is. > > + */ > > + kasan_unpoison(object, size); > > + > > page = virt_to_head_page(object); > > > > + /* Piggy-back on kmalloc() instrumentation to poison the redzone. */ > > if (unlikely(!PageSlab(page))) > > return __kasan_kmalloc_large(object, size, flags); > > else > > diff --git a/mm/slab_common.c b/mm/slab_common.c > > index dad70239b54c..60a2f49df6ce 100644 > > --- a/mm/slab_common.c > > +++ b/mm/slab_common.c > > @@ -1140,19 +1140,27 @@ static __always_inline void *__do_krealloc(const void *p, size_t new_size, > > void *ret; > > size_t ks; > > > > - if (likely(!ZERO_OR_NULL_PTR(p)) && !kasan_check_byte(p)) > > - return NULL; > > - > > - ks = ksize(p); > > + /* Don't use instrumented ksize to allow precise KASAN poisoning. */ > > + if (likely(!ZERO_OR_NULL_PTR(p))) { > > + if (!kasan_check_byte(p)) > > + return NULL; > > Just checking: Check byte returns true if the object is not tracked by KASAN, right? I.e. if it's a KFENCE object, kasan_check_byte() always returns true. kasan_check_byte() still performs the check, but since KFENCE objects are never poisoned, the check always passes. Thanks!