Date: Fri, 21 Mar 2025 17:57:38 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@freebsd.org> To: Mark Johnston <markj@freebsd.org> Cc: Gleb Smirnoff <glebius@freebsd.org>, David Wolfskill <david@catwhisker.org>, current@freebsd.org, Konstantin Belousov <kib@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: Possible video driver issue after main-n275966-d2a55e6a9348 -> main-n275975-5963423232e8 Message-ID: <7spnrss9-93o9-onr2-sorq-8r5qnn22oor9@serrofq.bet> In-Reply-To: <Z91vvp9uG8Fv3_bt@framework> References: <Z9WJsC4FcyHQkME-@albert.catwhisker.org> <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, 21 Mar 2025, Mark Johnston wrote: > On Fri, Mar 21, 2025 at 02:50:58AM -0700, Gleb Smirnoff wrote: >> On Fri, Mar 21, 2025 at 05:34:16AM -0400, Mark Johnston wrote: >> M> On Fri, Mar 21, 2025 at 01:56:01AM -0700, Gleb Smirnoff wrote: >> M> > On Thu, Mar 20, 2025 at 07:52:19PM +0000, Bjoern A. Zeeb wrote: >> M> > B> He's hitting a ... somewhere in i915kms.ko (here's the two instances I >> M> > B> have): >> M> > B> REDZONE: Buffer underflow detected. 16 bytes corrupted before 0xfffffe089bc65000 (262148 bytes allocated). >> M> > B> REDZONE: Buffer underflow detected. 16 bytes corrupted before 0xfffffe08a7e70000 (262148 bytes allocated). >> M> > >> M> > I looked a bit into the problem and it actually seems very trivial to me. >> M> > Please re-check my observations. >> M> > >> M> > A contigmalloc(9) allocation doesn't get redzone protection, see kern_malloc.c. >> M> > But free(9) always does contigmalloc check. This makes deprecation of >> M> > contigfree(9) incompatible with redzone(9). And looks like >> M> > 19df0c5abcb9d4e951e610b6de98d4d8a00bd5f9 is our first bump into this sad fact. >> M> >> M> Can we not just add redzone padding to contigmalloc() allocations? >> >> I was about to suggest that, but was afraid it is too naive :) But >> if that works, why not? We probably should document that for >> contigmalloc() the redzone would provide protection of the virtual >> space, but not the physical. > > I'm not sure what you mean by this? As implemented, the patch > effectively rounds up the allocation size, so the redzone will also be > physically contiguous. Though, I see now that this will result in an > non-page-aligned allocation, which callers of contigmalloc() might > not tolerate... > > Actually, for malloc_large() and contigmalloc() allocations it's > probably a bit easier to just provide guard pages around the > allocation, like we do for kernel stacks. That is, if the caller asks > for N pages, then allocate N+2 pages of virtual address space and back > pages [1, N] with physical memory. Then any overflow will trap at the > site of the overflow, which is probably more useful than what > redzone(9). Actually, KASAN provides the same checking, but currently > we don't pad allocations when KASAN is enabled. I like the idea given contigmalloc will always round up to PAGE_SIZE anyway. Problem with contigmalloc is that you have to meet the alignment requirement, etc. on [1,N] then. Does that make it more tricky? /bz -- Bjoern A. Zeeb r15:7home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7spnrss9-93o9-onr2-sorq-8r5qnn22oor9>