[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 09:42:26 +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=ujeaJow8xSy9r7cLaQRDnkOrgWUB0pRTW7ImUZPADDY=; b=ej21RTttHcJ2391VJYaI81j2RnnhuKhhJXhRaJMaWNkTh3MB0b12dCKmcR6EWdGQezEW8+FEkEr9tZUicZGFEp+OO1th0VYXMuwgOPN89BWF+AcZ+1Ks5M/XCqqb5WvNCRC8bao2OGTbme91f2Wg4jLhu9bN65+5kHubP2ZmjcnIIlAPw5R8K9mtjyZHnHUAO4TMjpEIa5dFnMTP/JNs6PpcwTTOxMnh1+cgzy9yGcNCPi3qX8NdKWqe/HfiPi3QLXL13Auey6DgWwulKW0xKGfl2y5V/QpaEAY6qS9wdsFgdZN99UOnnZVqpDoeG6cNGUitbQgBN3U6enMjv5yLzg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RIw9KEERhLj85XtWy+K+3qvURkaiAUGatRnQJm2rcPa/yd3a7tiSYyPxAhsBgnAZWBGu59X5rE1xPo1rgC3mEFEk4b59nR4d57RP32ITcaZz2yX0rjXc7dGjOu0mQeT2ocI02quFXWpvRkyrydATDNDBCXIsMQUaQAaUFWhm33TmhLdl1VREHE9f7aWin6I8j4dwqlMMDErUUGtPt9C5JakOvqbfKXxKPhHgav20Q2Je4GOhKCi9y/UU7nmsCBULNXNvACGPtZosy6eFB0Ie9MMItkI0836HQ3XsAKjY/YJI+byDkeUQBSysF+Vh0PRzns3vBgZG09muNmGTqO4DDg==
  • 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 07:43:02 +0000
  • Ironport-data: A9a23:KNnO762cheybMdU1s/bD5QJxkn2cJEfYwER7XKvMYLTBsI5bp2RVy 2pOCj/Va6uINDT3Lt4jYIzk9x5XsceDmIA1SgNspC1hF35El5HIVI+TRqvS04J+DSFhoGZPt Zh2hgzodZhsJpPkjk7xdOCn9xGQ7InQLlbGILes1htZGEk1EE/NtTo5w7Rj2tIw3IDga++wk YiaT/P3aQfNNwFcagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDfjZw0/DaptVBoaHq 9Prl9lVyI97EyAFUbtJmp6jGqEDryW70QKm0hK6UID66vROS7BbPg/W+5PwZG8O4whlkeydx /0cmK2IdlwsHpbFxsoSQ0lUSi5uMbd/reqvzXiX6aR/zmXDenrohf5vEFs3LcsT/eMf7WNmr KJCbmpXN1ba2rzwkOnTpupE36zPKOHxO4wSoDd4xCzxBvc6W5HTBa7N4Le02R9u1pgXQqeEP aL1bxJTbTfkfg9jOW1JI6omsMGq3l7AKTRx/Qf9Sa0fvDGIkV0ZPKLWGNjcfNCQVNhWtkmdr 2PCuW/+B3kyONOTxDWf+1qwl+TPmmX9Q4tUG7qmntZxi1qP2iofAQMXTnOgvfCjjke0HdNYQ 2QY4jErrLQy3EWzQ8PhQgajp3qZoh8bXcEWGOo/gCmdx6yR7wuHC2wsSj9adMdgpMIwXSYt1 FKCg5XuHzMHjVGOYSvDrPHO92r0YHVLaz9ZDcMZcecby4jOkbkM1Rfvdd89PqGl3tGsFiH82 Qnf+UDSmI4vpcIM0qy6+3XOjDStuoXFQ2YJ2+nHYo62xlgnPdD4PuRE/XCetK8dd9jBEjFtq VBew6CjAPYy4YZhfcBnaMEEB/mX6vmMK1UwanY/TsB6p1xBF5NOFL28AQ2Sxm80aa7omhezO Sc/XD+9ArcJYRNGioctPuqM5zwCl/SIKDgcfqm8giBySpZwbhSb2ypleFSd2Wvg+GB1z/1uY c3DLZvwVipGYUiC8NZQb71AuVPM7npgrV4/uLihl0j3uVZgTCD9pUg53KumMblisfLsTPT9+ NdDLcqaoyizo8WlChQ7BbU7dAhQRVBiXMieg5UOKoarf1o3cEl8WqS56e5wJORYc1F9y76gE oeVARQDljISRBTvdG23V5yUQOi2B8wi8itnY3dE0JTB8yFLXLtDJZw3LvMfVbIm6PZi3bhzS fwEcN+HGfNBVnLM/DF1UHU3hNcKmMiD7e5WAxeYXQ==
  • Ironport-hdrordr: A9a23:b94wOql2vUwe7StELRf8+/GLpQjpDfIo3DAbv31ZSRFFG/Fw8P re+8jztCWE7Ar5PUtKpTnuAsW9qB/nmqKdgrNwAV7BZmfbUQKTRekJgLcKqAeAJwTOssJbyK d8Y+xfJbTLfD1HZB/BkWqF+gAbsbu6zJw=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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/

> > 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.

Thanks, Roger.



 


Rackspace

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