From: Kees Cook <keescook@chromium.org>
To: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
xfs <linux-xfs@vger.kernel.org>, Zorro Lang <zlang@redhat.com>,
linux-hardening@vger.kernel.org
Subject: Re: [RFC PATCH] xfs: fix FORTIFY_SOURCE complaints about log item memcpy
Date: Tue, 25 Oct 2022 11:45:19 -0700 [thread overview]
Message-ID: <202210251140.A25428CB6@keescook> (raw)
In-Reply-To: <20221024223235.GA3600936@dread.disaster.area>
On Tue, Oct 25, 2022 at 09:32:35AM +1100, Dave Chinner wrote:
> On Mon, Oct 24, 2022 at 09:59:08AM -0700, Kees Cook wrote:
> > On Wed, Oct 19, 2022 at 05:04:11PM -0700, Darrick J. Wong wrote:
> > > [...]
> > > -/*
> > > - * Copy an BUI format buffer from the given buf, and into the destination
> > > - * BUI format structure. The BUI/BUD items were designed not to need any
> > > - * special alignment handling.
> > > - */
> > > -static int
> > > -xfs_bui_copy_format(
> > > - struct xfs_log_iovec *buf,
> > > - struct xfs_bui_log_format *dst_bui_fmt)
> > > -{
> > > - struct xfs_bui_log_format *src_bui_fmt;
> > > - uint len;
> > > -
> > > - src_bui_fmt = buf->i_addr;
> > > - len = xfs_bui_log_format_sizeof(src_bui_fmt->bui_nextents);
> > > -
> > > - if (buf->i_len == len) {
> > > - memcpy(dst_bui_fmt, src_bui_fmt, len);
> > > - return 0;
> > > - }
> > > - XFS_ERROR_REPORT(__func__, XFS_ERRLEVEL_LOW, NULL);
> > > - return -EFSCORRUPTED;
> > > -}
> >
> > This is the place where flex_cpy() could be used:
> >
> > flex_cpy(dst_bui_fmt, src_bui_fmt);
>
> How does flex_cpy() know how much memory was allocated for
> dst_bui_fmt? Doesn't knowing this imply that we have to set the
> count field in dst_bui_fmt appropriately before flex_cpy() is
> called?
Right -- this is why I had originally sent my API proposal with the *_dup
helpers included as well. The much more common case is allocate/copy
and allocate/deserialize. The case of doing flex-to-flex is odd, because
it implies there was an external allocation step, etc. But, that said,
allocation and bounds recording are usually pretty well tied together.
> Hence I don't see that this flex array copying stuff will make it
> harder to make mistakes, but ISTM that it'll make them harder to spot
> during review and audit...
I think the transition to a fallible routine is an improvement, but
yes, I expect flex_cpy() not to be used much compared to flex_dup(),
or mem_to_flex_dup(), both of which collapse a great many steps and
sanity checks into a single common, internally-consistent, and fallible
operation.
--
Kees Cook
prev parent reply other threads:[~2022-10-25 18:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-20 0:04 [RFC PATCH] xfs: fix FORTIFY_SOURCE complaints about log item memcpy Darrick J. Wong
2022-10-20 3:05 ` Kees Cook
2022-10-24 16:59 ` Kees Cook
2022-10-24 21:38 ` Darrick J. Wong
2022-10-25 18:40 ` Kees Cook
2022-10-24 22:32 ` Dave Chinner
2022-10-25 18:45 ` Kees Cook [this message]
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=202210251140.A25428CB6@keescook \
--to=keescook@chromium.org \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=zlang@redhat.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.