From: Kees Cook <keescook@chromium.org>
To: Marco Elver <elver@google.com>
Cc: linux-hardening@vger.kernel.org,
Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
Mark Rutland <mark.rutland@arm.com>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] overflow: Introduce add_wrap(), sub_wrap(), and mul_wrap()
Date: Tue, 6 Feb 2024 02:05:42 -0800 [thread overview]
Message-ID: <202402060204.A19FFF8FD5@keescook> (raw)
In-Reply-To: <CANpmjNNExn8DX2+Cnz3GDWXNZv-jZcpFSedCYx+y6HEemFoHRw@mail.gmail.com>
On Mon, Feb 05, 2024 at 02:31:04PM +0100, Marco Elver wrote:
> On Mon, 5 Feb 2024 at 10:12, Kees Cook <keescook@chromium.org> wrote:
> >
> > Provide helpers that will perform wrapping addition, subtraction, or
> > multiplication without tripping the arithmetic wrap-around sanitizers. The
> > first argument is the type under which the wrap-around should happen
> > with. In other words, these two calls will get very different results:
> >
> > mul_wrap(int, 50, 50) == 2500
> > mul_wrap(u8, 50, 50) == 196
> >
> > Add to the selftests to validate behavior and lack of side-effects.
> >
> > Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: linux-hardening@vger.kernel.org
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
> > include/linux/overflow.h | 54 ++++++++++++++++++++++++++++++++++++++++
> > lib/overflow_kunit.c | 23 ++++++++++++++---
> > 2 files changed, 73 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/linux/overflow.h b/include/linux/overflow.h
> > index 4e741ebb8005..9b8c05bdb788 100644
> > --- a/include/linux/overflow.h
> > +++ b/include/linux/overflow.h
> > @@ -64,6 +64,24 @@ static inline bool __must_check __must_check_overflow(bool overflow)
> > #define check_add_overflow(a, b, d) \
> > __must_check_overflow(__builtin_add_overflow(a, b, d))
> >
> > +/**
> > + * add_wrap() - Intentionally perform a wrapping addition
> > + * @type: type for result of calculation
> > + * @a: first addend
> > + * @b: second addend
> > + *
> > + * Return the potentially wrapped-around addition without
> > + * tripping any wrap-around sanitizers that may be enabled.
> > + */
> > +#define add_wrap(type, a, b) \
> > + ({ \
> > + type __val; \
> > + if (check_add_overflow(a, b, &__val)) { \
> > + /* do nothing */ \
>
> The whole reason check_*_overflow() exists is to wrap the builtin in a
> function with __must_check. Here the result is explicitly ignored, so
> do we have to go through the check_add_overflow indirection? Why not
> just use the builtin directly? It might make sense to make the
Yes, this follows now. This is a leftover from extending the helpers to
work with pointers, which I don't have any current use for now. I'll fix
this.
> compiler's job a little easier, because I predict that
> __must_check_overflow will be outlined with enough instrumentation
> (maybe it should have been __always_inline).
I could change that separately, yeah.
--
Kees Cook
next prev parent reply other threads:[~2024-02-06 10:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-05 9:12 [PATCH v3 0/3] overflow: Introduce wrapping helpers Kees Cook
2024-02-05 9:12 ` [PATCH v3 1/3] overflow: Adjust check_*_overflow() kern-doc to reflect results Kees Cook
2024-02-05 20:00 ` Gustavo A. R. Silva
2024-02-05 9:12 ` [PATCH v3 2/3] overflow: Introduce add_wrap(), sub_wrap(), and mul_wrap() Kees Cook
2024-02-05 13:31 ` Marco Elver
2024-02-05 19:53 ` Gustavo A. R. Silva
2024-02-06 10:05 ` Kees Cook [this message]
2024-02-05 20:21 ` Eric Biggers
2024-02-05 22:44 ` Kees Cook
2024-02-05 23:17 ` Eric Biggers
2024-02-05 23:21 ` Kees Cook
2024-02-06 8:42 ` Rasmus Villemoes
2024-02-06 10:01 ` Kees Cook
2024-02-05 9:12 ` [PATCH v3 3/3] overflow: Introduce inc_wrap() and dec_wrap() Kees Cook
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=202402060204.A19FFF8FD5@keescook \
--to=keescook@chromium.org \
--cc=elver@google.com \
--cc=gustavoars@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=rasmus.villemoes@prevas.dk \
/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.