From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id D9F7E3861806 for ; Fri, 27 Oct 2023 17:19:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D9F7E3861806 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=chromium.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D9F7E3861806 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::631 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698427170; cv=none; b=k2RSv0ctRxZWOv3OdEOQqI5KbC51u5z/BCc1GOfy6LAqc3qUxKmgM8TIwUJ6y0xTiZgAuVT7T2n4FESCCKV8Lb8+3lAivZO35FtYTvKu1qnBOFBDjQvOmsOb3M29wrqFtGXHuuK/Xeagh9ExYW3nN8DlCmtm2ZeRqTAQHtgzgXY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698427170; c=relaxed/simple; bh=J0JYOCYLGEVh99vo6ATACbbY+8wH7pRSgYLlmsEJYa8=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=ane5lQpyHHK7G14TFiK7OgM3Y2idPIcIILin/ncC0Rp/m/tPbjHFKu3mkMB2wNCHdx7HXJY/l4IEw9C5YwjvYT61MK5Eo+fk6PFXN5H/mdTnoblXTnuYSbo4gzlUUzGinypT4LFscB6HG2M5vjwwgCjl6ofEQEJGuzBxJBg8LBE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1c87a85332bso20494815ad.2 for ; Fri, 27 Oct 2023 10:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1698427168; x=1699031968; darn=gcc.gnu.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=FRNq4Fjs+afQ60ZuZUOsk0vOvcdctqxSI6UNnl1ILE0=; b=mVvdxNNlye4g6xZkJlobzU22FVXZ5MiRb4g8YfoJS6Ncs3ZWatTDBVud06VT1Ut3YL AwFzG3rs6+1NfTqEmdA4F/7Jzg7dwt9yaXTH1Ai2yohdJNHxNDNAgQFe1n9TwElO/H+0 qGpZre82erzTTiKfs9+EMyWq7xJTJgTcgjhKE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698427168; x=1699031968; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FRNq4Fjs+afQ60ZuZUOsk0vOvcdctqxSI6UNnl1ILE0=; b=KsmT2A7NtgJf+pleV+RtkBfVVQtpr7vsbmb49RfBsmbZuBX1Qa+V+XZbaxxMh4qigo 1/+Nt5xTJdeHtWSkdOcRSjXCRGqz6A7IxbKGe5i28iuao7q1n9o88w+E05LEyfumze72 0HO9q04g6b7Z1gn8/366/GVXQ2vcRbcemIb2SVGNrREh2k1tDCtGnOk8IsNrDNbCAZZN 6sYcEqKeeJ174zdS7nZ21NsJLbnAVFbArZnmckYZfRx1BFUNBzMFwdE1vcMHuOPs+UiM qWa6M6HfOkLwtk9hQ8I901aNlSgsa5icZ/tL5TdpSo3jR3+3evKUPXv0UOz021iqusvQ iYyg== X-Gm-Message-State: AOJu0Yx0c2uV0FMwxt/1Udt94s5uEhL0EWDOmQ/q9eKNXqoWe5D9hCIn Jm/vfSFCyVukQ473+x6VRUpctQ== X-Google-Smtp-Source: AGHT+IH6QtEWGCqcikIJ4InxvUhbhEXqVkTttwHByTJdwKVciPBoLdtvOWpyU22YP94ubVh/sI2j8Q== X-Received: by 2002:a17:902:d2cd:b0:1ca:3fa6:4aef with SMTP id n13-20020a170902d2cd00b001ca3fa64aefmr3936297plc.66.1698427167864; Fri, 27 Oct 2023 10:19:27 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id b8-20020a170902d50800b001c60635c13esm1809528plg.115.2023.10.27.10.19.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Oct 2023 10:19:27 -0700 (PDT) Date: Fri, 27 Oct 2023 10:19:26 -0700 From: Kees Cook To: Qing Zhao Cc: Martin Uecker , Siddhesh Poyarekar , Richard Biener , Joseph Myers , Jakub Jelinek , gcc Patches , "isanbard@gmail.com" Subject: Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896) Message-ID: <202310271006.8E04ABC@keescook> References: <947881C6-7040-4C73-8A81-0F364D0DF469@oracle.com> <202310251529.296AB019@keescook> <2df236317429b1c08fa11982d4e65a6b798bd4c6.camel@tugraz.at> <202310260851.B3719E6928@keescook> <6e07e4da210b3ee53e3bae5b18949a9d62b2a0b0.camel@tugraz.at> <081064A6-7104-4A12-8D11-BB3FA6EA55DF@oracle.com> <5a95d30d4e7cbfa71e24935072412c6d6ff55324.camel@tugraz.at> <5256BC97-043C-48BB-B664-1004C42DFD61@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5256BC97-043C-48BB-B664-1004C42DFD61@oracle.com> X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Oct 27, 2023 at 03:10:22PM +0000, Qing Zhao wrote: > Since the dynamic array support is quite important to the kernel (is this true, Kees? ), > We might need to include such support into our design in the beginning. tl;dr: We don't need "dynamic array support" in the 1st version of __counted_by I'm not sure it's as strong as "quite important", but it is a code pattern that exists. The vast majority of FAM usage is run-time fixed, in the sense that the allocation matches the usage. Only sometimes do we over-allocate and then slowly fill it up like I've shown. So really my thoughts on this are to bring light to the usage pattern in the hopes that we don't make it an impossible thing to do. And if it's a limitation of the initial version of __counted_by, the kernel can still use it: it will just need to use __counted_by strictly for allocation sizes, not "usage" size: struct foo { int allocated; int used; int array[] __counted_by(allocated); // would nice to use "used" }; struct foo *p; p = alloc(sizeof(*p) + sizeof(*p->array) * max_items); p->allocated = max_items; p->used = 0; while (data_available()) p->array[++p->used] = next_datum(); With this, we'll still catch p->array accesses beyond "allocated", but other code in the kernel won't catch "invalid data" accesses for p->array beyond "used". (i.e. we still have memory corruption protection, just not logic error protection.) We can deal with aliasing in the future if we want to expand to catching logic errors. I should not that we don't get logic error protection from things like ARM's Memory Tagging Extension either -- it only tracks allocation size (and is very expensive to change as the "used" part of an allocation grows), so this isn't an unreasonable condition for __counted_by to require as well. -- Kees Cook