From: Kees Cook <keescook@chromium.org> To: Peter Zijlstra <peterz@infradead.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 20:01:08 -0700 [thread overview] Message-ID: <202104131935.B5EBDAE@keescook> (raw) In-Reply-To: <YHVKACnVLAhbnt4j@hirez.programming.kicks-ass.net> On Tue, Apr 13, 2021 at 09:36:32AM +0200, Peter Zijlstra wrote: > 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. It's better in the sense that it's not the func/arg pair that really bugs me, yes. :) > The alternative is refactoring apply_to_page_range() :-/ Yeah, I'm looking now, I see what you mean. > --- > > 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; > } My point about passing "addr" was that nothing in the callback actually needs it -- the top level can just as easily report the error. And that the helper is always vpr_fn(), so it doesn't need to be passed either. So the addr can just be encoded in "int", and no structure is needed at: typedef bool (*vpr_fn_t)(pte_t pte); static int vpr_fn(pte_t *pte, unsigned long addr, void *data) { vpr_fn_t callback = data; if (!callback(*pte)) return addr >> PAGE_SIZE; return 0; } unsigned long verify_page_range(struct mm_struct *mm, unsigned long addr, unsigned long size, vpr_fn_t callback) { return apply_to_page_range(mm, addr, size, vpr_fn, callback) << PAGE_SIZE; } But maybe I'm missing something? -- Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org> To: Peter Zijlstra <peterz@infradead.org> Cc: jgross@suse.com, sstabellini@kernel.org, intel-gfx@lists.freedesktop.org, x86@kernel.org, linux-kernel@vger.kernel.org, chris@chris-wilson.co.uk, linux-mm@kvack.org, boris.ostrovsky@oracle.com, hch@lst.de, akpm@linux-foundation.org Subject: Re: [Intel-gfx] [PATCH 4/7] mm: Introduce verify_page_range() Date: Tue, 13 Apr 2021 20:01:08 -0700 [thread overview] Message-ID: <202104131935.B5EBDAE@keescook> (raw) In-Reply-To: <YHVKACnVLAhbnt4j@hirez.programming.kicks-ass.net> On Tue, Apr 13, 2021 at 09:36:32AM +0200, Peter Zijlstra wrote: > 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. It's better in the sense that it's not the func/arg pair that really bugs me, yes. :) > The alternative is refactoring apply_to_page_range() :-/ Yeah, I'm looking now, I see what you mean. > --- > > 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; > } My point about passing "addr" was that nothing in the callback actually needs it -- the top level can just as easily report the error. And that the helper is always vpr_fn(), so it doesn't need to be passed either. So the addr can just be encoded in "int", and no structure is needed at: typedef bool (*vpr_fn_t)(pte_t pte); static int vpr_fn(pte_t *pte, unsigned long addr, void *data) { vpr_fn_t callback = data; if (!callback(*pte)) return addr >> PAGE_SIZE; return 0; } unsigned long verify_page_range(struct mm_struct *mm, unsigned long addr, unsigned long size, vpr_fn_t callback) { return apply_to_page_range(mm, addr, size, vpr_fn, callback) << PAGE_SIZE; } But maybe I'm missing something? -- Kees Cook _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-04-14 3:01 UTC|newest] Thread overview: 58+ 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 ` [Intel-gfx] " Peter Zijlstra 2021-04-12 8:00 ` [PATCH 1/7] mm: Unexport apply_to_existing_page_range() Peter Zijlstra 2021-04-12 8:00 ` [Intel-gfx] " Peter Zijlstra 2021-04-12 8:13 ` Christoph Hellwig 2021-04-12 8:13 ` [Intel-gfx] " 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:00 ` [Intel-gfx] [PATCH 2/7] xen/gntdev, x86: " Peter Zijlstra 2021-04-12 8:26 ` [PATCH 2/7] xen/gntdev,x86: " Christoph Hellwig 2021-04-12 8:26 ` [Intel-gfx] [PATCH 2/7] xen/gntdev, x86: " Christoph Hellwig 2021-04-12 9:20 ` [PATCH 2/7] xen/gntdev,x86: " Peter Zijlstra 2021-04-12 9:20 ` [Intel-gfx] [PATCH 2/7] xen/gntdev, x86: " Peter Zijlstra 2021-04-12 9:26 ` [PATCH 2/7] xen/gntdev,x86: " Juergen Gross 2021-04-12 9:26 ` [Intel-gfx] [PATCH 2/7] xen/gntdev, x86: " Juergen Gross 2021-04-12 8:00 ` [PATCH 3/7] xen/gntdev: " Peter Zijlstra 2021-04-12 8:00 ` [Intel-gfx] " Peter Zijlstra 2021-04-12 8:27 ` Christoph Hellwig 2021-04-12 8:27 ` [Intel-gfx] " Christoph Hellwig 2021-04-12 9:02 ` Peter Zijlstra 2021-04-12 9:02 ` [Intel-gfx] " Peter Zijlstra 2021-04-12 8:00 ` [PATCH 4/7] mm: Introduce verify_page_range() Peter Zijlstra 2021-04-12 8:00 ` [Intel-gfx] " Peter Zijlstra 2021-04-12 8:28 ` Christoph Hellwig 2021-04-12 8:28 ` [Intel-gfx] " Christoph Hellwig 2021-04-12 9:17 ` Peter Zijlstra 2021-04-12 9:17 ` [Intel-gfx] " Peter Zijlstra 2021-04-12 20:05 ` Kees Cook 2021-04-12 20:05 ` [Intel-gfx] " Kees Cook 2021-04-13 6:54 ` Peter Zijlstra 2021-04-13 6:54 ` [Intel-gfx] " Peter Zijlstra 2021-04-19 23:36 ` Kees Cook 2021-04-19 23:36 ` [Intel-gfx] " Kees Cook 2021-04-13 7:36 ` Peter Zijlstra 2021-04-13 7:36 ` [Intel-gfx] " Peter Zijlstra 2021-04-14 3:01 ` Kees Cook [this message] 2021-04-14 3:01 ` Kees Cook 2021-04-14 7:00 ` Peter Zijlstra 2021-04-14 7:00 ` [Intel-gfx] " Peter Zijlstra 2021-04-12 8:00 ` [PATCH 5/7] xen/privcmd: Use verify_page_range() Peter Zijlstra 2021-04-12 8:00 ` [Intel-gfx] " Peter Zijlstra 2021-04-12 8:28 ` Christoph Hellwig 2021-04-12 8:28 ` [Intel-gfx] " Christoph Hellwig 2021-04-12 8:00 ` [PATCH 6/7] i915: Convert to verify_page_range() Peter Zijlstra 2021-04-12 8:00 ` [Intel-gfx] " Peter Zijlstra 2021-04-12 8:28 ` Christoph Hellwig 2021-04-12 8:28 ` [Intel-gfx] " Christoph Hellwig 2021-04-12 20:08 ` Kees Cook 2021-04-12 20:08 ` [Intel-gfx] " Kees Cook 2021-04-13 6:54 ` Peter Zijlstra 2021-04-13 6:54 ` [Intel-gfx] " Peter Zijlstra 2021-04-14 3:04 ` Kees Cook 2021-04-14 3:04 ` [Intel-gfx] " Kees Cook 2021-04-12 8:00 ` [PATCH 7/7] mm: Unexport apply_to_page_range() Peter Zijlstra 2021-04-12 8:00 ` [Intel-gfx] " Peter Zijlstra 2021-04-12 8:28 ` Christoph Hellwig 2021-04-12 8:28 ` [Intel-gfx] " Christoph Hellwig 2021-04-12 9:00 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for " Patchwork 2021-04-12 9:23 ` Peter Zijlstra
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=202104131935.B5EBDAE@keescook \ --to=keescook@chromium.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=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=peterz@infradead.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: linkBe 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.