From patchwork Tue Dec 13 08:58:42 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Vyukov X-Patchwork-Id: 9471931 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 28E50607EE for ; Tue, 13 Dec 2016 08:59:08 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1CE6B284FF for ; Tue, 13 Dec 2016 08:59:08 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 10C9B28506; Tue, 13 Dec 2016 08:59:08 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 047B6284FF for ; Tue, 13 Dec 2016 08:59:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752711AbcLMI7G (ORCPT ); Tue, 13 Dec 2016 03:59:06 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:35212 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752892AbcLMI7F (ORCPT ); Tue, 13 Dec 2016 03:59:05 -0500 Received: by mail-wm0-f47.google.com with SMTP id a197so98993668wmd.0 for ; Tue, 13 Dec 2016 00:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bdRtYRcB+F1jQBhSNyszDsdAZHI4U+dOPWKNIB9qJDI=; b=P5xDL6ibiLeztNbvRbVD1ZTAHC2CtrRN+XbdPEAzToWguQ6sc022WmW/r+MdGQJy5q +2KtLWzl8dlnKazjl8uj09fUqWzcRVOMF3zGKEWh8QgfTquByNDq7h0FZ2vsfiYUPihf IYI/sXxDUvF8ocnINtO47yJwUo8wUmMNlPLKDd+M+murUlzdjwOIpDJ/yxAJtyjWwnxd 7nDs0c+3IxVoE/tLheqEuewxfXTemKJsqI0QIxi67q9CAMcZKkw51XOp6C4dHJywEwkN z5ThxeLn8YL176e8zXsDtbHzlnxnId50hlkNYM56K0GRcnyTiHb0peu7S1Mduq6PRjlf bmLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bdRtYRcB+F1jQBhSNyszDsdAZHI4U+dOPWKNIB9qJDI=; b=DjyK6dyJKFVtDRvxN4HNPMS4W8F6lezXIjXH1Pd9ibzoyQrLfFdYwZTR9hvrGTJPO8 mB7w8wjNG3tDCJ/oy5CX5+CVMdBCeP7swS3kgpTD3/yRvI3neX5IaDxP6Lz1hqAejWNA Y1dsGUE8ZhMprI3y1Ag3/5bZ0m0zxHo5Z5pSn8q0QfyKCK6GCh4IaBr1obaGg0ffFjoJ J2bCoa+AWOcAHIUFoewH3Q446p/EBjjkrfMtzomzYzhQCFvp/NNJHgdDjtpOw4wKbPOC 0xZLqzLTyWdKDKJhb78cuXImOvO84KOClgMX3X21WN/4RGv4bYSjghuGZrRrYBQMU9md VqWg== X-Gm-Message-State: AKaTC02S7RMoJqgydJh+GvMWmK0trNZsVcnggP9x8W7gC4qHHaPoxYD4YGiuKPbmB5MPolrYxm6qTLyhU8WU8OVb X-Received: by 10.46.7.9 with SMTP id 9mr34402548ljh.75.1481619543156; Tue, 13 Dec 2016 00:59:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.183.238 with HTTP; Tue, 13 Dec 2016 00:58:42 -0800 (PST) In-Reply-To: <1481608665-26941-1-git-send-email-maninder1.s@samsung.com> References: <1481608665-26941-1-git-send-email-maninder1.s@samsung.com> From: Dmitry Vyukov Date: Tue, 13 Dec 2016 09:58:42 +0100 Message-ID: Subject: Re: [PATCH v2] kasan: Support for r/w instrumentation control To: Maninder Singh Cc: Andrey Ryabinin , Alexander Potapenko , Jonathan Corbet , Michal Marek , Andrew Morton , kasan-dev , linux-doc@vger.kernel.org, LKML , "open list:KERNEL BUILD + fi..." , PANKAJ MISHRA , Ajeet Kumar Yadav , Vaneet narang Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Dec 13, 2016 at 6:57 AM, Maninder Singh wrote: > This provide option to control sanity of read and write operations > Both read and write instrumentation increase size of uImage, So using > this option read or write instrumentation can be avoided if not required. > Useful in case of module sanity, using this uImage sanity can be avoided. > > Also user space ASAN provides this support for read/write instrumentation > control. > > Signed-off-by: Vaneet narang > Signed-off-by: Maninder Singh > Reviewed-by: Ajeet Yadav > --- > v1 -> v2: Added Documentation for the same. > > Documentation/dev-tools/kasan.rst | 16 ++++++++++++++++ > lib/Kconfig.kasan | 16 ++++++++++++++++ > scripts/Makefile.kasan | 4 ++++ > 3 files changed, 36 insertions(+) > > diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst > index f7a18f2..b8147df 100644 > --- a/Documentation/dev-tools/kasan.rst > +++ b/Documentation/dev-tools/kasan.rst > @@ -40,6 +40,22 @@ similar to the following to the respective kernel Makefile: > > KASAN_SANITIZE := n > > +Control Over Read/Write Instrumentation of kernel:: double colon at the end of line > + > +- To Disable Read Instrumentation of kernel with: Strange choice of capital letters. > + > + CONFIG_KASAN_READS = n Are configs ever set to = n? I can't find any cases in my .config file. I thought configs are disabled with: # CONFIG_KASAN_READS is not set > + > +Because in some cases we need to check only memory write sanitization > +for better performance, read instrumentation can be disabled. > + > +- To Disable Write Instrumentation of kernel with: I am not a native speaker but this looks malformed. I would say either "Disable write instrumentation of kernel with" or "To disable write instrumentation of kernel set" > + CONFIG_KASAN_WRITES = n > + > +In case when to instrument only external modules, not the entire kernel > +for read or write intrumentation or both. > + I propose something along these lines: the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -40,6 +40,14 @@ similar to the following to the respective kernel Makefile: KASAN_SANITIZE := n +Sometimes it may be useful to disable instrumentation of reads, or writes +or both for the entire kernel. For example, if binary size is a concern, +it may be useful to disable instrumentation of reads to reduce binary size but +still catch more harmful bugs on writes. Or, if one is interested only in +sanitization of a particular module and performance is a concern, she can +disable instrumentation of both reads and writes for kernel code. +Instrumentation can be disabled with CONFIG_KASAN_READS and CONFIG_KASAN_WRITES. + Error reports -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in