Date: Fri, 21 Mar 2025 10:35:50 -0700 From: Gleb Smirnoff <glebius@freebsd.org> To: Mark Johnston <markj@freebsd.org> Cc: "Bjoern A. Zeeb" <bz@freebsd.org>, David Wolfskill <david@catwhisker.org>, current@freebsd.org, kib@freebsd.org, jhb@freebsd.org Subject: Re: Possible video driver issue after main-n275966-d2a55e6a9348 -> main-n275975-5963423232e8 Message-ID: <Z92jdusq_7ri4_wK@cell.glebi.us> In-Reply-To: <Z91vvp9uG8Fv3_bt@framework> References: <Z9jRXIe5cNnlRfhU@albert.catwhisker.org> <01qqq28n-p1s3-n82q-9n1s-7o900ro5n62q@SerrOFQ.bet> <Z9l7vF_gt57AyzDC@albert.catwhisker.org> <Z9mN10KGg_pQXbly@albert.catwhisker.org> <Z9oBNVH7l8QKHSC3@cell.glebi.us> <rp062q43-939r-3o94-7s04-06s8669nsq1s@serrofq.bet> <Z90poZ960b6jCXqn@cell.glebi.us> <Z90ymKjH18bkj-nc@framework> <Z902glkq79hlB0N4@cell.glebi.us> <Z91vvp9uG8Fv3_bt@framework>
index | next in thread | previous in thread | raw e-mail
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 Smirnoffhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Z92jdusq_7ri4_wK>