All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: "Gustavo A . R . Silva" <gustavoars@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Leon Romanovsky <leon@kernel.org>,
	Keith Busch <kbusch@kernel.org>, Len Baker <len.baker@gmx.com>,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH 1/2] overflow: Implement size_t saturating arithmetic helpers
Date: Tue, 21 Sep 2021 12:07:35 -0700	[thread overview]
Message-ID: <202109211204.75043CDF@keescook> (raw)
In-Reply-To: <aa42ebfa-03b8-93fa-e036-a7507397d0dc@rasmusvillemoes.dk>

On Tue, Sep 21, 2021 at 08:51:53AM +0200, Rasmus Villemoes wrote:
> On 20/09/2021 20.08, Kees Cook wrote:
> 
> > + * Internal logic for size_mul(). Takes variable names from UNIQUE_ID
> > + * so that the local variables here will never collide with other local
> > + * variables (for example, with itself).
> > + */
> > +#define __size_mul(factor1, factor2, __factor1, __factor2, __product)	\
> > +({									\
> > +	size_t __product;						\
> > +	size_t __factor1 = (factor1);					\
> > +	size_t __factor2 = (factor2);					\
> > +	if (check_mul_overflow(__factor1, __factor2, &__product))	\
> > +		__product = SIZE_MAX;					\
> > +	__product;							\
> > +})
> > +
> 
> Why can't this just be a static inline taking and returning size_ts,
> avoiding all the unique_id ritual and triple layers of macros?

*hold face* Yeah. I've been doing so much type-agnostic macro work
lately that I completely looked past the characteristics I was
describing for this macro are ... in fact ... how functions actually
work. *sigh* Yes, I'll change all of these to just be static inlines.
If we ever need them as constant expressions, we can fix them then.

> Not that I can see that the __must_check matters much for these anyway;
> if anybody does
> 
>   size_mul(foo, bar);
> 
> that's just a statement with no side effects, so probably the compiler
> would warn anyway, or at least nobody can then go on to do anything
> "wrong". Unlike the check_*_overflow(), which have the (possibly
> wrapped) result in a output-pointer and the "did it overflow" as the
> return value, so you can do
> 
>   check_mul_overflow(a, b, &d);
>   do_stuff_with(d);
> 
> were it not for the __must_check wrapper.
> 
> [Reminder: __must_check is a bit of a misnomer, the attribute is really
> warn_unused_result, and there's no requirement that the result is part
> of the controlling expression of an if() or while() - just passing the
> result on directly to some other function counts as a "use", which is
> indeed what we do with the size wrappers.]

Yeah, all a good point. My knee-jerk reaction is to include __must_check
just because it's "free" here.

Thanks!

-Kees

-- 
Kees Cook

  reply	other threads:[~2021-09-21 19:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20 18:08 [PATCH 0/2] overflow: Implement size_t saturating arithmetic helpers Kees Cook
2021-09-20 18:08 ` [PATCH 1/2] " Kees Cook
2021-09-20 22:06   ` Nick Desaulniers
2021-09-21  1:38     ` Kees Cook
2021-09-21  6:51   ` Rasmus Villemoes
2021-09-21 19:07     ` Kees Cook [this message]
2022-01-24 21:13     ` Kees Cook
2022-01-24 21:16       ` Nick Desaulniers
2022-01-25 12:58       ` Jason Gunthorpe
2021-09-20 18:08 ` [PATCH 2/2] test_overflow: Regularize test reporting output Kees Cook
2021-09-20 22:10   ` Nick Desaulniers
2021-09-21  6:56     ` Rasmus Villemoes

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=202109211204.75043CDF@keescook \
    --to=keescook@chromium.org \
    --cc=gustavoars@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=kbusch@kernel.org \
    --cc=len.baker@gmx.com \
    --cc=leon@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.