From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [PATCH 08/18] xen: Add DOMID_SELF support to rcu_lock_domain_by_id
Date: Mon, 06 Aug 2012 12:38:22 -0400 [thread overview]
Message-ID: <501FF2FE.8040603@tycho.nsa.gov> (raw)
In-Reply-To: <502003DD0200007800093011@nat28.tlf.novell.com>
On 08/06/2012 11:50 AM, Jan Beulich wrote:
>>>> On 06.08.12 at 17:19, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 08/06/2012 11:07 AM, Jan Beulich wrote:
>>>>>> On 06.08.12 at 16:32, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> Callers that want to prevent use of DOMID_SELF already need to ensure
>>>> the calling domain does not pass its own domain ID. This removes the
>>>> need for the caller to manually support DOMID_SELF, which many already
>>>> do.
>>>
>>> I'm not really sure this is correct. At the very least it changes the
>>> return value of rcu_lock_remote_target_domain_by_id() when
>>> called with DOMID_SELF (from -ESRCH to -EPERM).
>>
>> This series ends up eliminating that function in patch #18, so that
>> part is taken care of.
>
> But may, in case of problems, then not be fully bi-sectable.
Do we depend on the exact error return codes in non-error code paths?
I would think most attempts to bisect would work just fine as the
function will still be returning an error. I'm not sure ESRCH is
really the best error to return here anyway: the problem is not that
a domain with my_own_domid or DOMID_SELF couldn't be found, it's that
you can't specify that domain for this operation.
>>> I'm also not convinced that a distinction between a domain knowing
>>> its ID and one passing DOMID_SELF isn't/can't be useful. That of
>>> course depends on whether the ID can be fully hidden from a guest
>>> (obviously pure HVM guests would never know their ID, but then
>>> again they also would never pass DOMID_SELF anywhere; it might
>>> be, however, that they could get the latter passed on their behalf
>>> e.g. from some emulation function).
>>
>> I don't think we can (or want to) make it impossible for a guest to find
>> out its own domain ID. I agree that the distinction between DOMID_SELF and
>> my_own_domid can be a useful distinction in some cases. Most of those cases
>> in Xen that I have seen already handle this at the caller.
>>
>> Another solution here is to create a function rcu_lock_domain_by_any_id that
>> is identical to rcu_lock_domain_by_id except for handling DOMID_SELF.
>
> Maybe. I'd like to see Keir's position regarding all of the details
> here anyway.
>
> Jan
>
>
>
--
Daniel De Graaf
National Security Agency
next prev parent reply other threads:[~2012-08-06 16:38 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-06 14:32 [PATCH 00/18] RFC: Merge IS_PRIV checks into XSM hooks Daniel De Graaf
2012-08-06 14:32 ` [PATCH 01/18] xsm/flask: remove inherited class attributes Daniel De Graaf
2012-08-06 14:32 ` [PATCH 02/18] xsm/flask: remove unneeded create_sid field Daniel De Graaf
2012-08-06 14:32 ` [PATCH 03/18] xsm/flask: add domain relabel support Daniel De Graaf
2012-08-06 14:32 ` [PATCH 04/18] libxl: introduce XSM relabel on build Daniel De Graaf
2012-08-06 14:32 ` [PATCH 05/18] flask/policy: Add domain relabel example Daniel De Graaf
2012-08-06 14:32 ` [PATCH 06/18] xsm, arch/x86: add distinct XSM hooks for map/unmap Daniel De Graaf
2012-08-06 14:32 ` [PATCH 07/18] arch/x86: add missing XSM checks to XENPF_ commands Daniel De Graaf
2012-08-06 14:57 ` Jan Beulich
2012-08-06 15:06 ` Daniel De Graaf
2012-08-06 14:32 ` [PATCH 08/18] xen: Add DOMID_SELF support to rcu_lock_domain_by_id Daniel De Graaf
2012-08-06 15:07 ` Jan Beulich
2012-08-06 15:19 ` Daniel De Graaf
2012-08-06 15:50 ` Jan Beulich
2012-08-06 16:38 ` Daniel De Graaf [this message]
2012-08-07 7:00 ` Jan Beulich
2012-08-06 14:32 ` [PATCH 09/18] xsm/flask: Add checks on the domain performing the set_target operation Daniel De Graaf
2012-08-06 14:32 ` [PATCH 10/18] xsm: Add IS_PRIV checks to dummy XSM module Daniel De Graaf
2012-08-06 14:32 ` [PATCH 11/18] xen: use XSM instead of IS_PRIV where duplicated Daniel De Graaf
2012-08-06 15:18 ` Jan Beulich
2012-08-06 15:25 ` Daniel De Graaf
2012-08-06 15:53 ` Jan Beulich
2012-08-06 14:32 ` [PATCH 12/18] xsm: Add missing domctl and mem_sharing hooks Daniel De Graaf
2012-08-06 18:53 ` Keir Fraser
2012-08-06 19:30 ` Daniel De Graaf
2012-08-06 14:32 ` [PATCH 13/18] tmem: Add access control check Daniel De Graaf
2012-08-06 14:32 ` [PATCH 14/18] xsm: remove unneeded xsm_call macro Daniel De Graaf
2012-08-06 14:32 ` [PATCH 15/18] xsm/flask: add distinct SIDs for self/target access Daniel De Graaf
2012-08-06 14:32 ` [PATCH 16/18] arch/x86: use XSM hooks for get_pg_owner access checks Daniel De Graaf
2012-08-06 15:26 ` Jan Beulich
2012-08-06 16:29 ` Daniel De Graaf
2012-08-07 6:55 ` Jan Beulich
2012-08-07 13:44 ` Daniel De Graaf
2012-08-07 13:56 ` Jan Beulich
2012-08-06 14:32 ` [PATCH 17/18] xen: Add XSM hook for XENMEM_exchange Daniel De Graaf
2012-08-06 14:32 ` [PATCH 18/18] xen: remove rcu_lock_target_domain_by_id Daniel De Graaf
2012-08-07 5:12 ` [PATCH 00/18] RFC: Merge IS_PRIV checks into XSM hooks Shakeel Butt
2012-08-07 17:46 ` Daniel De Graaf
2012-08-07 18:07 ` Shakeel Butt
2012-08-07 18:06 ` Konrad Rzeszutek Wilk
2012-08-07 18:20 ` Daniel De Graaf
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=501FF2FE.8040603@tycho.nsa.gov \
--to=dgdegra@tycho.nsa.gov \
--cc=JBeulich@suse.com \
--cc=xen-devel@lists.xen.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).