All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Kees Cook <keescook@chromium.org>
Cc: William Kucharski <william.kucharski@oracle.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"linux-hardening@vger.kernel.org"
	<linux-hardening@vger.kernel.org>
Subject: Re: [PATCH v3 0/3] Assorted improvements to usercopy
Date: Mon, 13 Dec 2021 21:16:46 +0000	[thread overview]
Message-ID: <Ybe4PoG2qQyn8zCX@casper.infradead.org> (raw)
In-Reply-To: <202112131246.4BBFBA69A@keescook>

On Mon, Dec 13, 2021 at 12:47:58PM -0800, Kees Cook wrote:
> On Mon, Dec 13, 2021 at 08:27:42PM +0000, Matthew Wilcox wrote:
> > On Mon, Dec 13, 2021 at 07:18:57PM +0000, William Kucharski wrote:
> > > I like these, but a quick question:
> > > 
> > > Since the usercopy_abort() calls are all because the offset exceeds the page
> > > size, is there a reason why you don't specifically state that via the detail
> > > parameter rather than just supply a NULL pointer?
> > 
> > Hmm ... I'd defer to Kees on this, because I'm not familiar with
> > usercopy_abort() usage, but the only places which use the detail
> > parameter today are slab/slub, which use it to pass the name of
> > the slab.  I think the user is supposed to infer that we overran the
> > end of the page based on the offset & length values.
> 
> I agree that leaving it NULL is best here. The "detail" is really about
> adding more information about which thing it was, which for slab makes
> sense, but most other stuff there isn't really anything to quickly
> distinguish one from another (i.e. vmap is all vmap).

There _is_ a bit more information in the vmap case (not in the kmap
or compound page case).  You can see it in /proc/vmallocinfo.  We
could pass it in like this?

        if (is_vmalloc_addr(ptr)) {
                struct vm_struct *vm = find_vm_area(ptr);
+               char sym[100];
                unsigned long offset;

                if (!vm) {
..
+               if (vm->caller)
+                       snprintf(sym, sizeof(sym), "%pS", vm->caller);
                offset = ptr - vm->addr;
                if (offset + n > vm->size)
-                       usercopy_abort("vmalloc", NULL, to_user, offset, n);
+                       usercopy_abort("vmalloc", vm->caller ? sym : NULL,
+                                       to_user, offset, n);
                return;


  parent reply	other threads:[~2021-12-13 21:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-13 14:27 [PATCH v3 0/3] Assorted improvements to usercopy Matthew Wilcox (Oracle)
2021-12-13 14:27 ` [PATCH v3 1/3] mm/usercopy: Check kmap addresses properly Matthew Wilcox (Oracle)
2021-12-13 14:27 ` [PATCH v3 2/3] mm/usercopy: Detect vmalloc overruns Matthew Wilcox (Oracle)
2021-12-13 14:27 ` [PATCH v3 3/3] mm/usercopy: Detect compound page overruns Matthew Wilcox (Oracle)
2021-12-13 20:52   ` Kees Cook
2021-12-13 23:44     ` Matthew Wilcox
2021-12-13 23:50       ` Kees Cook
2021-12-13 19:18 ` [PATCH v3 0/3] Assorted improvements to usercopy William Kucharski
2021-12-13 20:27   ` Matthew Wilcox
2021-12-13 20:47     ` Kees Cook
2021-12-13 20:53       ` William Kucharski
2021-12-13 21:16       ` Matthew Wilcox [this message]
2021-12-13 23:47         ` Kees Cook

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=Ybe4PoG2qQyn8zCX@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tglx@linutronix.de \
    --cc=william.kucharski@oracle.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.