From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@citrix.com>,
Ian Jackson <iwj@xenproject.org>, Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] common: don't require use of DOMID_SELF
Date: Thu, 14 Jan 2021 16:38:27 +0100 [thread overview]
Message-ID: <c6a6c3e5-ef52-51f6-261c-06ae2d477b43@suse.com> (raw)
In-Reply-To: <3c0ebca6-a5e9-36a8-cfeb-6abc0fc7c2af@citrix.com>
On 14.01.2021 16:01, Andrew Cooper wrote:
> On 14/01/2021 14:02, Jan Beulich wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -2776,15 +2776,19 @@ struct gnttab_copy_buf {
>> static int gnttab_copy_lock_domain(domid_t domid, bool is_gref,
>> struct gnttab_copy_buf *buf)
>> {
>> - /* Only DOMID_SELF may reference via frame. */
>> - if ( domid != DOMID_SELF && !is_gref )
>> - return GNTST_permission_denied;
>> -
>> buf->domain = rcu_lock_domain_by_any_id(domid);
>>
>> if ( !buf->domain )
>> return GNTST_bad_domain;
>>
>> + /* Only the local domain may reference via frame. */
>> + if ( buf->domain != current->domain && !is_gref )
>> + {
>> + rcu_unlock_domain(buf->domain);
>> + buf->domain = NULL;
>> + return GNTST_permission_denied;
>> + }
>
> In this case, it's also a weird asymmetry where this is one grant table
> operation which a privileged domain can't issue on behalf of an
> unprivileged one.
Well, in a way, perhaps. If it was useful, perhaps it would have
been made work and allowed, so I wonder whether there simply is
no good use for it?
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -2566,13 +2566,7 @@ __initcall(register_heap_trigger);
>>
>> struct domain *get_pg_owner(domid_t domid)
>> {
>> - struct domain *pg_owner = NULL, *curr = current->domain;
>> -
>> - if ( unlikely(domid == curr->domain_id) )
>> - {
>> - gdprintk(XENLOG_WARNING, "Cannot specify itself as foreign domain\n");
>> - goto out;
>> - }
>> + struct domain *pg_owner;
>
> I'm not sure this is correct.
>
> It isn't a DOMID_SELF check. It's a "confirm the nominated domid is
> remote" check, and I don't see all the callers of this interface having
> appropriate checks to prohibit trying to do a foreign operation on
> oneself, however they specify the foreign domid.
No, I don't think so. Prior to a625c335593e ("common: don't (kind
of) open-code rcu_lock_domain_by_any_id()") DOMID_SELF was explicitly
permitted. As of that change, it's implicitly permitted. I don't see
how using DOMID_SELF would be okay when using the numeric ID isn't.
(I'm not going to exclude there may be missing checks in some of the
callers, but from prior audits I don't recall recognizing any.)
Jan
next prev parent reply other threads:[~2021-01-14 15:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-14 14:02 [PATCH] common: don't require use of DOMID_SELF Jan Beulich
2021-01-14 14:43 ` Julien Grall
2021-01-14 15:30 ` Jan Beulich
2021-01-14 15:36 ` Andrew Cooper
2021-01-15 9:59 ` Julien Grall
2021-01-15 10:22 ` Jan Beulich
2021-01-14 15:01 ` Andrew Cooper
2021-01-14 15:38 ` Jan Beulich [this message]
2021-01-15 10:49 ` Jan Beulich
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=c6a6c3e5-ef52-51f6-261c-06ae2d477b43@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=iwj@xenproject.org \
--cc=julien@xen.org \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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 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.