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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox