From: Kees Cook <keescook@chromium.org>
To: Yury Norov <yury.norov@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] find: Do not read beyond variable boundaries on small sizes
Date: Fri, 3 Dec 2021 14:43:21 -0800 [thread overview]
Message-ID: <202112031441.200FE4975@keescook> (raw)
In-Reply-To: <20211203191611.GB450223@lapt>
On Fri, Dec 03, 2021 at 11:16:11AM -0800, Yury Norov wrote:
> On Fri, Dec 03, 2021 at 08:37:59AM -0800, Kees Cook wrote:
> >
> >
> > On December 3, 2021 4:30:35 AM PST, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > >On Fri, Dec 03, 2021 at 02:08:46AM -0800, Kees Cook wrote:
> > >> It's common practice to cast small variable arguments to the find_*_bit()
> > >
> > >It's a bad practice and should be fixed accordingly, no?
> >
> > There's an argument to be made that the first arg should be void * but that's a pretty invasive change at this point (and orthogonal to this fix).
>
> What for? To save at most 7 bytes of alignment overhead for bitmaps
> like char bitmap[sizeof(unsigned long) + 1]?
I just meant to simplify the calling conventions. Right now everyone has
to cast to unsigned long *, which doesn't seem right: alignment and
strides can be done in the routine. But, I have no strong opinion about
this; it's just something I noticed while looking at it.
--
Kees Cook
next prev parent reply other threads:[~2021-12-03 22:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-03 10:08 [PATCH] find: Do not read beyond variable boundaries on small sizes Kees Cook
2021-12-03 12:30 ` Andy Shevchenko
2021-12-03 16:37 ` Kees Cook
2021-12-03 19:16 ` Yury Norov
2021-12-03 22:43 ` Kees Cook [this message]
2021-12-03 18:26 ` Yury Norov
2021-12-03 20:48 ` Steven Rostedt
2021-12-03 23:01 ` Kees Cook
2021-12-07 23:39 ` Yury Norov
2021-12-08 5:25 ` Yury Norov
2021-12-08 10:22 ` Andy Shevchenko
2021-12-08 13:07 ` David Laight
2021-12-08 19:19 ` Kees Cook
2021-12-08 19:34 ` Kees Cook
2021-12-08 23:23 ` 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=202112031441.200FE4975@keescook \
--to=keescook@chromium.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=wsa+renesas@sang-engineering.com \
--cc=yury.norov@gmail.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.