llvm dev - Jun 2012 - [LLVMdev] MemorySanitizer, a tool that finds uninitialized reads and more

On Mon, Jun 18, 2012 at 6:30 PM, Joerg Sonnenberger <joerg at
britannica.bec.de
> wrote:
> On Mon, Jun 18, 2012 at 05:52:49PM +0400, Kostya Serebryany wrote:
> > On Mon, Jun 18, 2012 at 5:43 PM, Joerg Sonnenberger <
> joerg at britannica.bec.de
> > > wrote:
> >
> > > On Mon, Jun 18, 2012 at 05:19:11PM +0400, Kostya Serebryany
wrote:
> > > > On Mon, Jun 18, 2012 at 5:07 PM, Joerg Sonnenberger <
> > > joerg at britannica.bec.de
> > > > > wrote:
> > > >
> > > > > On Mon, Jun 18, 2012 at 02:39:34PM +0400, Kostya
Serebryany wrote:
> > > > > > Another difference from Memcheck is that we
propose to use 8
> shadow
> > > bits
> > > > > > per byte of application memory and use a
> > > > > > direct shadow mapping (for 64-bit linux that is
just clearing
> 46-th
> > > bit
> > > > > of
> > > > > > the application memory address).
> > > > > > This greatly simplifies the instrumentation code
and avoids
> races on
> > > > > shadow
> > > > > > updates
> > > > > > (Memcheck is single-threaded so races are not a
concern there.
> > > > > > Memcheck uses 2 shadow bits per byte with a slow
path storage
> that
> > > uses 8
> > > > > > bits per byte).
> > > > >
> > > > > Can you make it possible for ASAN to share the same
layout?
> > > >
> > > >
> > > > Not sure I understand you. What layout?
> > >
> > > Shadow memory.
> > >
> >
> > yes, asan and msan shadow could co-exist, at least on 64-bit linux
with
> > disabled ASLR.
> > But the problem is that the memory overheads will multiply -- the
> combined
> > tool will be more expensive to use
> > than two separate tools together.
>
> Which is what I am asking about. I don't really have a problem with
> using a one-to-one mapping, if it makes both ASAN and MSAN more
> efficient in terms of runtime overhead.
>
one-to-one mapping will make ASAN much less efficient.
I meant that we may have both mappings (1:1 for MSAN and 8:1 for ASAN) in
the same process, but it makes little sense to me.

--kcc


>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120618/f216ca59/attachment.html>

On Mon, Jun 18, 2012 at 06:44:57PM +0400, Kostya Serebryany
wrote:
> On Mon, Jun 18, 2012 at 6:30 PM, Joerg Sonnenberger <joerg at
britannica.bec.de
> > wrote:
> 
> > On Mon, Jun 18, 2012 at 05:52:49PM +0400, Kostya Serebryany wrote:
> > > On Mon, Jun 18, 2012 at 5:43 PM, Joerg Sonnenberger <
> > joerg at britannica.bec.de
> > > > wrote:
> > >
> > > > On Mon, Jun 18, 2012 at 05:19:11PM +0400, Kostya Serebryany
wrote:
> > > > > On Mon, Jun 18, 2012 at 5:07 PM, Joerg Sonnenberger
<
> > > > joerg at britannica.bec.de
> > > > > > wrote:
> > > > >
> > > > > > On Mon, Jun 18, 2012 at 02:39:34PM +0400, Kostya
Serebryany wrote:
> > > > > > > Another difference from Memcheck is that we
propose to use 8
> > shadow
> > > > bits
> > > > > > > per byte of application memory and use a
> > > > > > > direct shadow mapping (for 64-bit linux that
is just clearing
> > 46-th
> > > > bit
> > > > > > of
> > > > > > > the application memory address).
> > > > > > > This greatly simplifies the instrumentation
code and avoids
> > races on
> > > > > > shadow
> > > > > > > updates
> > > > > > > (Memcheck is single-threaded so races are not
a concern there.
> > > > > > > Memcheck uses 2 shadow bits per byte with a
slow path storage
> > that
> > > > uses 8
> > > > > > > bits per byte).
> > > > > >
> > > > > > Can you make it possible for ASAN to share the
same layout?
> > > > >
> > > > >
> > > > > Not sure I understand you. What layout?
> > > >
> > > > Shadow memory.
> > > >
> > >
> > > yes, asan and msan shadow could co-exist, at least on 64-bit
linux with
> > > disabled ASLR.
> > > But the problem is that the memory overheads will multiply -- the
> > combined
> > > tool will be more expensive to use
> > > than two separate tools together.
> >
> > Which is what I am asking about. I don't really have a problem
with
> > using a one-to-one mapping, if it makes both ASAN and MSAN more
> > efficient in terms of runtime overhead.
> >
> 
> one-to-one mapping will make ASAN much less efficient.
> I meant that we may have both mappings (1:1 for MSAN and 8:1 for ASAN) in
> the same process, but it makes little sense to me.
Why can't ASAN use the same window as MSAN? That's the part I don't
understand.

Joerg

On Mon, Jun 18, 2012 at 8:19 PM, Joerg Sonnenberger <joerg at
britannica.bec.de
> wrote:
> On Mon, Jun 18, 2012 at 06:44:57PM +0400, Kostya Serebryany wrote:
> > On Mon, Jun 18, 2012 at 6:30 PM, Joerg Sonnenberger <
> joerg at britannica.bec.de
> > > wrote:
> >
> > > On Mon, Jun 18, 2012 at 05:52:49PM +0400, Kostya Serebryany
wrote:
> > > > On Mon, Jun 18, 2012 at 5:43 PM, Joerg Sonnenberger <
> > > joerg at britannica.bec.de
> > > > > wrote:
> > > >
> > > > > On Mon, Jun 18, 2012 at 05:19:11PM +0400, Kostya
Serebryany wrote:
> > > > > > On Mon, Jun 18, 2012 at 5:07 PM, Joerg
Sonnenberger <
> > > > > joerg at britannica.bec.de
> > > > > > > wrote:
> > > > > >
> > > > > > > On Mon, Jun 18, 2012 at 02:39:34PM +0400,
Kostya Serebryany
> wrote:
> > > > > > > > Another difference from Memcheck is that
we propose to use 8
> > > shadow
> > > > > bits
> > > > > > > > per byte of application memory and use a
> > > > > > > > direct shadow mapping (for 64-bit linux
that is just clearing
> > > 46-th
> > > > > bit
> > > > > > > of
> > > > > > > > the application memory address).
> > > > > > > > This greatly simplifies the
instrumentation code and avoids
> > > races on
> > > > > > > shadow
> > > > > > > > updates
> > > > > > > > (Memcheck is single-threaded so races
are not a concern
> there.
> > > > > > > > Memcheck uses 2 shadow bits per byte
with a slow path storage
> > > that
> > > > > uses 8
> > > > > > > > bits per byte).
> > > > > > >
> > > > > > > Can you make it possible for ASAN to share
the same layout?
> > > > > >
> > > > > >
> > > > > > Not sure I understand you. What layout?
> > > > >
> > > > > Shadow memory.
> > > > >
> > > >
> > > > yes, asan and msan shadow could co-exist, at least on 64-bit
linux
> with
> > > > disabled ASLR.
> > > > But the problem is that the memory overheads will multiply
-- the
> > > combined
> > > > tool will be more expensive to use
> > > > than two separate tools together.
> > >
> > > Which is what I am asking about. I don't really have a
problem with
> > > using a one-to-one mapping, if it makes both ASAN and MSAN more
> > > efficient in terms of runtime overhead.
> > >
> >
> > one-to-one mapping will make ASAN much less efficient.
> > I meant that we may have both mappings (1:1 for MSAN and 8:1 for ASAN)
in
> > the same process, but it makes little sense to me.
>
> Why can't ASAN use the same window as MSAN? That's the part I
don't
> understand.
>
asan uses 8:1 mapping, so the shadow overhead is 9/8.
But the real overhead comes from the heap redzones.
With 32-byte redzones we observe 2x-4x memory bloat, sometimes more.
If asan starts using 1:1 mapping (which was in the early version), this
bloat will be multiplied by 2, not by 9/8.
Besides, un/poisoning the shadow in asan will become 8x more expensive
(more important for stack).

Why do you worry about this?

--kcc


>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120618/14c6b11c/attachment.html>