On Thu, Oct 29, 2020 at 2:17 PM Marco Elver <elver@xxxxxxxxxx> wrote: > Add KFENCE documentation in dev-tools/kfence.rst, and add to index. [...] > +The KFENCE memory pool is of fixed size, and if the pool is exhausted, no > +further KFENCE allocations occur. With ``CONFIG_KFENCE_NUM_OBJECTS`` (default > +255), the number of available guarded objects can be controlled. Each object > +requires 2 pages, one for the object itself and the other one used as a guard > +page; object pages are interleaved with guard pages, and every object page is > +therefore surrounded by two guard pages. > + > +The total memory dedicated to the KFENCE memory pool can be computed as:: > + > + ( #objects + 1 ) * 2 * PAGE_SIZE Plus memory overhead from shattered hugepages. With the default object count, on x86, we allocate 2MiB of memory pool, but if we have to shatter a 2MiB hugepage for that, we may cause the allocation of one extra page table, or 4KiB. Of course that's pretty much negligible. But on arm64 it's worse, because there we have to disable hugepages in the linear map completely. So on a device with 4GiB memory, we might end up with something on the order of 4GiB/2MiB * 0x1000 bytes = 8MiB of extra L1 page tables that wouldn't have been needed otherwise - significantly more than the default memory pool size. If the memory overhead is documented, this detail should probably be documented, too. > +Using the default config, and assuming a page size of 4 KiB, results in > +dedicating 2 MiB to the KFENCE memory pool. [...] > +For such errors, the address where the corruption as well as the invalidly nit: "the address where the corruption occurred" or "the address of the corruption" > +written bytes (offset from the address) are shown; in this representation, '.' > +denote untouched bytes. In the example above ``0xac`` is the value written to > +the invalid address at offset 0, and the remaining '.' denote that no following > +bytes have been touched. Note that, real values are only shown for > +``CONFIG_DEBUG_KERNEL=y`` builds; to avoid information disclosure for non-debug > +builds, '!' is used instead to denote invalidly written bytes. [...] > +KFENCE objects each reside on a dedicated page, at either the left or right > +page boundaries selected at random. 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. Such page faults are then > +intercepted by KFENCE, which handles the fault gracefully by reporting an > +out-of-bounds access. ... and marking the page as accessible so that the faulting code can continue (wrongly) executing. [...] > +Interface > +--------- > + > +The following describes the functions which are used by allocators as well page nit: "as well as"? > +handling code to set up and deal with KFENCE allocations.
