Am Montag, dem 18.11.2024 um 21:31 +0000 schrieb Qing Zhao:
>
> > On Nov 18, 2024, at 13:10, Martin Uecker <uec...@tugraz.at> wrote:
>
...
> So, I guess that the more accurate question is, for the following:
>
> struct annotated {
> int b;
> int *c __attribute__ ((counted_by (b)));
> } *p_array_annotated;
>
> p_array_annotated->c[10] = 2;
>
>
> Should we treat the reference “p_array_annotated->c[10]” as
> an array reference if the pointer field “c” in the “struct annotated”
> has the counted_by attribute?
Assuming UBSan is they way to go, then yes and I agree
that after casting to another type this should not be
done anymore.
>
> >
> > I am a bit frustrated about the sanitizer. On the
> > one hand, it is not doing enough to get spatial memory
> > safety even where this would be easily possible, on the
> > other hand, is pedantic about things which are technically
> > UB but not problematic and then one is prevented from
> > using it.
>
> Yes, In order to make sanitizer better, both the above issues need to be
> addressed.
> >
> > When used in default mode, where execution continues, it
> > also does not mix well with many warning, creates more code,
> > and pulls in a libary dependency (and the library also depends
> > on upstream choices / progress which seems a limitation for
> > extensions).
>
> Right, all these are existing issues with the current sanitizer.
> >
> > What IMHO would be ideal is a protection mode for spatial
> > memory safety that simply adds traps (which then requires
> > no library, has no issues with other warnings, and could
> > evolve independently from clang)
> >
> > So shouldn't we just add a -fboundscheck (which would
> > be like -fsanitize=bounds -fsanitize-trap=bounds just with
> > more checking) and make it really good? I think many people
> > would be very happy about this.
>
> Then why not just fix the known issues in the current
> -fsanitize=bounds -fsanitize-trap=bounds to make it better?
> What’s the major benefit to add another new option?
The question is how to fix this?
At the moment the sanitizer is tied to a shared C++ library
maintained elsewhere (I believe) with a design that ties
every specific case to a specific entry point in this library.
So the UBsan handlers become part of an ABI that needs to
be maintained and upgraded. Also you need to reimplement
this when using it somewhere we you can't have a C++ library.
(I assume kernels or embedded platforms have all their
own implementations). If we add something, everything
needs to be upgraded. For 'counted_by' and 'bounds' you
may get a way with the existing message.
Martin
>
> Thanks.
>
> Qing
> >
> > Martin
> >
> >
> > >
> > > For the following small example:
> > >
> > > #include <stdlib.h>
> > >
> > > struct annotated {
> > > int b;
> > > int *c __attribute__ ((counted_by (b)));
> > > } *p_array_annotated;
> > >
> > > void __attribute__((__noinline__)) setup (int annotated_count)
> > > {
> > > p_array_annotated
> > > = (struct annotated *)malloc (sizeof (struct annotated));
> > > p_array_annotated->c = (int *) malloc (annotated_count * sizeof (int));
> > > p_array_annotated->b = annotated_count;
> > >
> > > return;
> > > }
> > >
> > > int main(int argc, char *argv[])
> > > {
> > > setup (10);
> > > p_array_annotated->c[11] = 2;
> > > return 0;
> > > }
> > >
> > > Should ubsan add instrumentation to the above reference
> > > p_array_annoated->c[11] inside routine “main”?
> > >
> > > From my understanding, ubsan does not add bound checking for any pointer
> > > reference now, however, when the “counted_by” attribute is attached to a
> > > pointer field inside a structure, the “bound” information for this
> > > pointer is known, should we enhance the ubsan to instrument such
> > > reference?
> > >
> > > If Yes, then should we add the following limitation to the end user:
> > >
> > > When the counted_by attribute is attached to a pointer field, the
> > > -fsantize=bounds only work for such reference when the pointer is NOT
> > > casted to another type other than the original target type?
> > >
> > > Thanks for any comments and suggestions.
> > >
> > > Qing
> >
>
