From: Peter Zijlstra <peterz@infradead.org>
To: Kees Cook <keescook@chromium.org>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
boris.ostrovsky@oracle.com, jgross@suse.com,
sstabellini@kernel.org, x86@kernel.org,
jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
rodrigo.vivi@intel.com, chris@chris-wilson.co.uk,
intel-gfx@lists.freedesktop.org, linux-mm@kvack.org, hch@lst.de
Subject: Re: [PATCH 4/7] mm: Introduce verify_page_range()
Date: Tue, 13 Apr 2021 09:36:32 +0200 [thread overview]
Message-ID: <YHVKACnVLAhbnt4j@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <202104121302.57D7EF8@keescook>
On Mon, Apr 12, 2021 at 01:05:09PM -0700, Kees Cook wrote:
> On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> > +struct vpr_data {
> > + int (*fn)(pte_t pte, unsigned long addr, void *data);
> > + void *data;
> > +};
>
> Eeerg. This is likely to become an attack target itself. Stored function
> pointer with stored (3rd) argument.
>
> This doesn't seem needed: only DRM uses it, and that's for error
> reporting. I'd rather plumb back errors in a way to not have to add
> another place in the kernel where we do func+arg stored calling.
Is this any better? It does have the stored pointer, but not a stored
argument, assuming you don't count returns as arguments I suppose.
The alternative is refactoring apply_to_page_range() :-/
---
struct vpr_data {
bool (*fn)(pte_t pte, unsigned long addr);
unsigned long addr;
};
static int vpr_fn(pte_t *pte, unsigned long addr, void *data)
{
struct vpr_data *vpr = data;
if (!vpr->fn(*pte, addr)) {
vpr->addr = addr;
return -EINVAL;
}
return 0;
}
/**
* verify_page_range() - Scan (and fill) a range of virtual memory and validate PTEs
* @mm: mm identifying the virtual memory map
* @addr: starting virtual address of the range
* @size: size of the range
* @fn: function that verifies the PTEs
*
* Scan a region of virtual memory, filling in page tables as necessary and
* calling a provided function on each leaf, providing a copy of the
* page-table-entry.
*
* Similar apply_to_page_range(), but does not provide direct access to the
* page-tables.
*
* NOTE! this function does not work correctly vs large pages.
*
* Return: the address that failed verification or 0 on success.
*/
unsigned long verify_page_range(struct mm_struct *mm,
unsigned long addr, unsigned long size,
bool (*fn)(pte_t pte, unsigned long addr))
{
struct vpr_data vpr = {
.fn = fn,
.addr = 0,
};
apply_to_page_range(mm, addr, size, vpr_fn, &vpr);
return vpr.addr;
}
EXPORT_SYMBOL_GPL(verify_page_range);
next prev parent reply other threads:[~2021-04-13 7:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-12 8:00 [PATCH 0/7] mm: Unexport apply_to_page_range() Peter Zijlstra
2021-04-12 8:00 ` [PATCH 1/7] mm: Unexport apply_to_existing_page_range() Peter Zijlstra
2021-04-12 8:13 ` Christoph Hellwig
2021-04-12 8:00 ` [PATCH 2/7] xen/gntdev,x86: Remove apply_to_page_range() use from module Peter Zijlstra
2021-04-12 8:26 ` Christoph Hellwig
2021-04-12 9:20 ` Peter Zijlstra
2021-04-12 9:26 ` Juergen Gross
2021-04-12 8:00 ` [PATCH 3/7] xen/gntdev: " Peter Zijlstra
2021-04-12 8:27 ` Christoph Hellwig
2021-04-12 9:02 ` Peter Zijlstra
2021-04-12 8:00 ` [PATCH 4/7] mm: Introduce verify_page_range() Peter Zijlstra
2021-04-12 8:28 ` Christoph Hellwig
2021-04-12 9:17 ` Peter Zijlstra
2021-04-12 20:05 ` Kees Cook
2021-04-13 6:54 ` Peter Zijlstra
2021-04-19 23:36 ` Kees Cook
2021-04-13 7:36 ` Peter Zijlstra [this message]
2021-04-14 3:01 ` Kees Cook
2021-04-14 7:00 ` Peter Zijlstra
2021-04-12 8:00 ` [PATCH 5/7] xen/privcmd: Use verify_page_range() Peter Zijlstra
2021-04-12 8:28 ` Christoph Hellwig
2021-04-12 8:00 ` [PATCH 6/7] i915: Convert to verify_page_range() Peter Zijlstra
2021-04-12 8:28 ` Christoph Hellwig
2021-04-12 20:08 ` Kees Cook
2021-04-13 6:54 ` Peter Zijlstra
2021-04-14 3:04 ` Kees Cook
2021-04-12 8:00 ` [PATCH 7/7] mm: Unexport apply_to_page_range() Peter Zijlstra
2021-04-12 8:28 ` Christoph Hellwig
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=YHVKACnVLAhbnt4j@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=boris.ostrovsky@oracle.com \
--cc=chris@chris-wilson.co.uk \
--cc=hch@lst.de \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jgross@suse.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rodrigo.vivi@intel.com \
--cc=sstabellini@kernel.org \
--cc=x86@kernel.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