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