From: "Vaneet Narang" <v.narang@samsung.com>
To: "Dmitry Vyukov" <dvyukov@google.com>,
"Maninder Singh" <maninder1.s@samsung.com>
Cc: "Michal Marek" <mmarek@suse.com>,
"Andrey Ryabinin" <aryabinin@virtuozzo.com>,
"Alexander Potapenko" <glider@google.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
"open list:KERNEL BUILD + fi..." <linux-kbuild@vger.kernel.org>,
kasan-dev <kasan-dev@googlegroups.com>,
"PANKAJ MISHRA" <pankaj.m@samsung.com>,
"Ajeet Kumar Yadav" <ajeet.y@samsung.com>
Subject: RE: Re: [PATCH 1/1] kasan: Support for r/w instrumentation control
Date: Mon, 12 Dec 2016 10:29:05 +0000 [thread overview]
Message-ID: <20161212102905epcms5p4ae1ddc2405b942e2d65e5cda4bc4abd4@epcms5p4> (raw)
In-Reply-To: <CGME20161212100600epcas4p2417928d125eb8b25589023cf0fdb733f@epcas4p2.samsung.com>
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
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.
> 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.
> disabling reads, right?
> Disabling both certainly does not make sense.
Regards,
Vaneet Narang
next prev parent reply other threads:[~2016-12-12 10:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-12 9:32 Maninder Singh
2016-12-12 10:05 ` Dmitry Vyukov
[not found] ` <CGME20161212100600epcas4p2417928d125eb8b25589023cf0fdb733f@epcas4p2.samsung.com>
2016-12-12 10:29 ` Vaneet Narang [this message]
2016-12-12 10:49 ` Dmitry Vyukov
2016-12-12 11:12 ` Vaneet Narang
[not found] ` <CACT4Y+YGK=2beyfo14ibOx92Lf8MefjQe5PhH2BSSj=v2pFaRw@mail.gmail.com>
2016-12-12 13:44 ` Dmitry Vyukov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161212102905epcms5p4ae1ddc2405b942e2d65e5cda4bc4abd4@epcms5p4 \
--to=v.narang@samsung.com \
--cc=ajeet.y@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maninder1.s@samsung.com \
--cc=mmarek@suse.com \
--cc=pankaj.m@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®