On Fri, Mar 21, 2025 at 09:55:10AM -0400, Mark Johnston wrote: M> > I was about to suggest that, but was afraid it is too naive :) But M> > if that works, why not? We probably should document that for M> > contigmalloc() the redzone would provide protection of the virtual M> > space, but not the physical. M> M> I'm not sure what you mean by this? As implemented, the patch M> effectively rounds up the allocation size, so the redzone will also be M> physically contiguous. Though, I see now that this will result in an M> non-page-aligned allocation, which callers of contigmalloc() might M> not tolerate... M> M> Actually, for malloc_large() and contigmalloc() allocations it's M> probably a bit easier to just provide guard pages around the M> allocation, like we do for kernel stacks. That is, if the caller asks M> for N pages, then allocate N+2 pages of virtual address space and back M> pages [1, N] with physical memory. Then any overflow will trap at the M> site of the overflow, which is probably more useful than what M> redzone(9). Actually, KASAN provides the same checking, but currently M> we don't pad allocations when KASAN is enabled. M> M> > M> Compile-tested patch below: M> > M> > Why do you increase the size with redzone_size_ntor() before passing M> > it to redzone_setup()? Other calls to redzone_setup() don't do that. M> > My reading is that argument to redzone_setup() shall be exactly the M> > amount of bytes requested by the malloc KPI user. If you pass M> > increased value, the canaries will be written after a gap. M> M> I pass "osize", the original allocation size, to redzone_setup().
I see the point, with growing the original size you also guarantee red zone both in physical and virtual memory. Got it, thanks! -- Gleb Smirnoff
