Okay, thanks for the explanation.
We will keep this in mind.
Qing
> On Oct 27, 2023, at 1:19 PM, Kees Cook <keesc...@chromium.org> wrote:
>
> 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
