From nobody Fri Mar 21 17:57:38 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZK9CB1yZVz5rVDW for ; Fri, 21 Mar 2025 17:57:42 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZK9CB09Nkz3R8m; Fri, 21 Mar 2025 17:57:42 +0000 (UTC) (envelope-from bz@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742579862; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5H3mCZE6aocvh7kKH4jXpc2GtI0Pd50rVv0k8rKRAX0=; b=iJ6eyYk/5HsP+/b4Ep9FCAc2IPIW+OYzfWsR8D7VmeDfBOetZq86QUKk0a8dqOAl6GKk8M NY8gkz2dsQtJ6+YnKvDDnxrL8sozTb/nSkTtwNLOy3wROIU8w+IwRnzj0H2XH8YG0wsjLr dykSi2FGiqOgIqnUmh7lGYFa0eXuDVy2TsiaKqEA2a9IpaqYXCV7481T+AWCVmSwXw3yn7 4hLJA1Lt1HVO94bHugJEew1+wY9IHTIyn8QlVCSLtNI3YVj6aEvZU/vUUG5DSmxj+Ge5nC Uf6/BAkNdl2Oepa20UUTvhznCSDRcl91kfasZADzK9q9rnwWPaR0ItcrXI5gjA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742579862; a=rsa-sha256; cv=none; b=goAYKiiQyZnOzcq3Rk9EiVeL+mFUWQWWSNCRGyy5RtXriVur3/JYocfCpyVGWvIFu+2Gpf RlNfiWe9R0C9MeCl7h6jzzX4atpN/GKP17fbf9i75LVrbKxZNLDHdeRxMxH88TgmuFwyYE /uDaUXJPrv++Iad/Hv2/OfDboNSVveWRwHEvjTwfXWiSqr0+Icvqvos2yvjfZUQtOyu46O D7niNrd1uqmbr9kifS/gbCLbb8259xMQyJlDJiQtBNWK2LOCnmqE5mXJ3mtvZc9qUJfKjp V1tRVOJjnmyqR3Ay0xG+kGqak7ynqCp5yXYaDJyybHTS8VAeLYm31Y1tBDOJIg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742579862; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5H3mCZE6aocvh7kKH4jXpc2GtI0Pd50rVv0k8rKRAX0=; b=qi4xgwHn1ACqBG+wymJS/g6dQ06JbhHbiKh0AI4FF3DpsiZ6DXo7rMENE2N/k19GMnUmdN 6xvN+vfPt/XMHt9KSuf3zfPzar/Oa1v7hLq3ZULd1p9dpfPDFcaGTVLyblP2mukFi2r0eO fq/kCVeCYO/TBREP1I6id/AJpSfYrI2sVMG+AzngtzV5hBljtORyU39YKP/fPCaoFeX+Ch hwBcmvs1NigKToBFvRX+bblrs/svSh6pz20SQrh3jC/WOPm/gNGNv+mkDJzWn6jlV2xF7N qPPHm09ZPaMYjD8oU9uWq8OO/Qj1lV0SEe0+RusS5khGji7K2ImIgZR+ZtJqZQ== Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E5" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZK9C95tPSzv0H; Fri, 21 Mar 2025 17:57:41 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id BA12BA64805; Fri, 21 Mar 2025 17:57:37 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 148642D029E0; Fri, 21 Mar 2025 17:57:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id FT_AuMmxWiVh; Fri, 21 Mar 2025 17:57:38 +0000 (UTC) Received: from strong-rtwn1.sbone.de (strong-rtwn1.sbone.de [IPv6:fde9:577b:c1a9:4902:821f:2ff:feef:e8d5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9ADA12D029D8; Fri, 21 Mar 2025 17:57:38 +0000 (UTC) Date: Fri, 21 Mar 2025 17:57:38 +0000 (UTC) From: "Bjoern A. Zeeb" To: Mark Johnston cc: Gleb Smirnoff , David Wolfskill , current@freebsd.org, Konstantin Belousov , John Baldwin Subject: Re: Possible video driver issue after main-n275966-d2a55e6a9348 -> main-n275975-5963423232e8 In-Reply-To: Message-ID: <7spnrss9-93o9-onr2-sorq-8r5qnn22oor9@serrofq.bet> References: <01qqq28n-p1s3-n82q-9n1s-7o900ro5n62q@SerrOFQ.bet> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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:7