linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Wengang Wang <wen.gang.wang@oracle.com>
Cc: Dmitry Vyukov <dvyukov@google.com>, Linux-MM <linux-mm@kvack.org>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	kasan-dev <kasan-dev@googlegroups.com>
Subject: Re: [PATCH 0/5] mm/kasan: advanced check
Date: Thu, 23 Nov 2017 15:35:14 +0900	[thread overview]
Message-ID: <20171123063514.GD31720@js1304-P5Q-DELUXE> (raw)
In-Reply-To: <20171123062317.GC31720@js1304-P5Q-DELUXE>

On Thu, Nov 23, 2017 at 03:23:17PM +0900, Joonsoo Kim wrote:
> On Wed, Nov 22, 2017 at 11:43:00AM -0800, Wengang Wang wrote:
> > >
> > >
> > >>There do is the case you pointed out here. In this case, the
> > >>debugger can make slight change to the calling path. And as I
> > >>understand,
> > >>most of the overwritten are happening in quite different call paths,
> > >>they are not calling the (owning) caller.
> > >Agreed.
> > >
> > >>>FYI, I attach some commit descriptions of the vchecker.
> > >>>
> > >>>     vchecker: store/report callstack of value writer
> > >>>     The purpose of the value checker is finding invalid user writing
> > >>>     invalid value at the moment that the value is written. However, there is
> > >>>     a missing infrastructure that passes writing value to the checker
> > >>>     since we temporarilly piggyback on the KASAN. So, we cannot easily
> > >>>     detect this case in time.
> > >>>     However, by following way, we can emulate similar effect.
> > >>>     1. Store callstack when memory is written.
> > >>Oh, seems you are storing the callstack for each write. -- I am not
> > >>sure if that would too heavy.
> > >Unlike KASAN that checks all type of the objects, this debugging
> > >feature is only enabled on the specific type of the objects so
> > >overhead would not be too heavy in terms of system overall
> > >performance.
> > Yes, only specific type of objects do the extra stuff, but I am not
> > sure if the overall
> > performance to be affected. Actually I was thinking of tracking last
> > write stack.
> > At that time, I had two concerns: one is the performance affect; the
> > other is if it's safe
> > since memory access can happen in any context -- process context,
> > soft irq and irq..

Oops. I missed this question. vchecker works well on all contexts
however there is a possibilty to miss the callstack due to memory
allocation failure in stackdepot. It would be rare case since
stackdepot has some protection to this problem. Note that KASAN has
the same problem and it works well until now.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-11-23  6:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-17 22:30 Wengang Wang
2017-11-17 22:30 ` [PATCH 1/5] mm/kasan: make space in shadow bytes for " Wengang Wang
2017-11-17 22:30 ` [PATCH 2/5] mm/kasan: pass access mode to poison check functions Wengang Wang
2017-11-17 22:30 ` [PATCH 3/5] mm/kasan: do advanced check Wengang Wang
2017-11-17 22:30 ` [PATCH 4/5] mm/kasan: register check and bind it to memory Wengang Wang
2017-11-17 22:30 ` [PATCH 5/5] mm/kasan: add advanced check test case Wengang Wang
2017-11-17 22:32 ` [PATCH 0/5] mm/kasan: advanced check Wengang Wang
2017-11-17 22:56 ` Dmitry Vyukov
2017-11-20  1:50   ` Joonsoo Kim
2017-11-20  8:41     ` Dmitry Vyukov
2017-11-20 20:05       ` Wengang
2017-11-20 20:20         ` Dmitry Vyukov
2017-11-20 20:29           ` Wengang
2017-11-21  9:54             ` Dmitry Vyukov
2017-11-21 19:17               ` Wengang Wang
2017-11-22  8:48                 ` Dmitry Vyukov
2017-11-22 21:09                   ` Wengang Wang
2017-11-20 19:56     ` Wengang
2017-11-22  4:30       ` Joonsoo Kim
2017-11-22  8:51         ` Dmitry Vyukov
2017-11-23  6:07           ` Joonsoo Kim
2017-11-22 19:43         ` Wengang Wang
2017-11-23  6:23           ` Joonsoo Kim
2017-11-23  6:35             ` Joonsoo Kim [this message]
2017-11-22 12:04     ` Andrey Ryabinin
2017-11-23  5:57       ` Joonsoo Kim
2017-11-22 12:04 ` Andrey Ryabinin
2017-11-22 19:29   ` Wengang Wang
2017-11-26 19:37     ` Wengang Wang

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=20171123063514.GD31720@js1304-P5Q-DELUXE \
    --to=iamjoonsoo.kim@lge.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-mm@kvack.org \
    --cc=wen.gang.wang@oracle.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