[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 Tue, Apr 05, 2022 at 08:06:31AM -0400, Daniel P. Smith wrote: > 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. Right, it's IMO easier when things just explode when not used correctly, hence my suggestion to make it __init. > 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? Indeed. IMO everything that happens before the system switches to the active state should be considered to be running in a privileged context anyway. Maybe others have different opinions. Or maybe there are use-cases I'm not aware of where this is not true. Thanks, Roger.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |