From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Julien Grall <julien@xen.org>, <paul@xen.org>,
'Xen-devel' <xen-devel@lists.xenproject.org>
Cc: "'Stefano Stabellini'" <sstabellini@kernel.org>,
"'Hubert Jasudowicz'" <hubert.jasudowicz@cert.pl>,
"'Wei Liu'" <wl@xen.org>,
"'Konrad Rzeszutek Wilk'" <konrad.wilk@oracle.com>,
"'George Dunlap'" <George.Dunlap@eu.citrix.com>,
"'Michał Leszczyński'" <michal.leszczynski@cert.pl>,
"'Jan Beulich'" <JBeulich@suse.com>,
"'Ian Jackson'" <ian.jackson@citrix.com>
Subject: Re: [PATCH 4/5] xen/memory: Fix acquire_resource size semantics
Date: Thu, 30 Jul 2020 20:53:10 +0100 [thread overview]
Message-ID: <7b7aae0d-35d8-8bfa-7352-8e3c58873964@citrix.com> (raw)
In-Reply-To: <d0c00a30-2f72-036e-d574-a82e96ea79ea@xen.org>
On 30/07/2020 13:54, Julien Grall wrote:
> Hi Paul,
>
> On 30/07/2020 09:31, Paul Durrant wrote:
>>> diff --git a/xen/common/memory.c b/xen/common/memory.c
>>> index dc3a7248e3..21edabf9cc 100644
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -1007,6 +1007,26 @@ static long xatp_permission_check(struct
>>> domain *d, unsigned int space)
>>> return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
>>> }
>>>
>>> +/*
>>> + * Return 0 on any kind of error. Caller converts to -EINVAL.
>>> + *
>>> + * All nonzero values should be repeatable (i.e. derived from some
>>> fixed
>>> + * proerty of the domain), and describe the full resource (i.e.
>>> mapping the
>>
>> s/property/property
>>
>>> + * result of this call will be the entire resource).
>>
>> This precludes dynamically adding a resource to a running domain. Do
>> we really want to bake in that restriction?
>
> AFAICT, this restriction is not documented in the ABI. In particular,
> it is written:
>
> "
> The size of a resource will never be zero, but a nonzero result doesn't
> guarentee that a subsequent mapping request will be successful. There
> are further type/id specific constraints which may change between the
> two calls.
> "
>
> So I think a domain couldn't rely on this behavior. Although, it might
> be good to clarify in the comment on top of resource_max_frames that
> this an implementation decision and not part of the ABI.
There are two aspects here.
First, yes - I deliberately didn't state it in the ABI, just in case we
might want to use it in the future. I could theoretically foresee using
-EBUSY for the purpose.
That said however, we are currently deliberately taking dynamic
resources out of Xen, because they've proved to be unnecessary in
practice and a fertile source of complexity and security bugs.
I don't foresee accepting new dynamic resources, but that's not to say
that someone can't theoretically come up with a sufficiently compelling
counterexample.
~Andrew
next prev parent reply other threads:[~2020-07-30 19:53 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 11:37 [PATCH 0/5] Multiple fixes to XENMEM_acquire_resource Andrew Cooper
2020-07-28 11:37 ` [PATCH 1/5] xen/memory: Introduce CONFIG_ARCH_ACQUIRE_RESOURCE Andrew Cooper
2020-07-29 19:41 ` Jan Beulich
2020-07-30 8:02 ` Paul Durrant
2020-07-30 17:34 ` Andrew Cooper
2020-07-30 18:24 ` Paul Durrant
2020-07-30 9:50 ` Julien Grall
2020-07-30 17:28 ` Andrew Cooper
2020-07-30 18:30 ` Julien Grall
2020-07-28 11:37 ` [PATCH 2/5] xen/gnttab: Rework resource acquisition Andrew Cooper
2020-07-28 14:11 ` Andrew Cooper
2020-07-29 20:02 ` Jan Beulich
2020-09-22 13:10 ` Andrew Cooper
2020-09-22 13:34 ` Jan Beulich
2020-09-22 14:50 ` Andrew Cooper
2020-09-22 16:01 ` Jan Beulich
2020-07-30 8:14 ` Paul Durrant
2020-09-22 13:13 ` Andrew Cooper
2020-07-30 10:56 ` Julien Grall
2020-07-28 11:37 ` [PATCH 3/5] xen/memory: Fix compat XENMEM_acquire_resource for size requests Andrew Cooper
2020-07-29 20:09 ` Jan Beulich
2020-07-30 19:12 ` Andrew Cooper
2020-07-31 7:52 ` Jan Beulich
2020-07-30 8:19 ` Paul Durrant
2020-07-28 11:37 ` [PATCH 4/5] xen/memory: Fix acquire_resource size semantics Andrew Cooper
2020-07-30 8:31 ` Paul Durrant
2020-07-30 12:54 ` Julien Grall
2020-07-30 19:53 ` Andrew Cooper [this message]
2020-07-30 19:46 ` Andrew Cooper
2020-07-30 20:00 ` Julien Grall
2020-07-31 14:31 ` Jan Beulich
2020-07-31 14:44 ` Jan Beulich
2020-07-31 14:53 ` Andrew Cooper
2020-07-28 11:37 ` [PATCH 5/5] tools/foreignmem: Support querying the size of a resource Andrew Cooper
2020-07-28 14:14 ` Andrew Cooper
2020-08-04 14:29 ` Wei Liu
2020-07-30 8:39 ` Paul Durrant
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=7b7aae0d-35d8-8bfa-7352-8e3c58873964@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=hubert.jasudowicz@cert.pl \
--cc=ian.jackson@citrix.com \
--cc=julien@xen.org \
--cc=konrad.wilk@oracle.com \
--cc=michal.leszczynski@cert.pl \
--cc=paul@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).