[PATCH RFC 00/10] KFENCE: A low-overhead sampling-based memory safety error detector

[Dave Hansen]

On 9/8/20 8:31 AM, Marco Elver wrote:
...
> If you can afford to use KASAN, continue using KASAN. Usually this only
> applies to test environments. If you have kernels for production use,
> and cannot enable KASAN for the obvious cost reasons, you could consider
> KFENCE.

That's a really nice, succinct way to put it.  You might even want to
consider putting this in the Kconfig help text.


>>> KFENCE objects each reside on a dedicated page, at either the left or
>>> right page boundaries. The pages to the left and right of the object
>>> page are "guard pages", whose attributes are changed to a protected
>>> state, and cause page faults on any attempted access to them. Such page
>>> faults are then intercepted by KFENCE, which handles the fault
>>> gracefully by reporting a memory access error.
>>
>> How much memory overhead does this end up having?  I know it depends on
>> the object size and so forth.  But, could you give some real-world
>> examples of memory consumption?  Also, what's the worst case?  Say I
>> have a ton of worst-case-sized (32b) slab objects.  Will I notice?
> 
> KFENCE objects are limited (default 255). If we exhaust KFENCE's memory
> pool, no more KFENCE allocations will occur.
> Documentation/dev-tools/kfence.rst gives a formula to calculate the
> KFENCE pool size:
> 
> 	The total memory dedicated to the KFENCE memory pool can be computed as::
> 
> 	    ( #objects + 1 ) * 2 * PAGE_SIZE
> 
> 	Using the default config, and assuming a page size of 4 KiB, results in
> 	dedicating 2 MiB to the KFENCE memory pool.
> 
> Does that clarify this point? Or anything else that could help clarify
> this?

That clears it up, thanks!

I would suggest adding a tiny nugget about this in the cover letter,
just saying that the worst-case memory consumption on x86 is ~2M.