From: Andrew Morton <akpm@linux-foundation.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
adobriyan@gmail.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH -v2] memdup_user(): introduce
Date: Sat, 7 Mar 2009 10:27:35 -0800 [thread overview]
Message-ID: <20090307102735.80f498b1.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090307084805.7cf3d574@infradead.org>
On Sat, 7 Mar 2009 08:48:05 -0800 Arjan van de Ven <arjan@infradead.org> wrote:
> On Fri, 6 Mar 2009 15:03:35 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > >
> > > /**
> > > + * memdup_user - duplicate memory region from user space
> > > + *
> > > + * @src: source address in user space
> > > + * @len: number of bytes to copy
> > > + * @gfp: GFP mask to use
> > > + *
> > > + * Returns an ERR_PTR() on failure.
> > > + */
> > > +void *memdup_user(const void __user *src, size_t len, gfp_t gfp)
> > > +{
> > > + void *p;
> > > +
> > > + p = kmalloc_track_caller(len, gfp);
> > > + if (!p)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + if (copy_from_user(p, src, len)) {
> > > + kfree(p);
> > > + return ERR_PTR(-EFAULT);
> > > + }
> > > +
> > > + return p;
> > > +}
> > > +EXPORT_SYMBOL(memdup_user);
>
> Hi,
>
> I like the general idea of this a lot; it will make things much less
> error prone (and we can add some sanity checks on "len" to catch the
> standard security holes around copy_from_user usage). I'd even also
> want a memdup_array() like thing in the style of calloc().
>
> However, I have two questions/suggestions for improvement:
>
> I would like to question the use of the gfp argument here;
> copy_from_user sleeps, so you can't use GFP_ATOMIC anyway.
> You can't use GFP_NOFS etc, because the pagefault path will happily do
> things that are equivalent, if not identical, to GFP_KERNEL.
>
> So the only value you can pass in correctly, as far as I can see, is
> GFP_KERNEL. Am I wrong?
True.
> A second thing.. I'd like to have this function return NULL on failure;
> error checking a pointer for NULL is so much easier than testing for
> anything else; the only distinction is -ENOMEM versus -EFAULT, and I'm
> not sure that that is worth the complexity on all callers.
This errno will be returned to userspace. If the caller guesses wrong,
that's a kernel bug, of the regression variety.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
adobriyan@gmail.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH -v2] memdup_user(): introduce
Date: Sat, 7 Mar 2009 10:27:35 -0800 [thread overview]
Message-ID: <20090307102735.80f498b1.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090307084805.7cf3d574@infradead.org>
On Sat, 7 Mar 2009 08:48:05 -0800 Arjan van de Ven <arjan@infradead.org> wrote:
> On Fri, 6 Mar 2009 15:03:35 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > >
> > > /**
> > > + * memdup_user - duplicate memory region from user space
> > > + *
> > > + * @src: source address in user space
> > > + * @len: number of bytes to copy
> > > + * @gfp: GFP mask to use
> > > + *
> > > + * Returns an ERR_PTR() on failure.
> > > + */
> > > +void *memdup_user(const void __user *src, size_t len, gfp_t gfp)
> > > +{
> > > + void *p;
> > > +
> > > + p = kmalloc_track_caller(len, gfp);
> > > + if (!p)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + if (copy_from_user(p, src, len)) {
> > > + kfree(p);
> > > + return ERR_PTR(-EFAULT);
> > > + }
> > > +
> > > + return p;
> > > +}
> > > +EXPORT_SYMBOL(memdup_user);
>
> Hi,
>
> I like the general idea of this a lot; it will make things much less
> error prone (and we can add some sanity checks on "len" to catch the
> standard security holes around copy_from_user usage). I'd even also
> want a memdup_array() like thing in the style of calloc().
>
> However, I have two questions/suggestions for improvement:
>
> I would like to question the use of the gfp argument here;
> copy_from_user sleeps, so you can't use GFP_ATOMIC anyway.
> You can't use GFP_NOFS etc, because the pagefault path will happily do
> things that are equivalent, if not identical, to GFP_KERNEL.
>
> So the only value you can pass in correctly, as far as I can see, is
> GFP_KERNEL. Am I wrong?
True.
> A second thing.. I'd like to have this function return NULL on failure;
> error checking a pointer for NULL is so much easier than testing for
> anything else; the only distinction is -ENOMEM versus -EFAULT, and I'm
> not sure that that is worth the complexity on all callers.
This errno will be returned to userspace. If the caller guesses wrong,
that's a kernel bug, of the regression variety.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-03-07 18:28 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-06 7:04 [RFC][PATCH] kmemdup_from_user(): introduce Li Zefan
2009-03-06 7:04 ` Li Zefan
2009-03-06 7:23 ` Américo Wang
2009-03-06 7:23 ` Américo Wang
2009-03-06 7:37 ` KOSAKI Motohiro
2009-03-06 7:37 ` KOSAKI Motohiro
2009-03-06 8:03 ` KOSAKI Motohiro
2009-03-06 8:03 ` KOSAKI Motohiro
2009-03-06 7:39 ` Li Zefan
2009-03-06 7:39 ` Li Zefan
2009-03-06 8:20 ` Alexey Dobriyan
2009-03-06 8:20 ` Alexey Dobriyan
2009-03-06 8:27 ` Li Zefan
2009-03-06 8:27 ` Li Zefan
2009-03-06 8:39 ` Andrew Morton
2009-03-06 8:39 ` Andrew Morton
2009-03-06 8:57 ` Alexey Dobriyan
2009-03-06 8:57 ` Alexey Dobriyan
2009-03-06 9:09 ` KOSAKI Motohiro
2009-03-06 9:09 ` KOSAKI Motohiro
2009-03-06 9:01 ` Li Zefan
2009-03-06 9:01 ` Li Zefan
2009-03-06 9:15 ` Andrew Morton
2009-03-06 9:15 ` Andrew Morton
2009-03-06 9:49 ` [PATCH -v2] memdup_user(): introduce Li Zefan
2009-03-06 9:49 ` Li Zefan
2009-03-06 23:03 ` Andrew Morton
2009-03-06 23:03 ` Andrew Morton
2009-03-07 16:48 ` Arjan van de Ven
2009-03-07 16:48 ` Arjan van de Ven
2009-03-07 16:54 ` Roland Dreier
2009-03-07 16:54 ` Roland Dreier
2009-03-07 18:27 ` Andrew Morton [this message]
2009-03-07 18:27 ` Andrew Morton
2009-03-09 2:22 ` Li Zefan
2009-03-09 2:22 ` Li Zefan
2009-03-09 3:00 ` Andrew Morton
2009-03-09 3:00 ` Andrew Morton
2009-03-09 3:30 ` Li Zefan
2009-03-09 3:30 ` Li Zefan
2009-03-09 3:45 ` Andrew Morton
2009-03-09 3:45 ` Andrew Morton
2009-03-06 9:03 ` [RFC][PATCH] kmemdup_from_user(): introduce Alexey Dobriyan
2009-03-06 9:03 ` Alexey Dobriyan
2009-03-06 9:02 ` Li Zefan
2009-03-06 9:02 ` Li Zefan
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=20090307102735.80f498b1.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=adobriyan@gmail.com \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizf@cn.fujitsu.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.