Le 07/02/2015 19:05, Christos Zoulas a écrit :
On Feb 7, 5:54pm, jym%NetBSD.org@localhost (Jean-Yves Migeon) wrote: -- Subject: Re: reallocarr(3) | Le 06/02/2015 01:50, Kamil Rytarowski a écrit : | > Is it fine to have this function for the kernel too? | | TBH I think that the kernel should rather rely on generic integer | overflow/underflow checks for its allocation APIs, a bit like the size | overflow plugin you can find in grsec. | | pool_cache(9) are generally sufficient enough to handle arrays of object | with a fixed size (behind the curtain), adding yet-another allocator | would not address the various kmem_alloc/malloc() call sites that | already exist in kernel. | | Of course this opinion is just mine :) The idiom number-of-elements * size is too common, and instead of protecting it by opencoding overflow everywhere, it is simpler to provide an allocator that does this internally...
True however the problem is moved elsewhere (in the function where the calculation and overflow is done internally). Note: I am not opposing that function in userland (after all this is a big gain), but in kernel I think that something more efficient can be done.
In userland you can't do much besides providing a new API that checks for overflow. Functions like these are typically part of a library (in this case: libc), and it is too late for the function to check for the "correctness" of its arguments. Therefore this only benefits the ones that use the API (almost) directly.
This situation is less problematic inside kernel where we have fewer ABI/API stability internally, so it is easier to instrument the compiler (llvm-ir or gimple) to put overflow checks before calling specific functions (allocators, routines with multi-dimensional arrays, etc). All functions may then benefit from it directly without having to rototill all places where "nelems * size" parameters get used. grsec does this for example, without needing an extensive patch to fix all kind of call sites.
IMHO the function can still be introduced for pragmatic reasons. But please, make it part of kmem(9) and not malloc(9).
Cheers, -- Jean-Yves Migeon