From: Kees Cook <keescook@chromium.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Jason Yan <yanaijie@huawei.com>,
kernel-hardening@lists.openwall.com,
linux-fsdevel@vger.kernel.org
Subject: Re: CONFIG_HARDENED_USERCOPY
Date: Fri, 30 Aug 2019 12:47:48 -0700 [thread overview]
Message-ID: <201908301242.EAC8111@keescook> (raw)
In-Reply-To: <20190830042958.GC7777@dread.disaster.area>
On Fri, Aug 30, 2019 at 02:29:58PM +1000, Dave Chinner wrote:
> On Thu, Aug 29, 2019 at 09:15:36AM -0700, Kees Cook wrote:
> > On Thu, Aug 29, 2019 at 08:42:30PM +0800, Jason Yan wrote:
> > > We found an issue of kernel bug related to HARDENED_USERCOPY.
> > > When copying an IO buffer to userspace, HARDENED_USERCOPY thought it is
> > > illegal to copy this buffer. Actually this is because this IO buffer was
> > > merged from two bio vectors, and the two bio vectors buffer was allocated
> > > with kmalloc() in the filesystem layer.
> >
> > Ew. I thought the FS layer was always using page_alloc?
>
> No, they don't. It's perfectly legal to use heap memory for bio
> buffers - we've been doing it since, at least, XFS got merged all
> those years ago.
Okay, so I have some observations/thoughts about this:
- This "cross allocation merging" is going to continue being a problem
in the future when we have hardware-backed allocation tagging (like
ARM's MTE). It'll be exactly the same kind of detection: a tagged
pointer crossed into a separately allocated region and access through
it will be rejected.
- I don't think using _copy_to_user() unconditionally is correct here
unless we can be absolutely sure that the size calculation really
was correct. (i.e. is the merge close enough to the copy that the
non-merge paths don't lose the validation?)
- If this has gone until now to get noticed (hardened usercopy was
introduced in v4.8), is this optimization (and, frankly, layering
violation) actually useful?
- We could just turn off allocation merging in the face of having
hardened usercopy or allocation tagging enabled...
--
Kees Cook
prev parent reply other threads:[~2019-08-30 19:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 12:42 CONFIG_HARDENED_USERCOPY Jason Yan
2019-08-29 16:15 ` CONFIG_HARDENED_USERCOPY Kees Cook
2019-08-30 4:29 ` CONFIG_HARDENED_USERCOPY Dave Chinner
2019-08-30 19:47 ` 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=201908301242.EAC8111@keescook \
--to=keescook@chromium.org \
--cc=david@fromorbit.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=yanaijie@huawei.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.