[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
IMHO the function can still be introduced for pragmatic reasons. But
please, make it part of kmem(9) and not malloc(9).
Main Index |
Thread Index |