[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
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |