From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id 5396B3858D38 for ; Fri, 26 Jan 2024 08:04:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5396B3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5396B3858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706256250; cv=none; b=oCxHzZi6gXkbYHK/urCUSjX3yrBmpbatbyyG9BC2ILmdBgr1WGlXui676lM+M8OTMePMkk9jyvgBA2tmlLp4nnjWnn9Cbem0Y1XDukYBU40MSsqziWkoTvnQd6ugiFWdQUkCumweVVFYzkrJkU3Las/mf759kfiEoJb2oVUaVlk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706256250; c=relaxed/simple; bh=IpG/vZD3MDqRPtTM7TEO6BSiXgT9BY3NxLaTd+4nIA8=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=BXG7KJfamuX0rBDLtPx/vlX0TWYJJ/bQIGnvH3k9ET+corn4YxartLbYI3p7GUkDCxcwNgmjCkAJsuxz3hg5GXiYrPLA8geO1lXyAdU+IOJDK8fp01VJEGwvIDDYnySOepFkZ4N7b/JrvrT2aTNGXFRJ5RTsJwkzE92WxiZiJyM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from vra-168-131.tugraz.at (vra-168-131.tugraz.at [129.27.168.131]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4TLqw13JPzz1HNLZ; Fri, 26 Jan 2024 09:04:01 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4TLqw13JPzz1HNLZ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1706256242; bh=tX7UYHr6oN6NazueygSu7+Qo03DaxEtPJLqmxmST+ow=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=ZLE16Y0y5CwHMR9TwRsrxZToQwW+4MzvbZAbp9INMhaMWMZWKwM7nIFXBcaqvuDpM LK5AGIwzu/C3jY3uwjPbniW8E2Xdlw7jBo28mgac6COkfw8+zW4SO5Wzd4Lpe+06sK +dbp/ap1T6lRNaYrGUUt8vQjlzU8BHe7WRBkQ5qc= Message-ID: <08c3913ee0e75beb1fdfbce5487418fbd50de9e3.camel@tugraz.at> Subject: Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896) From: Martin Uecker To: Qing Zhao , Kees Cook Cc: "joseph@codesourcery.com" , "richard.guenther@gmail.com" , "jakub@redhat.com" , "siddhesh@gotplt.org" , "isanbard@gmail.com" , "gcc-patches@gcc.gnu.org" Date: Fri, 26 Jan 2024 09:04:00 +0100 In-Reply-To: References: <20240124002955.3387096-1-qing.zhao@oracle.com> <202401241624.4DC3D829@keescook> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -0.4 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: I haven't looked at the patch, but it sounds you give the result the wrong type. Then patching up all use cases instead of the type seems wrong. Martin Am Donnerstag, dem 25.01.2024 um 20:11 +0000 schrieb Qing Zhao: > Thanks a lot for the testing. >=20 > Yes, I can repeat the issue with the following small example: >=20 > #include > #include > #include >=20 > #define MAX(a, b) ((a) > (b) ? (a) : (b)) >=20 > struct untracked { > int size; > int array[] __attribute__((counted_by (size))); > } *a; > struct untracked * alloc_buf (int index) > { > struct untracked *p; > p =3D (struct untracked *) malloc (MAX (sizeof (struct untracked), > (offsetof (struct untracked, arra= y[0]) > + (index) * sizeof (int)))); > p->size =3D index; > return p; > } >=20 > int main() > { > a =3D alloc_buf(10); > printf ("same_type is %d\n", > (__builtin_types_compatible_p(typeof (a->array), typeof (&(a->array)[0]= )))); > return 0; > } >=20 >=20 > /home/opc/Install/latest-d/bin/gcc -O2 btcp.c > same_type is 1 >=20 > Looks like that the =E2=80=9Ctypeof=E2=80=9D operator need to be handled = specially in C FE > for the new internal function .ACCESS_WITH_SIZE.=20 >=20 > (I have specially handle the operator =E2=80=9Coffsetof=E2=80=9D in C FE = already). >=20 > Will fix this issue. >=20 > Thanks. >=20 > Qing >=20 > > On Jan 24, 2024, at 7:51 PM, Kees Cook wrote: > >=20 > > On Wed, Jan 24, 2024 at 12:29:51AM +0000, Qing Zhao wrote: > > > This is the 4th version of the patch. > >=20 > > Thanks very much for this! > >=20 > > I tripped over an unexpected behavioral change that the Linux kernel > > depends on: > >=20 > > __builtin_types_compatible_p() no longer treats an array marked with > > counted_by as different from that array's decayed pointer. Specifically= , > > the kernel uses these macros: > >=20 > >=20 > > /* > > * Force a compilation error if condition is true, but also produce a > > * result (of value 0 and type int), so the expression can be used > > * e.g. in a structure initializer (or where-ever else comma expressions > > * aren't permitted). > > */ > > #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); }))) > >=20 > > #define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeo= f(b)) > >=20 > > /* &a[0] degrades to a pointer: a different type from an array */ > > #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]= )) > >=20 > >=20 > > This gets used in various places to make sure we're dealing with an > > array for a macro: > >=20 > > #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_arr= ay(arr)) > >=20 > >=20 > > So this builds: > >=20 > > struct untracked { > > int size; > > int array[]; > > } *a; > >=20 > > __must_be_array(a->array) > > =3D> 0 (as expected) > > __builtin_types_compatible_p(typeof(a->array), typeof(&(a->array)[0])) > > =3D> 0 (as expected, array vs decayed array pointer) > >=20 > >=20 > > But if counted_by is added, we get a build failure: > >=20 > > struct tracked { > > int size; > > int array[] __counted_by(size); > > } *b; > >=20 > > __must_be_array(b->array) > > =3D> build failure (not expected) > > __builtin_types_compatible_p(typeof(b->array), typeof(&(b->array)[0])) > > =3D> 1 (not expected, both pointers?) > >=20 > >=20 > >=20 > >=20 > > --=20 > > Kees Cook >=20