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 5F9883858D39 for ; Wed, 2 Aug 2023 06:25:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F9883858D39 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at Received: from [192.168.0.171] (84-115-221-158.cable.dynamic.surfer.at [84.115.221.158]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4RG25V31Qdz1LM0V; Wed, 2 Aug 2023 08:25:02 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4RG25V31Qdz1LM0V DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1690957503; bh=vk+/zfiGX8X63ekepHxIQYTmbr2raujOQbkLU0Idfk0=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=m1/2ifLQFOp76P+iS83Vvyl2kAYJc7j4IKyAp5+Kfy0oRNsC6qgHushkyOaLVL5ok NaYybg1bgED0E/8L0L5j+3drDX9lGqKapb8IJiA4wWlKV8BAwxfW45YAMMGiYBa5g7 4yKMVmdkB81VH+hdCqRIVs7M87AWDGO8wOCJ82yw= Message-ID: <58462e61d6b09514c848cf1197f49290aeb87f45.camel@tugraz.at> Subject: Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896) From: Martin Uecker To: Kees Cook , Qing Zhao Cc: Siddhesh Poyarekar , "joseph@codesourcery.com" , "richard.guenther@gmail.com" , "jakub@redhat.com" , "gcc-patches@gcc.gnu.org" , "isanbard@gmail.com" Date: Wed, 02 Aug 2023 08:25:01 +0200 In-Reply-To: <202308011538.90858F8D2@keescook> References: <20230525161450.3704901-1-qing.zhao@oracle.com> <202305261218.2420AB8E0@keescook> <202307131311.1F30C4357@keescook> <202307171612.406D82C39@keescook> <72AF1253-564C-46C1-9FBC-5A53871CB701@oracle.com> <202308011538.90858F8D2@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.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,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: Am Dienstag, dem 01.08.2023 um 15:45 -0700 schrieb Kees Cook: > On Mon, Jul 31, 2023 at 08:14:42PM +0000, Qing Zhao wrote: > > /* In general, Due to type casting, the type for the pointee of a point= er > > does not say anything about the object it points to, > > So, __builtin_object_size can not directly use the type of the point= ee > > to decide the size of the object the pointer points to. > >=20 > > there are only two reliable ways: > > A. observed allocations (call to the allocation functions in the ro= utine) > > B. observed accesses (read or write access to the location of th= e=20 > > pointer points to) > >=20 > > that provide information about the type/existence of an object at > > the corresponding address. > >=20 > > for A, we use the "alloc_size" attribute for the corresponding alloc= ation > > functions to determine the object size; > >=20 > > For B, we use the SIZE info of the TYPE attached to the correspondin= g access. > > (We treat counted_by attribute as a complement to the SIZE info of t= he TYPE > > for FMA)=20 > >=20 > > The only other way in C which ensures that a pointer actually points > > to an object of the correct type is 'static': > >=20 > > void foo(struct P *p[static 1]); =20 > >=20 > > See https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624814.html > > for more details. */ >=20 > This is a great explanation; thank you! >=20 > In the future I might want to have a new builtin that will allow > a program to query a pointer when neither A nor B have happened. But > for the first version of the __counted_by infrastructure, the above > limitations seen fine. >=20 > For example, maybe __builtin_counted_size(p) (which returns sizeof(*p) + > sizeof(*p->flex_array_member) * p->counted_by_member). Though since > there might be multiple flex array members, maybe this can't work. :) We had a _Lengthof proposal for arrays (instead of sizeof/sizeof) and thought about how to extend this to structs with FAM. The problem is that it can not rely on an attribute. With GCC's VLA in structs you could do=C2=A0 struct foo { int n; char buf[n_init]; } *p =3D malloc(sizeof *p); p->n_init =3D n; and get sizeof and bounds checking with UBSan https://godbolt.org/z/d4nneqs3P (but also compiler bugs and other issues) Also see my experimental container library, where you can do: vec_decl(int); vec(int)* v =3D vec_alloc(int); vec_push(&v, 1); vec_push(&v, 3); auto p =3D &vec_array(v); (*p)[1] =3D 1; // bounds check Here, "vec_array()" would give you a regular C array view of the vector contant and with correct dynamic size, so you can apply "sizeof" and=C2=A0 have bounds checking with UBSan and it just works (with clang / GCC without changes).=C2=A0 https://github.com/uecker/noplate Martin