From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dog.birch.relay.mailchannels.net (dog.birch.relay.mailchannels.net [23.83.209.48]) by sourceware.org (Postfix) with ESMTPS id 795013858C52 for ; Wed, 18 Oct 2023 15:37:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 795013858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 795013858C52 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=23.83.209.48 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697643471; cv=pass; b=ey+J6Kh4/gpbZUsqA2FItzIYKWN0fYhMxOxkclVil8f3n5yciNG/1+huYOtCZhFrpJVyG7Vl9btrim/VsAiq61yMO48DRwDyPchBMKSJpg+VwqsCfUtoHvxc7I5l4vjVslLQn5s2oxGCsv5XVGMsbp8xpR8G2Yj4Ioogv53UVa0= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697643471; c=relaxed/simple; bh=ZRH24/FWm6ZxsNhBDY272WDsrH0Fqv0w+8LIk088BNo=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=f0I+vAuB/NUn4QX+Pb7QH9tS7n9H8nJxXIuRwgIwXUdWiHCz6x0ywGnY7ynbnxjwmg9vZxfpkawAsnv8DHurmgp23yyNyckLTXvfeU+dzvHULAR64zFdS3UPmT0dwmXEz+XzRruaczPkTyKM9g69TJfOP9PrbATjkINjxrqpDyM= ARC-Authentication-Results: i=2; server2.sourceware.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id DFCE4419D6; Wed, 18 Oct 2023 15:37:43 +0000 (UTC) Received: from pdx1-sub0-mail-a202.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 4F7A8401FD; Wed, 18 Oct 2023 15:37:43 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1697643463; a=rsa-sha256; cv=none; b=PXf5igYOrOaGR15++gpWEDm9PLh8mvkhWkq6j3FfU4VgfGrMvE0rX4R69eBLvaWd+kOkFp rgsxoKH5SKUUZ7MJ/6GczQR1C1d8RmWz/N59zAL0ymmxWDM1OEAI4icBgG9mW/R/gAPpCg OA1GpBgmpeKoYdDyLK+u+aVzGueLO8olr+obxLc5UuHXXDqn5XlUJNn5L0Syfwzj/IUbSz jDs6EleZjrlPRqqzT4OJLzGp8yJU2hr54ozzXyt1SaIEpLsIXK15dEaKFnyRYqLn72Jjpy fVsMkA7a9O6qcogooxc0nAs63KsI/iJa3TfBFTQRpZeLsAZUW5pFl6iVzmzbaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1697643463; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JRxb+st/O5ejOa86KYFd35e3eTSJzkqC3jvj9ajfnZo=; b=7ihynZ/8xXNdv0l86LFylaGgV7boggSihoePV3WxWnlqcfphgbgPMfbFvBxPYs3GHo1bHi EWJnGmoBesImu+/YNB5h28s/gXJWd+xknMiAiG7F7z8sgQTeXRXakVcU08CWIcdY+uMgZj 3bMeGg91CrjmgPObXXHwoDkTPUiAx1ZdsNrws0/3Ch3aKttt8tZk4BLagZyWPbf1cbscTy wRGsNHUWOzYGzOcA6RJ+DxwGNHeCK6+MGznaKfDsDUQYbakMXD86gD9PKCXPIG0YfkaMi2 GlIT3h4vDiTghX6d2D0iyGtchmmPcoiIXfW2xVGUnAsfDBazPpF7JbWM4xFtUQ== ARC-Authentication-Results: i=1; rspamd-555cdc57c9-tl2cp; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Arithmetic-Suffer: 752678a029939de8_1697643463754_4146680498 X-MC-Loop-Signature: 1697643463754:3810914595 X-MC-Ingress-Time: 1697643463754 Received: from pdx1-sub0-mail-a202.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.126.222.52 (trex/6.9.2); Wed, 18 Oct 2023 15:37:43 +0000 Received: from [192.168.2.12] (bras-vprn-toroon4834w-lp130-02-142-113-138-136.dsl.bell.ca [142.113.138.136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a202.dreamhost.com (Postfix) with ESMTPSA id 4S9Zjf3gM0zX7; Wed, 18 Oct 2023 08:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1697643463; bh=JRxb+st/O5ejOa86KYFd35e3eTSJzkqC3jvj9ajfnZo=; h=Date:To:Cc:From:Subject:Content-Type:Content-Transfer-Encoding; b=L91a7+BILHus/4VetPfPwOzwx0ugooiWoYs7BoZQAfFwV+6Ocd7EJUSOIDJ4XXE7E nEjd08hWqgtmGQ3kAaq+lKH4oF5ra3twPwUwPWvytjygTLjts/qq9Ngif1X32b1Sqm v5Pkwf7WKCJzVFVi8s45Tki4zrhDc8gMbmpIvqn1ToNcqFyYc3SnolyKW/puUYvZW1 0LRHVcvh9ltIBtUPRLCejSRQ43BS+rn2ieuCKI4yUnHutWC+sbMuNsMwg1LHyF2SOs Z/QKc1O70v0458hIN3yvP/mxz6FJofoD/rD9qA5DBFCPezuxvRYwSFjQst5XcZcein 0raOh0Px17GWw== Message-ID: <75763e27-1883-c409-a277-05585d174be3@gotplt.org> Date: Wed, 18 Oct 2023 11:37:20 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Content-Language: en-US To: Martin Uecker , Kees Cook Cc: Qing Zhao , joseph@codesourcery.com, richard.guenther@gmail.com, jakub@redhat.com, gcc-patches@gcc.gnu.org, isanbard@gmail.com References: <20230825152425.2417656-1-qing.zhao@oracle.com> <202310051529.7F8FEFBAA@keescook> <7636ed2764630383cce60d3c5a6c78d6a1a49edd.camel@tugraz.at> <5da583e1-5efd-4bc5-6769-e714ce0f3646@gotplt.org> <1f0e32201a97f31e17323e3038a852eb0c5c6209.camel@tugraz.at> From: Siddhesh Poyarekar Subject: Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896) In-Reply-To: <1f0e32201a97f31e17323e3038a852eb0c5c6209.camel@tugraz.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3031.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP 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: [Sorry, I forgot to respond to this] On 2023-10-06 16:01, Martin Uecker wrote: > Am Freitag, dem 06.10.2023 um 06:50 -0400 schrieb Siddhesh Poyarekar: >> On 2023-10-06 01:11, Martin Uecker wrote: >>> Am Donnerstag, dem 05.10.2023 um 15:35 -0700 schrieb Kees Cook: >>>> On Thu, Oct 05, 2023 at 04:08:52PM -0400, Siddhesh Poyarekar wrote: >>>>> 2. How would you handle signedness of the size field? The size gets >>>>> converted to sizetype everywhere it is used and overflows/underflows may >>>>> produce interesting results. Do you want to limit the types to unsigned or >>>>> do you want to add a disclaimer in the docs? The former seems like the >>>>> *right* thing to do given that it is a new feature; best to enforce the >>>>> cleaner habit at the outset. >>>> >>>> The Linux kernel has a lot of "int" counters, so the goal is to catch >>>> negative offsets just like too-large offsets at runtime with the sanitizer >>>> and report 0 for __bdos. Refactoring all these to be unsigned is going >>>> to take time since at least some of them use the negative values as >>>> special values unrelated to array indexing. :( >>>> >>>> So, perhaps if unsigned counters are worth enforcing, can this be a >>>> separate warning the kernel can turn off initially? >>>> >>> >>> I think unsigned counters are much more problematic than signed ones >>> because wraparound errors are more difficult to find. >>> >>> With unsigned you could potentially diagnose wraparound, but only if we >>> add -fsanitize=unsigned-overflow *and* add mechanism to mark intentional >>> wraparound *and* everybody adds this annotation after carefully screening >>> their code *and* rewriting all operations such as (counter - 3) + 5 >>> where the wraparound in the intermediate expression is harmless. >>> >>> For this reason, I do not think we should ever enforce some rule that >>> the counter has to be unsigned. >>> >>> What we could do, is detect *storing* negative values into the >>> counter at run-time using UBSan. (but if negative values are >>> used for special cases, one also should be able to turn this >>> off). >> >> All of the object size detection relies on object sizes being sizetype. >> The closest we could do with that is detect (sz != SIZE_MAX && sz > >> size_t / 2), since allocators typically cannot allocate more than >> SIZE_MAX / 2. > > I was talking about the counter in: > > struct { > int counter; > char buf[] __counted_by__((counter)) > }; > > which could be checked to be positive either when stored to or > when buf is used. > > And yes, we could also check the size of buf. Not sure what is > done for VLAs now, but I guess it could be similar. Right now all object sizes are cast to sizetype and the generated dynamic expressions are such that overflows will result in the computed object size being zero. Non-generated expressions (like we could get with __counted_by__) will simply be cast; there's probably scope for improvement here, where we wrap that with an expression that returns 0 if the size exceeds SIZE_MAX / 2 since that's typically the limit for allocators. We use that heuristic elsewhere in the __bos/__bdos logic too. Thanks, Sid