public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Alejandro Colomar <alx@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Christopher Bazley <chris.bazley.wg14@gmail.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Marco Elver <elver@google.com>, Michal Hocko <mhocko@suse.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>, Jann Horn <jannh@google.com>
Subject: Re: [PATCH v1 0/3] Add ENDOF(), and use it to fix off-by-one bugs
Date: Thu, 25 Sep 2025 20:37:49 -0700	[thread overview]
Message-ID: <202509252007.E9D3C14@keescook> (raw)
In-Reply-To: <CAHk-=witf7e1QRp29tAeHLB34HuBSO5G7q82cmd-mAPSt+0JVg@mail.gmail.com>

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

  reply	other threads:[~2025-09-26  3:37 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-25 13:20 [PATCH v1 0/3] Add ENDOF(), and use it to fix off-by-one bugs Alejandro Colomar
2025-09-25 13:20 ` [PATCH v1 1/3] array_size.h: Add ENDOF() Alejandro Colomar
2025-09-25 13:24   ` Alejandro Colomar
2025-09-25 13:20 ` [PATCH v1 2/3] mm: Fix benign off-by-one bugs Alejandro Colomar
2025-11-10 17:47   ` kernel test robot
2025-11-10 22:06     ` Alejandro Colomar
2025-11-10 18:40   ` kernel test robot
2025-11-11 10:42   ` kernel test robot
2025-09-25 13:20 ` [PATCH v1 3/3] kernel: Fix off-by-one benign bugs Alejandro Colomar
2025-09-25 20:48 ` [PATCH v1 0/3] Add ENDOF(), and use it to fix off-by-one bugs Andrew Morton
2025-09-26  0:00   ` Kees Cook
     [not found]     ` <CAHk-=wg2M+v5wFQLK3u3DuchpCbuHF8Z7_if3=foECVRXF+8vg@mail.gmail.com>
2025-09-26  1:31       ` Kees Cook
2025-09-26  2:36         ` Linus Torvalds
2025-09-26  3:37           ` Kees Cook [this message]
2025-09-26 13:07             ` Alejandro Colomar
2025-09-26  8:29           ` Alejandro Colomar
2025-09-26  9:00   ` Alejandro Colomar
2025-11-08 22:20 ` [PATCH v2 0/4] Add ARRAY_END(), " Alejandro Colomar
2025-11-08 22:20   ` [PATCH v2 1/4] array_size.h: Add ARRAY_END() Alejandro Colomar
2025-11-09 10:43     ` kernel test robot
2025-11-09 12:30       ` Alejandro Colomar
2025-11-09 13:14     ` kernel test robot
2025-11-08 22:20   ` [PATCH v2 2/4] mm: Fix benign off-by-one bugs Alejandro Colomar
2025-11-08 22:20   ` [PATCH v2 3/4] kernel: Fix off-by-one benign bugs Alejandro Colomar
2025-11-08 22:20   ` [PATCH v2 4/4] mm: Use ARRAY_END() instead of open-coding it Alejandro Colomar
2025-11-09 18:06 ` [PATCH v3 0/4] Add ARRAY_END(), and use it to fix off-by-one bugs Alejandro Colomar
2025-11-09 18:06   ` [PATCH v3 1/4] array_size.h: Add ARRAY_END() Alejandro Colomar
2025-11-09 19:05     ` Maciej W. Rozycki
2025-11-09 19:18       ` Alejandro Colomar
2025-11-09 18:06   ` [PATCH v3 2/4] mm: Fix benign off-by-one bugs Alejandro Colomar
2025-11-09 18:07   ` [PATCH v3 3/4] kernel: Fix off-by-one benign bugs Alejandro Colomar
2025-11-09 18:07   ` [PATCH v3 4/4] mm: Use ARRAY_END() instead of open-coding it Alejandro Colomar
2025-11-09 19:45 ` [PATCH v4 0/4] Add ARRAY_END(), and use it to fix off-by-one bugs Alejandro Colomar
2025-11-09 19:45 ` [PATCH v4 1/4] array_size.h: Add ARRAY_END() Alejandro Colomar
2025-11-09 19:45 ` [PATCH v4 2/4] mm: Fix benign off-by-one bugs Alejandro Colomar
2025-11-09 19:45 ` [PATCH v4 3/4] kernel: Fix off-by-one benign bugs Alejandro Colomar
2025-11-09 19:45 ` [PATCH v4 4/4] mm: Use ARRAY_END() instead of open-coding it Alejandro Colomar
2025-12-10 22:46 ` [PATCH v5 0/4] Add ARRAY_END(), and use it to fix off-by-one bugs Alejandro Colomar
2025-12-10 22:46   ` [PATCH v5 1/4] array_size.h: Add ARRAY_END() Alejandro Colomar
2025-12-10 22:46   ` [PATCH v5 2/4] mm: Fix benign off-by-one bugs Alejandro Colomar
2025-12-10 22:46   ` [PATCH v5 3/4] kernel: Fix off-by-one benign bugs Alejandro Colomar
2025-12-10 22:46   ` [PATCH v5 4/4] mm: Use ARRAY_END() instead of open-coding it Alejandro Colomar
2025-12-10 23:18     ` Kees Cook
2025-12-11  0:21       ` Alejandro Colomar
2025-12-11  1:37         ` Kees Cook
2025-12-21 14:07           ` Alejandro Colomar
2025-12-22 23:21             ` Kees Cook
2025-12-23  1:07               ` Alejandro Colomar
2025-12-11 10:43 ` [PATCH v6 0/4] Add ARRAY_END(), and use it to fix off-by-one bugs Alejandro Colomar
2025-12-11 10:43   ` [PATCH v6 1/4] array_size.h: Add ARRAY_END() Alejandro Colomar
2025-12-11 10:43   ` [PATCH v6 2/4] mm: Fix benign off-by-one bugs Alejandro Colomar
2025-12-11 10:44   ` [PATCH v6 3/4] kernel: Fix off-by-one benign bugs Alejandro Colomar
2025-12-11 10:44   ` [PATCH v6 4/4] mm: Use ARRAY_END() instead of open-coding it Alejandro Colomar
2026-02-08 20:10     ` SeongJae Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202509252007.E9D3C14@keescook \
    --to=kees@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alx@kernel.org \
    --cc=chris.bazley.wg14@gmail.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mhocko@suse.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox