> On Nov 18, 2024, at 13:10, Martin Uecker <uec...@tugraz.at> wrote: > > Am Montag, dem 18.11.2024 um 17:55 +0000 schrieb Qing Zhao: >> Hi, >> >> I am working on extending “counted_by” attribute to pointers inside a >> structure per our previous discussion. >> >> I need advice on the following question: >> >> Should -fsantize=bounds support array reference that was referenced through >> a pointer that has counted_by attribute? > > I think the question is what -fsanitize=bounds is meant to be.
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Instrumentation-Options.html#index-fsanitize_003dbounds -fsanitize=bounds This option enables instrumentation of array bounds. Various out of bounds accesses are detected. Flexible array members, flexible array member-like arrays, and initializers of variables with static storage are not instrumented, with the exception of flexible array member-like arrays for which -fstrict-flex-arrays or -fstrict-flex-arrays= options or strict_flex_array attributes say they shouldn’t be treated like flexible array member-like arrays. 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? > > 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? 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 >
