On Fri, Oct 30, 2020 at 3:50 AM Jann Horn <jannh@xxxxxxxxxx> wrote: > > 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. Note that with CONFIG_RODATA_FULL_DEFAULT_ENABLED (which is on by default now) these hugepages are already disabled (see patch 3/9) > If the memory overhead is documented, this detail should probably be > documented, too. But, yes, documenting that also makes sense. > > +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. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
