[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: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 5 Apr 2022 17:01:53 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=khxftXRJ5VV5NNPI913hPMepB9iJZcjrmSRTl13EHsU=; b=P/BR/IT2yWC+5ONnyCfdZ/dH4cV0cv1ROi/7jPF7ibgcAWug7RcCInYE+QLFODMalyXlC0U0UuawkUXI1IHgnmMhAhSTom8yh/lkd6XB/I3rTKiO18HPt13L0cisVgdXj2gd5xaImCxHA+Ru8Ti50eH2BFKLNzXgBKsge0aPRlh0SHbGXcqbCTGuxitAqcvP0FETMB/VWgruf6ahDL/Nc7yN/KpRPuHmDORDSU+6A6fvlkaExMYFaZTcodFdQJkc4fKV1kfJr2sgUjZz7e1GV+5auOIZVcx24WzkYsNUCMn3x1eTziWPANfZjUT1xLotQbL8qenHKpAkaUiDaJ8jJw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c49vcgNnfFzzQT8zeHOT0hGPrJ3GxNXRIgFGs5fBR8cLk6IdWzxPoJ8i1BXdMkDjPn1tRayycuRZt0ID8Pm/EYQtRcVCz0LwH4meztOtcwzkokOV0fOty4yAkx0KO3lhKfP7t3ty48CYcUEN90REZFQUMBU7LJ8rVPnGkVEHN33FqekEzjfygnSr1wbSIabQ4jAiTJbhbWsiPXu6EROWxDv0GCpwJgPTjuAqBhWzkFacdtiD4AfqdE20IKiLT9VH+IvWqWXvwgI2f9Iay12vZrRkKoYUfQyHuAyaH0nONhCPLo5T9hwA8dP2mKuWQcWvybqCiyyebfyjBkOing8Dzg==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • 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 15:02:28 +0000
  • Ironport-data: A9a23:VGv/OK6C5x80v9bBqRQ7cQxRtOjHchMFZxGqfqrLsTDasY5as4F+v jQbCmjTP/6CYGbyKY1yOd+y/UpU6J7WyIBqTgdq/y49Hi5G8cbLO4+Ufxz6V8+wwmwvb67FA +E2MISowBUcFyeEzvuVGuG96yE6j8lkf5KkYAL+EnkZqTRMFWFw0XqPp8Zj2tQy2YThXlvX0 T/Pi5a31GGNimYc3l08s8pvmDs31BglkGpF1rCWTakjUG72zxH5PrpGTU2CByKQrr1vNvy7X 47+IISRpQs1yfuP5uSNyd4XemVSKlLb0JPnZnB+A8BOiTAazsA+PzpS2FPxpi67hh3Q9+2dx umhurSxdD8VboTmsdg0Vjh0FxgvGaFp/rjudC3XXcy7lyUqclPpyvRqSko3IZcZ6qB8BmQmG f4wcW5XKErZ3qTvnez9GrIEascLdaEHOKsFvX5t13fBBOsOSpHfWaTao9Rf2V/cg+gQTa6DO ZVANlKDajzJWg8fI2kTFa5lgb26wXqnSmxpiQqs8P9fD2/7k1UqjemF3MDuUt6DQ8lPj1ubj m3D9mX9RBodMbS3xTWJ/322j8fTjCj7X8QUD7T++fl06HWIzWsPFFsaXEW6utGilkekX9tVb U0TkgIitbM39VCrZtDlUgekvWWfuRoBR9tXFfZ84waIooLE7gDcCmUaQzppbN09qNRwVTEsz kWOnd7iGXpoqrL9dJ6G3u7K93XoY3FTdDJcI39fJecY3zX9iIAOti6fZ/xKLIewr/HxIGDUz x+MqwFr0t3/kvU3/6m8+FnGhRelqZ7IUhM5623rY4610u9qTNX7PtL1sDA3+d4Fdd/EFQfZ4 BDojuDEtIgz4YexeDthqQnnNJWg/L67PTLVmjaD9LFxpm32qxZPkW29iQySxXuF0O5ZIlcFg 2eJ4Gu9AaO/2lPwMMebhKrrVqwXIVDIT4iNaxwtRoMmjmJNXAGG5jpyQkWbwnrglkMh+YlmZ 8vKKZz0UStGUvg7pNZTewv7+eV2rszZ7TmNLa0XMjz9iebODJJrYelt3KSyghARs/rf/VS9H yd3PMqW0RRPONASkQGMmbP/2WsidCBhbbiv8pQ/XrfafmJORTFwY9eMkOhJU9E0wMxoehLgo yjVtrlwkwGk2xUq6GyiNxheVV8Ydc0m9yhmYnVwYw3ANrpKSd/H0ZrzvqAfJNEP3Odi0eR1X 78CfcCBCe5IUTPJ53IWapyVkWCoXE327e5SF0JJuAQCQqM=
  • Ironport-hdrordr: A9a23:dWfIV6yIeVZH2T/QLSeoKrPw9b1zdoMgy1knxilNoEpuA7elfq eV7ZAmPH7P+VMssBNJo7q90cy7LE80mqQY3WB8B9iftWrdyQmVxeNZjbcKmAeQYhEWn9Q1vc xdms5FZuEYZmIK7voSjjPYLz6OquP3ipxBKY3lvhBQpaABUdAH0y54Dh+cCVB/QwNLbKBJbK ah2g==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.



 


Rackspace

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