Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 26 May 2023 13:47:23 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Fangrui Song <maskray@google.com>
Cc:     Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>, ojeda@kernel.org,
        qing.zhao@oracle.com, morbo@google.com, llvm@lists.linux.dev,
        trix@redhat.com, linux-kernel@vger.kernel.org, nathan@kernel.org,
        linux-hardening@vger.kernel.org, gustavoars@kernel.org,
        ndesaulniers@google.com
Subject: Re: [PATCH v2] Compiler Attributes: Add __counted_by macro
Message-ID: <202305261344.A938E07789@keescook>
References: <20230517190841.gonna.796-kees@kernel.org>
 <168512138720.187005.8346289423859319616.b4-ty@chromium.org>
 <CANiq72=38mdTnJ3cicgwPB2xWqtbnGsL8Rtr4pwq7xGRr-m=Wg@mail.gmail.com>
 <202305261156.67CDEE933D@keescook>
 <CAFP8O3JO42CD2EXk+DJ5pci8ieHvRifAZpKg4iR_NiqTaYfLdA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAFP8O3JO42CD2EXk+DJ5pci8ieHvRifAZpKg4iR_NiqTaYfLdA@mail.gmail.com>
Precedence: bulk

On Fri, May 26, 2023 at 12:48:26PM -0700, Fangrui Song wrote:
> On Fri, May 26, 2023 at 11:56 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, May 26, 2023 at 07:47:03PM +0200, Miguel Ojeda wrote:
> > > On Fri, May 26, 2023 at 7:16 PM Kees Cook <keescook@chromium.org> wrote:
> > > >
> > > > FYI, applied to for-next/hardening:
> > > >
> > > > [1/1] Compiler Attributes: Add __counted_by macro
> > > >       https://git.kernel.org/kees/c/86a76e91cbab
> > >
> > > Sorry, I was going to apply it soon -- in case you want it:
> > >
> > >     Acked-by: Miguel Ojeda <ojeda@kernel.org>
> >
> > Thanks!
> >
> > > And thanks Nathan for resubmitting the `Reviewed-by` from v1!
> >
> > Yes, apologies for missing this in my v2 submission!
> >
> > --
> > Kees Cook
> >
> 
> https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854
> proposes a macro __counted_by as well.
> This patch uses the same name:
> 
> > # define __counted_by(member)          __attribute__((__element_count__(member)))
> 
> I wonder whether the two use cases are compatible so that using the
> same macro name will be fine.

Yeah, I have suggest the name change for the GCC proposal. However,
given that there is still no code to test for -fbounds-safety, I'm
sticking with __element_count for the moment, as there is code
implementing that name in both GCC and Clang today.

> #if defined(__has_feature) && __has_feature(bounds_safety)
> #define __counted_by(T) __attribute__((__counted_by__(T)))
> // ... other bounds annotations
> #else
> #define __counted_by(T) // defined as nothing // ... other bounds annotations
> #endif

Right. My main consideration for getting __counted_by defined by the
kernel at all is so that annotation can begin. We can adjust the
define's contents as needed. :)

-- 
Kees Cook