Re: [PATCH 0/5] mm/kasan: advanced check

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux