linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Matthew Wilcox <willy@infradead.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 12:47:58 -0800	[thread overview]
Message-ID: <202112131246.4BBFBA69A@keescook> (raw)
In-Reply-To: <YbesvmxAI3P5UFnv@casper.infradead.org>

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).

-- 
Kees Cook


  reply	other threads:[~2021-12-13 20:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-13 14:27 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 [this message]
2021-12-13 20:53       ` William Kucharski
2021-12-13 21:16       ` Matthew Wilcox
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=202112131246.4BBFBA69A@keescook \
    --to=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tglx@linutronix.de \
    --cc=william.kucharski@oracle.com \
    --cc=willy@infradead.org \
    /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