From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8EC3F1EBFFF for ; Fri, 26 Sep 2025 03:37:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758857870; cv=none; b=m/AkNnYNqcrfSumwGvCpLeNZo3k9sMtjFNK953zgue5xJEKo8Z5FWMIUlq+k3HJVr5bftPL8a4BKIgQVT+lcL0vpW/6M2/MiykCGte/Y4dY0TFIon2wB99YdSmZ2xziD3lfwBCMAGYuzZGZNEvdqcMUri/Fp0CxPaNDkB8NDizM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758857870; c=relaxed/simple; bh=Z8ymzU8QK2Rz1EhzcD996ZhA/fhIRvQiH7h5v9ptZYA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cAjTeo6JdT2ni16+KWkv6tS2vqd8DdtihcxfamStXDD544lEKLtGEfdT+cHmfmrhCLQheW89U3SqK+JqxPpfj9v7thqHVQTmgQSMp0cWzz/R9AfFnmRKXOG0oW49HOijlFMesAZDUEZlw6kMJhCyVy4oVyn41MDjDAh/Um2PpPc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NCwLjwOC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NCwLjwOC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05CC7C4CEF0; Fri, 26 Sep 2025 03:37:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1758857870; bh=Z8ymzU8QK2Rz1EhzcD996ZhA/fhIRvQiH7h5v9ptZYA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NCwLjwOCVeh6BUxuvTk6f03h9vvDiJxi9sWYZIdOV1KuBn5qTCvO0TsnXm0ctD9Gx 0x2gxqbU2GJtRN4babQFKjKo0KfKN9+QsW2SClYX/6WkBkjhT8befTRIiY3H4Ea75L N5CYsYqdYd+Zd+i73vv2rLDTRwNOsLCDCKc0XsouHDNV76sSd7c3d14s4dpgPn6S8P v5GAhhwAEaNef2SNhPM7dov7BKPSe78f5yK4S3Xs54ZK52tH44ixpO6z1Zyh1Lbllf IYEph7qy1CLk3KdPTYH3ItlhgCOpF/qqodxokwyFgg2ZjLs3JBMo+Lh5b9YcCCn37S /LtnOZ7i3Wyrw== Date: Thu, 25 Sep 2025 20:37:49 -0700 From: Kees Cook To: Linus Torvalds Cc: Andrew Morton , Alejandro Colomar , Linux Kernel Mailing List , Christopher Bazley , Rasmus Villemoes , Marco Elver , Michal Hocko , Al Viro , Alexander Potapenko , Dmitry Vyukov , Jann Horn Subject: Re: [PATCH v1 0/3] Add ENDOF(), and use it to fix off-by-one bugs Message-ID: <202509252007.E9D3C14@keescook> References: <20250925134814.1f68d84a951572245893abbe@linux-foundation.org> <202509251657.F4ED4CF@keescook> <202509251823.1B974C7@keescook> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Sep 25, 2025 at 07:36:13PM -0700, Linus Torvalds wrote: > The thing is, the "start+len" model is actually *safer* than the > "start+len-1" model. Sure. But start + len is a vector: "start" is a pointer, and "len" is a size. No problems at all. > Obviously you cannot dereference a zero-sized object, but zero-sized > objects aren't "wrong" per se. Right, totally agreed. I'm a big fan of zero-sized objects which are useful in all kinds of situations (e.g. empty flexible arrays). And as you're saying, a zero-sized object shares the same representation: start + len where len is 0. What I dislike is having this vector collapsed into a pointer because it loses its explicit start/len information, and becomes ambiguous. And worse we have nothing that says "this pointer isn't safe to dereference". All the bounds safety work we've been doing lately is mostly centered around finding ways to retain the "len" part of dynamically sized object pointers so we can reconstruct the vector unambiguously. Anyway, yay for vectors. :) -Kees -- Kees Cook