[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] xsm: add ability to elevate a domain to privileged


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 5 Apr 2022 08:06:31 -0400
  • Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1649160417; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=W9uEMEEVdi9Ua83j3iyEoXl2G+KS1XiR5VYiEdS/0cA=; b=O/hI+PxxLIYdP8mrE+C+z8EoT4oVm2+2nZJkvpBB8oA6Bes4rFOBPimTP0nf1hLMnha1aymAuZz9sm7JBBoKWbEuApi9Z80WwpuE7fkmdHi3Ogg0vWpUb3V8+97yHpcXNTEvPD2rDPkZl2taTCDSJPFpufWzI6kZDWWLhk/MtDY=
  • Arc-seal: i=1; a=rsa-sha256; t=1649160417; cv=none; d=zohomail.com; s=zohoarc; b=c7Tlm1BibFHCgIIZ25boczd7nxwBD/71/ibtsOyBzZo9kr79K7Wgaq5HWWsyxOLpMNyOwmRy7aE27B5F6eQGbyt8SBRpVDgtbFkCk58TyKSrpHTtQeTUrWnzb6E+0X7NjxrZGUHAs8AXFEUxENA/O5/xlV8kLO38mRNtHsyLn18=
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, scott.davis@xxxxxxxxxx, jandryuk@xxxxxxxxx, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Delivery-date: Tue, 05 Apr 2022 12:07:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 4/5/22 03:42, Roger Pau Monné wrote:
> On Mon, Apr 04, 2022 at 12:08:25PM -0400, Daniel P. Smith wrote:
>> On 4/4/22 11:12, Roger Pau Monné wrote:
>>> On Mon, Apr 04, 2022 at 10:21:18AM -0400, Daniel P. Smith wrote:
>>>> On 3/31/22 08:36, Roger Pau Monné wrote:
>>>>> On Wed, Mar 30, 2022 at 07:05:48PM -0400, Daniel P. Smith wrote:
>>>>>> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
>>>>>> index e22d6160b5..157e57151e 100644
>>>>>> --- a/xen/include/xsm/xsm.h
>>>>>> +++ b/xen/include/xsm/xsm.h
>>>>>> @@ -189,6 +189,28 @@ struct xsm_operations {
>>>>>>  #endif
>>>>>>  };
>>>>>>  
>>>>>> +static always_inline int xsm_elevate_priv(struct domain *d)
>>>>>
>>>>> I don't think it needs to be always_inline, using just inline would be
>>>>> fine IMO.
>>>>>
>>>>> Also this needs to be __init.
>>>>
>>>> AIUI always_inline is likely the best way to preserve the speculation
>>>> safety brought in by the call to is_system_domain().
>>>
>>> There's nothing related to speculation safety in is_system_domain()
>>> AFAICT. It's just a plain check against d->domain_id. It's my
>>> understanding there's no need for any speculation barrier there
>>> because d->domain_id is not an external input.
>>
>> Hmmm, this actually raises a good question. Why is is_control_domain(),
>> is_hardware_domain, and others all have evaluate_nospec() wrapping the
>> check of a struct domain element while is_system_domain() does not?
> 
> Jan replied to this regard, see:
> 
> https://lore.kernel.org/xen-devel/54272d08-7ce1-b162-c8e9-1955b780ca11@xxxxxxxx/

Jan can correct me if I misunderstood, but his point is with respect to
where the inline function will be expanded into and I would think you
would want to ensure that if anyone were to use is_system_domain(), then
the inline expansion of this new location could create a potential
speculation-able branch. Basically my concern is not putting the guards
in place today just because there is not currently any location where
is_system_domain() is expanded to create a speculation opportunity does
not mean there is not an opening for the opportunity down the road for a
future unprotected use.

>>> In any case this function should be __init only, at which point there
>>> are no untrusted inputs to Xen.
>>
>> I thought it was agreed that __init on inline functions in headers had
>> no meaning?
> 
> In a different reply I already noted my preference would be for the
> function to not reside in a header and not be inline, simply because
> it would be gone after initialization and we won't have to worry about
> any stray calls when the system is active.

If an inline function is only used by __init code, how would be
available for stray calls when the system is active? I would concede
that it is possible for someone to explicitly use in not __init code but
I would like to believe any usage in a submitted code change would be
questioned by the reviewers.

With that said, if we consider Jason's suggestion would this remove your
concern since that would only introduce a de-privilege function and
there would be no piv escalation that could be erroneously called at
anytime?

v/r
dps



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.