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=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,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 6956BC2D0DB for ; Mon, 20 Jan 2020 15:40:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2D5A8217F4 for ; Mon, 20 Jan 2020 15:40:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="VbUJNHV1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729121AbgATPkz (ORCPT ); Mon, 20 Jan 2020 10:40:55 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:36450 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726819AbgATPkz (ORCPT ); Mon, 20 Jan 2020 10:40:55 -0500 Received: by mail-ot1-f66.google.com with SMTP id m2so129744otq.3 for ; Mon, 20 Jan 2020 07:40:54 -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=bW+iYMzyJar5RkTMPGCcQG+bJOCaKWAlm479KJ6EAJc=; b=VbUJNHV1v/I38PKXDVIMoFye1oZVkkX7SJwJbvOOD7n4G2y8o79w3tA+/PDj1eFIAr hBmicIIU24JnBiwvffKhfRYNCEfdtJNfQDpOzvQIxdCjivxW5TSMA7Wa3nZ38oePzy2+ qMKkH9Hhv9vX7wSW3HPT+pv1+ZtAMMwRYppY6oMhDuRDLM3NRGDeaAU2AHd9NulTvFuI 4tbxl+rERpJJWSzspLh7RFLS9kNcBnhKkThxr+4aETQngE/KIIi4gJt+HmIyELS1PBJq ROXOe+lauiiaT/nNfUG6bmuTrlVOETx5UwWtgS6yFYd3FPJsqD7HNq1LEOU6AJXJQblM QIIg== 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=bW+iYMzyJar5RkTMPGCcQG+bJOCaKWAlm479KJ6EAJc=; b=NmHA9SWzXGndSve1JdJUJHpWvXl+81kmcdaYljnbZXKFb2fz43XUff2Tse2LqpHx4m 6ae3sjRvQtzntGtwrnZ6121K7qQJVc4Uh4puljAiSannX43RFs0jduApc0/1mHf6yRKP 908CXcOeLsZVZFIcGjTe5FQpQ+Wixi5eKnP/r9wczwEwvJb0n42ZRUPjfNNjLocPja4F /k7AqKxS7jl/5F0H4sXcuQ3puZWQOZ3lL1G+bF3TMBSDYvigYd5gzz9HFZi9cEBuaFbl PGmS7MeSGvrthJ6ZNOUUNfQa5g4ZjszevpI6gnvGXD9AqCFw75zdASbalMkLg27Qb1vH Amzg== X-Gm-Message-State: APjAAAWr/ktNXNRTBFP4l2WsNL+APIW8n+JyuJvfz8Q8agKZbM3Nclgq komm16Fslu1ksp4IY5+1VPCrp31EJ9JoJTo+ltvcLQ== X-Google-Smtp-Source: APXvYqzYSYuKezAl7YpUgPSRKQPA6H2KEbg8/UlKlfYHOFR01Pivkt2lcBRDlUu5Mxcw6HJtVeDKxsfdhfFE+UFLaRQ= X-Received: by 2002:a05:6830:1d7b:: with SMTP id l27mr15490059oti.251.1579534853838; Mon, 20 Jan 2020 07:40:53 -0800 (PST) MIME-Version: 1.0 References: <20200120141927.114373-1-elver@google.com> In-Reply-To: From: Marco Elver Date: Mon, 20 Jan 2020 16:40:42 +0100 Message-ID: Subject: Re: [PATCH 1/5] include/linux: Add instrumented.h infrastructure To: Dmitry Vyukov Cc: "Paul E. McKenney" , Andrey Konovalov , Alexander Potapenko , kasan-dev , LKML , Mark Rutland , Will Deacon , Peter Zijlstra , Boqun Feng , Arnd Bergmann , Al Viro , Christophe Leroy , Daniel Axtens , Michael Ellerman , Steven Rostedt , Masami Hiramatsu , Ingo Molnar , Christian Brauner , Daniel Borkmann , cyphar@cyphar.com, Kees Cook , linux-arch 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 Mon, 20 Jan 2020 at 16:09, Dmitry Vyukov wrote: > > On Mon, Jan 20, 2020 at 3:58 PM Dmitry Vyukov wrote: > > > > On Mon, Jan 20, 2020 at 3:45 PM Dmitry Vyukov wrote: > > > > > > On Mon, Jan 20, 2020 at 3:19 PM Marco Elver wrote: > > > > > > > > This adds instrumented.h, which provides generic wrappers for memory > > > > access instrumentation that the compiler cannot emit for various > > > > sanitizers. Currently this unifies KASAN and KCSAN instrumentation. In > > > > future this will also include KMSAN instrumentation. > > > > > > > > Note that, copy_{to,from}_user require special instrumentation, > > > > providing hooks before and after the access, since we may need to know > > > > the actual bytes accessed (currently this is relevant for KCSAN, and is > > > > also relevant in future for KMSAN). > > > > > > > > Suggested-by: Arnd Bergmann > > > > Signed-off-by: Marco Elver > > > > --- > > > > include/linux/instrumented.h | 153 +++++++++++++++++++++++++++++++++++ > > > > 1 file changed, 153 insertions(+) > > > > create mode 100644 include/linux/instrumented.h > > > > > > > > diff --git a/include/linux/instrumented.h b/include/linux/instrumented.h > > > > new file mode 100644 > > > > index 000000000000..9f83c8520223 > > > > --- /dev/null > > > > +++ b/include/linux/instrumented.h > > > > @@ -0,0 +1,153 @@ > > > > +/* SPDX-License-Identifier: GPL-2.0 */ > > > > + > > > > +/* > > > > + * This header provides generic wrappers for memory access instrumentation that > > > > + * the compiler cannot emit for: KASAN, KCSAN. > > > > + */ > > > > +#ifndef _LINUX_INSTRUMENTED_H > > > > +#define _LINUX_INSTRUMENTED_H > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > + > > > > +/** > > > > + * instrument_read - instrument regular read access > > > > + * > > > > + * Instrument a regular read access. The instrumentation should be inserted > > > > + * before the actual read happens. > > > > + * > > > > + * @ptr address of access > > > > + * @size size of access > > > > + */ > > > > > > Based on offline discussion, that's what we add for KMSAN: > > > > > > > +static __always_inline void instrument_read(const volatile void *v, size_t size) > > > > +{ > > > > + kasan_check_read(v, size); > > > > + kcsan_check_read(v, size); > > > > > > KMSAN: nothing > > > > KMSAN also has instrumentation in > > copy_to_user_page/copy_from_user_page. Do we need to do anything for > > KASAN/KCSAN for these functions? copy_to_user_page/copy_from_user_page can be instrumented with instrument_copy_{to,from}_user_. I prefer keeping this series with no functional change intended for KASAN at least. > There is also copy_user_highpage. > > And ioread/write8/16/32_rep: do we need any instrumentation there. It > seems we want both KSAN and KCSAN too. One may argue that KCSAN > instrumentation there is to super critical at this point, but KASAN > instrumentation is important, if anything to prevent silent memory > corruptions. How do we instrument there? I don't see how it maps to > any of the existing instrumentation functions. These should be able to use the regular instrument_{read,write}. I prefer keeping this series with no functional change intended for KASAN at least. > There is also kmsan_check_skb/kmsan_handle_dma/kmsan_handle_urb that > does not seem to map to any of the instrumentation functions. For now, I would rather that there are some one-off special instrumentation, like for KMSAN. Coming up with a unified interface here that, without the use-cases even settled, seems hard to justify. Once instrumentation for these have settled, unifying the interface would have better justification. This patch series is merely supposed to introduce instrumented.h and replace the kasan_checks (also implicitly introducing kcsan_checks there), however, with no further functional change intended. I propose that adding entirely new instrumentation for both KASAN and KCSAN, we should send a separate patch-series. Thanks, -- Marco