linux-hardening.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	"Gustavo A . R . Silva" <gustavoars@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Jason Gunthorpe <jgg@ziepe.ca>, 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: Mon, 20 Sep 2021 18:38:36 -0700	[thread overview]
Message-ID: <202109201815.E4D4AEA317@keescook> (raw)
In-Reply-To: <CAKwvOdnWiBwXq2atuHXYUfGLiHPhmipJmXze-ymtKG_Vmf7w2g@mail.gmail.com>

On Mon, Sep 20, 2021 at 03:06:33PM -0700, Nick Desaulniers wrote:
> On Mon, Sep 20, 2021 at 11:09 AM Kees Cook <keescook@chromium.org> wrote:
> > [...]
> > +/*
> > + * Internal logic for size_add(). 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_add(addend1, addend2, __addend1, __addend2, __sum)      \
> > +({                                                                     \
> > +       size_t __sum;                                                   \
> > +       size_t __addend1 = (addend1);                                   \
> > +       size_t __addend2 = (addend2);                                   \
> > +       if (check_add_overflow(__addend1, __addend2, &__sum))           \
> > +               __sum = SIZE_MAX;                                       \
> > +       __sum;                                                          \
> > +})
> > +
> > +/**
> > + * size_add() - Calculate size_t addition with saturation at SIZE_MAX
> > + *
> > + * @addend1: first addend
> > + * @addend2: second addend
> > + *
> > + * Returns: calculate @addend1 + @addend2, where both values are
> > + * evaluated as size_t, with any overflow causing the return value to
> > + * be SIZE_MAX.
> > + */
> > +#define size_add(addend1, addend2)                                     \
> > +       __must_check_size(__size_add(addend1, addend2,                  \
> > +                                    __UNIQUE_ID(__addend1_),           \
> > +                                    __UNIQUE_ID(__addend2_),           \
> > +                                    __UNIQUE_ID(__sum_)))
> 
> Is the use of __UNIQUE_ID really necessary? Is the point to avoid some
> kind of variable shadowing?  (As opposed to just using names for the
> new variables in the scope of the statement expressions? ie.

Yes, when composed[1], they would shadow (under -Wshadow). I'd rather
not knowingly add yet more[2] shadowed variables to the kernel. :)

[1] https://godbolt.org/z/1rM6Ko1j3
[2] https://github.com/KSPP/linux/issues/152

> +#define __size_add(addend1, addend2, __sum)      \
> +({                                                                     \
> +       size_t __sum;                                                   \
> +       if (check_add_overflow((size_t)__addend1, (size_t)__addend2,
> &__sum))           \
> +               __sum = SIZE_MAX;                                       \
> +       __sum;                                                          \
> +})
> 
> Do the double-underscore-prefixed really need to be a separate
> #define, or can their definitions be inlined into the expansion sites;
> there seems like there's no other users of the
> double-underscore-prefixed versions otherwise. ie.
> 
> #define size_add(addend1, addend2) \
>   __must_check_size(({ \
>     size_t sum;  \
>     if (check_add_overflow((size_t)addend1, (size_t)addend2), &sum;  \
>       sum = SIZE_MAX;  \
>     sum;  \
> })

Right, there aren't, but that's the way to pass such variable names in.
(See minmax.h.) This also leaves the door open for using these helpers
as constant expressions, if the need arises.

> > +       err |= check_one_size_helper(SIZE_MAX, size_add, SIZE_MAX, -3);
> 
> Sorry, is this ^ case saying that we expect SIZE_MAX + -3 == SIZE_MAX?
> This is because the helpers performed unsigned arithmetic on size_t?

Correct. When I wrote this I hadn't yet found any cases of needing to
shrink an allocation size that followed a common pattern like this. But it
turns out we do have some:

drivers/infiniband/core/sa_query.c:     sa_dev = kzalloc(struct_size(sa_dev, port, e - s + 1), GFP_KERNEL);
drivers/infiniband/core/user_mad.c:     umad_dev = kzalloc(struct_size(umad_dev, ports, e - s + 1), GFP_KERNEL);
drivers/net/ethernet/intel/iavf/iavf_virtchnl.c:        len = struct_size(vti, list, adapter->num_tc - 1);

I'll need to add size_sub() as well.

Thanks for looking this over!

-- 
Kees Cook

  reply	other threads:[~2021-09-21  3:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20 18:08 [PATCH 0/2] " 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 [this message]
2021-09-21  6:51   ` Rasmus Villemoes
2021-09-21 19:07     ` Kees Cook
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=202109201815.E4D4AEA317@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 \
    --subject='Re: [PATCH 1/2] overflow: Implement size_t saturating arithmetic helpers' \
    /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

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).