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
