Re: Making adaptive redzones less aggressive

['Alexander Potapenko' via address-sanitizer]

On Sat, Jul 15, 2017 at 4:39 PM, Yuri Gribov  wrote:
> Hi all,
>
> From reading the original feature request in
> https://github.com/google/sanitizers/issues/8 it seems that adaptive
> redzones were mainly meant for catching overflows in arrays of large
> objects e.g.
>
>   struct {
> int a[10];
> int x;
>   } a[100];
>   a[101].x = 0;  // Skips redzone
>
> Current adaptation only considers size of array as a whole so would
> add similarly big redzone for same-sized
>
>   int a[1100];
>
> even though risk of large overflow offset here seems to be much lower.
>
> Has anyone considered selecting redzone based on array element size
> rather than array size? Firstly this would allow more intelligent
> redzone selection (current approach does not guarantee that generated
> redzone will cover one array element) and also reduce memory pressure
> (which is important for "embedded" targets).

I totally agree that for compound type arrays the redzone size must be
based on the array element size.

Not sure if we need to reduce the redzone size for big arrays of
scalars, as e.g. char arrays are sometimes used as opaque storage for
compound types.
Do you have any evidence how big is the memory overhead caused by
redzones in this case?
> -Y
>
> --
> You received this message because you are subscribed to the Google Groups 
> "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to address-sanitizer+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making adaptive redzones less aggressive

[Yuri Gribov]

On Mon, Jul 17, 2017 at 10:25 AM, 'Alexander Potapenko' via
address-sanitizer  wrote:
> On Sat, Jul 15, 2017 at 4:39 PM, Yuri Gribov  wrote:
>> Hi all,
>>
>> From reading the original feature request in
>> https://github.com/google/sanitizers/issues/8 it seems that adaptive
>> redzones were mainly meant for catching overflows in arrays of large
>> objects e.g.
>>
>>   struct {
>> int a[10];
>> int x;
>>   } a[100];
>>   a[101].x = 0;  // Skips redzone
>>
>> Current adaptation only considers size of array as a whole so would
>> add similarly big redzone for same-sized
>>
>>   int a[1100];
>>
>> even though risk of large overflow offset here seems to be much lower.
>>
>> Has anyone considered selecting redzone based on array element size
>> rather than array size? Firstly this would allow more intelligent
>> redzone selection (current approach does not guarantee that generated
>> redzone will cover one array element) and also reduce memory pressure
>> (which is important for "embedded" targets).
>
> I totally agree that for compound type arrays the redzone size must be
> based on the array element size.
>
> Not sure if we need to reduce the redzone size for big arrays of
> scalars, as e.g. char arrays are sometimes used as opaque storage for
> compound types.

Good point.

> Do you have any evidence how big is the memory overhead caused by
> redzones in this case?

Not yet, this is something we'll need to investigate (my question was
mainly whether it makes sense to investigate this).

-Y

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making adaptive redzones less aggressive

[Konstantin Serebryany]

I can argue that this heuristic is totally relevant for 'int a[1100]'
because lots of scientific code uses single-dimensional arrays as
n-dimensional:

#define N 100
int a[N * N];
...
a[i * N + j];  // off-by-one in 'i' will lead to off-by-N

And no, I did not try to investigate if a better heuristic is possible.
The basis for the current heuristic is that it does not increase the memory
footprint (for globals) by more than X%.

--kcc






On Mon, Jul 17, 2017 at 2:41 AM, Yuri Gribov  wrote:

> On Mon, Jul 17, 2017 at 10:25 AM, 'Alexander Potapenko' via
> address-sanitizer  wrote:
> > On Sat, Jul 15, 2017 at 4:39 PM, Yuri Gribov 
> wrote:
> >> Hi all,
> >>
> >> From reading the original feature request in
> >> https://github.com/google/sanitizers/issues/8 it seems that adaptive
> >> redzones were mainly meant for catching overflows in arrays of large
> >> objects e.g.
> >>
> >>   struct {
> >> int a[10];
> >> int x;
> >>   } a[100];
> >>   a[101].x = 0;  // Skips redzone
> >>
> >> Current adaptation only considers size of array as a whole so would
> >> add similarly big redzone for same-sized
> >>
> >>   int a[1100];
> >>
> >> even though risk of large overflow offset here seems to be much lower.
> >>
> >> Has anyone considered selecting redzone based on array element size
> >> rather than array size? Firstly this would allow more intelligent
> >> redzone selection (current approach does not guarantee that generated
> >> redzone will cover one array element) and also reduce memory pressure
> >> (which is important for "embedded" targets).
> >
> > I totally agree that for compound type arrays the redzone size must be
> > based on the array element size.
> >
> > Not sure if we need to reduce the redzone size for big arrays of
> > scalars, as e.g. char arrays are sometimes used as opaque storage for
> > compound types.
>
> Good point.
>
> > Do you have any evidence how big is the memory overhead caused by
> > redzones in this case?
>
> Not yet, this is something we'll need to investigate (my question was
> mainly whether it makes sense to investigate this).
>
> -Y
>
> --
> You received this message because you are subscribed to the Google Groups
> "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to address-sanitizer+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.