From nobody Fri Mar 21 13:55:10 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 4ZK3qV4Yzmz5rFyr for ; Fri, 21 Mar 2025 13:55:18 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZK3qV0Lkfz42Wk; Fri, 21 Mar 2025 13:55:18 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-225477548e1so37081545ad.0; Fri, 21 Mar 2025 06:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742565316; x=1743170116; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=sgfztvESVo/zsIHqnM27dtQcYG3dfjrnnCqzwh3/HeI=; b=UmWl+xN3wrthOb9b2BNU5DGfiG0R0b8guDGguRWxK9X6GQ7IOcOHsWIR8n5NpWl/dW ChnVMdsWfyXCsnlDXDpzKQVHtfV16wJbDOXlAIaAhKIgvPEq9sblWL6DXrQPpY16ZTGq +mgPulopsstO4aHyKw934gFGmoXPIPKI7onDD/s/AmO+Zw8nbAzYAd8jupYEP0kjrXe0 +HuciqkVkI5eGtfGhY6RE5HUSMSOQnaK/MJUDEHQDhWYoip3FpZmqhjl5nU7mKY5wdPn o7AqhoWa/P51w/8y+4LFRqmEjkU6uxInwyJ7qJDth+QLZfJpIdhPQ+PGhbdvZXxkKPcq XZdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742565316; x=1743170116; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sgfztvESVo/zsIHqnM27dtQcYG3dfjrnnCqzwh3/HeI=; b=AfTwI114DUTtDLUlLbBzUOiOrIL9MMhk0dHrhSDjgH0rroX56cE+KEUhNtMAbBOvKn QUs/QtE0epGWicsu7fiGWoQdDd34E4GSWymhjlMHmBmgRFLLLwLFFNpPiCYWzQ2UAWQP Nq7Bn3fHYkIQCxecqMg/Li7gnY1o7REHzw0h4uEfq2j3/ZKzxRy8QSAZesKmSeftDRWA IC9pOdr1IDRT4MTA/Nk+CpUM34mZGjhJa4ZzxCSk4D+DaqWytv7lFp9GJyDr3Ifh2drR kMOxjXJyCa6SaWC/1qNg++zRgHOp/+Q8YDXVmRePqXMlRA57cG7qRO2806iT9gDCyOWN WMbA== X-Forwarded-Encrypted: i=1; AJvYcCVAMqb8wvZf9VWEfA8nKMOJnsxwdD6N9iUc3FT3oYSub8HRKfeUtzJDpuNS2BreTJqwozK8@freebsd.org, AJvYcCWOY3D65M5eWY8KI+1nyUzo1kB7KZMwyxUy58mruGUItdNNNEzh03ahQCY5uKArb3H5RhIPzvDU@freebsd.org, AJvYcCXYB/gx5CyF0/UFnEET3CsD3gTq0J2605OFONqrhlgky6oInUDckYw5IX177ybrEyzSZTW5@freebsd.org X-Gm-Message-State: AOJu0YxCVFUPih9vQX3UHFiPEHbbczKM9um7B4WEgxgYU0GJfK/CT1aC /lGo9GN4K3kIGQN7RAmG5GJ50AelhF9vaFs7bzv9P3/NDsWVHquLXiLlhGJKKgM= X-Gm-Gg: ASbGnctkylwgQHnUYv7QVARy6jYOITmXjP6GM72zHZSDj+u3ZMML89SG4zOYnQ1839y bCf7Vww1XTfJOv9IRSnwqihQaL1q50eehvLrQsrX7zFBQkjFBkT0GTfq3Bbfhfdm9ClXvF0cHmR xEnWtg6O8MDbJ4KdQoYJsdOwVcRPBMQ58mRUZb2vQY0ASmdMveVmAXPksE9BbIzUNrxechyuiec h1d5/wmjZkugHErB86tMZtRGyuj+lfn4fkmefqMvDLaBdSc9BLEhvvSuRRkofJpb6tv/kukyI39 +O1l/8cmIJve4PVhA3e/oZrNjgzwfGWal+dBciByeG4YQj9j9bE1JXy9X0vbWNwKXcw= X-Google-Smtp-Source: AGHT+IEKk/2QlZlqz2hNvjkpWlgV6oJX3t8L1AtdIb2Z0WzY98929Pd8np+SxDMYPzZa0kTJI9B4iA== X-Received: by 2002:a17:902:e78f:b0:224:c46:d162 with SMTP id d9443c01a7336-22780c7bfecmr53195645ad.20.1742565316191; Fri, 21 Mar 2025 06:55:16 -0700 (PDT) Received: from framework (M106185150005.v4.enabler.ne.jp. [106.185.150.5]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-22780f56d7asm16577375ad.105.2025.03.21.06.55.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Mar 2025 06:55:15 -0700 (PDT) Date: Fri, 21 Mar 2025 09:55:10 -0400 From: Mark Johnston To: Gleb Smirnoff Cc: "Bjoern A. Zeeb" , David Wolfskill , current@freebsd.org, kib@freebsd.org, jhb@freebsd.org Subject: Re: Possible video driver issue after main-n275966-d2a55e6a9348 -> main-n275975-5963423232e8 Message-ID: References: <01qqq28n-p1s3-n82q-9n1s-7o900ro5n62q@SerrOFQ.bet> 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 Content-Disposition: inline In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4ZK3qV0Lkfz42Wk X-Spamd-Bar: ---- 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. > M> Compile-tested patch below: > > Why do you increase the size with redzone_size_ntor() before passing > it to redzone_setup()? Other calls to redzone_setup() don't do that. > My reading is that argument to redzone_setup() shall be exactly the > amount of bytes requested by the malloc KPI user. If you pass > increased value, the canaries will be written after a gap. I pass "osize", the original allocation size, to redzone_setup().