Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932519AbcLLKtk (ORCPT ); Mon, 12 Dec 2016 05:49:40 -0500 Received: from mail-wm0-f43.google.com ([74.125.82.43]:35106 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754190AbcLLKti (ORCPT ); Mon, 12 Dec 2016 05:49:38 -0500 MIME-Version: 1.0 In-Reply-To: <20161212102905epcms5p4ae1ddc2405b942e2d65e5cda4bc4abd4@epcms5p4> References: <1481535157-24628-1-git-send-email-maninder1.s@samsung.com> <20161212102905epcms5p4ae1ddc2405b942e2d65e5cda4bc4abd4@epcms5p4> From: Dmitry Vyukov Date: Mon, 12 Dec 2016 11:49:16 +0100 Message-ID: Subject: Re: Re: [PATCH 1/1] kasan: Support for r/w instrumentation control To: Vaneet narang Cc: Maninder Singh , Michal Marek , Andrey Ryabinin , Alexander Potapenko , Andrew Morton , LKML , "open list:KERNEL BUILD + fi..." , kasan-dev , PANKAJ MISHRA , Ajeet Kumar Yadav Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1038 Lines: 27 On Mon, Dec 12, 2016 at 11:29 AM, Vaneet Narang wrote: > Hi, > >> Do you actually hit an issue with image size? In what context? >> Do you use inline/outline instrumentation? Does switching to the other >> option help? > > Memory access with KASAN enabled Image has overhead in terms of cpu execution. > Sometimes we are not able to reproduce race condition issues with these overhead in > place. So user should have control atleast over read instrumentation. Don't you want to disable KASAN entirely in such case? >> Does it make sense to ever disable writes? I assume that you are > > Write instrumentation control is majorly kept to be inline with ASAN for user space > applications. > Also write is sometimes useful when uImage is already sanitized and some corruption > is done by kernel modules by doing some direct memory access then both read / write sanity of uImage > can be avoided. But then you don't need KASAN at all. >> disabling reads, right? >> Disabling both certainly does not make sense.