From: Kees Cook <kees@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>,
Justin Stitt <justinstitt@google.com>
Cc: Erick Archer <erick.archer@outlook.com>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
"Liang, Kan" <kan.liang@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
Matthew Wilcox <mawilcox@microsoft.com>,
x86@kernel.org, linux-perf-users@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
llvm@lists.linux.dev
Subject: Re: [PATCH v4 0/3] Hardening perf subsystem
Date: Mon, 17 Jun 2024 10:19:15 -0700 [thread overview]
Message-ID: <202406170957.3269DA2@keescook> (raw)
In-Reply-To: <20240614101708.GO8774@noisy.programming.kicks-ass.net>
On Fri, Jun 14, 2024 at 12:17:08PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 12, 2024 at 04:23:31PM -0700, Kees Cook wrote:
> > On Thu, Jun 13, 2024 at 12:08:21AM +0200, Peter Zijlstra wrote:
> > > On Wed, Jun 12, 2024 at 12:01:19PM -0700, Kees Cook wrote:
> > > > I'm happy to take patches. And for this bikeshed, this would be better
> > > > named under the size_*() helpers which are trying to keep size_t
> > > > calculations from overflowing (by saturating). i.e.:
> > > >
> > > > size_add_mult(sizeof(*p), sizeof(*p->member), num)
> > >
> > > Fine I suppose, but what if we want something not size_t? Are we waiting
> > > for the type system extension?
> >
> > Because of C's implicit promotion/truncation, we can't do anything
> > sanely with return values of arbitrary type size; we have to capture the
> > lvalue type somehow so the checking can happen without C doing silent
> > garbage.
>
> So sizeof() returns the native (built-in) size_t, right? If that type
> the nooverflow qualifier on, then:
>
> sizeof(*p) + num*sizeof(p->foo[0])
>
> should all get the nooverflow semantics right? Because size_t is
> effectively 'nooverflow unsigned long' the multiplication should promote
> 'num' to some 'long'.
Hmmm. This is an interesting point. I'll see what Justin has found as
he's been working on limiting the overflow sanitizer to specific types.
It doesn't help this (unfortunately common) code pattern, though:
int size;
size = sizeof(*p) + num*sizeof(p->foo[0]);
p = kmalloc(size, GFP_KERNEL);
But that was going to be a problem either way.
> Now, I've re-read the rules and I don't see qualifiers mentioned, so
> can't we state that the overflow/nooverflow qualifiers are to be
> preserved on (implicit) promotion and when nooverflow and overflow are
> combined the 'safe' nooverflow takes precedence?
>
> I mean, when we're adding qualifiers we can make up rules about them
> too, right?
Yup, that is the design of the "wraps" attribute (though it is the
reverse: it _allows_ for wrap-around, since we want to the default state
to be mitigation).
> If 'people' don't want to adorn the built-in size_t, we can always do
> something like:
>
> #define sizeof(x) ((nooverflow unsigned long)(sizeof(x)))
>
> and 'fix' it ourselves.
Right, though my hope is still we get the result of "nooverflow" by
marking that which was expected to overflow.
--
Kees Cook
next prev parent reply other threads:[~2024-06-17 17:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-01 16:56 [PATCH v4 0/3] Hardening perf subsystem Erick Archer
2024-06-08 8:50 ` Erick Archer
2024-06-10 10:06 ` Peter Zijlstra
2024-06-10 17:28 ` Kees Cook
2024-06-10 20:05 ` Peter Zijlstra
2024-06-10 21:46 ` Kees Cook
2024-06-11 7:55 ` Peter Zijlstra
2024-06-12 19:01 ` Kees Cook
2024-06-12 22:08 ` Peter Zijlstra
2024-06-12 23:23 ` Kees Cook
2024-06-14 10:17 ` Peter Zijlstra
2024-06-15 16:09 ` Martin Uecker
2024-06-17 17:28 ` Kees Cook
2024-06-18 8:22 ` Peter Zijlstra
2024-06-20 18:26 ` Kees Cook
2024-06-17 17:19 ` Kees Cook [this message]
2024-06-18 8:28 ` Peter Zijlstra
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=202406170957.3269DA2@keescook \
--to=kees@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=christophe.jaillet@wanadoo.fr \
--cc=dave.hansen@linux.intel.com \
--cc=erick.archer@outlook.com \
--cc=gustavoars@kernel.org \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=justinstitt@google.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=mawilcox@microsoft.com \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=namhyung@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).