[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: Julien Grall <julien@xxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 4 Apr 2022 10:08:47 +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=HPHxqm4vhRWgFvqFN43iPqVfvXcxfZjq+Puv8C3Oo60=; b=iLrf0hXhC+3AMgud0T5Ms4rA/inP6UXZ0OVphgX4vrA7ZUT3hsGCiXgm4H32CYyPPvVt0vYn08eMCvTE7wmaaLS1yPD9rpRXiJ9wBsoiUbY95Uuc522vdKlHCSnIGysKQOD2pyaBw4D0FfF0Bh4vflHhgwUDeyv4mE4j/0S3mggxqisDRJ7iCB2agEtNoM2dtl4Hpd0yN1Yv6XgVfkJ9zxNUFTInWhb0UnJZ3a12zlfklXT59Q1KZ7Q/5Uq6n4xtFl6HRy2ssIPJB35n27eDRqEF9rDV3v+W/7Kfrpy3g988UmUptK0ApwKrdNMCxt84Tamj8jSMZ9ttfqfFlb4Puw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Aa45ssHW/oFA8rrzpDvfb4+mLQQ/FmHNuIvLXgBTKmBJLQ6dhMznN4nm2uCkO58MoX/lk/w3abnTU9V2XOX2wcD82xOaDOY4B8Gog42NnlBRQN5YdOU5YUPdn/7AGRMDqf1jK5r/Z+jrpWNqkxVCLuj3BWTO55nDlvjpaXUT535ZhG2/4Z2TSsnR3TIvQs9bI4ivnp8POWpH5VlQacLU9JqYQXQIKStdYLLZexDEUA2NzqFYTUGlKrpQ0P0UDR0muSzq4j15jhvAZ8ecYHG5rBm/3wmrK2mV650XQBZ1RX+YtxNk35zefgq1RsjYmC7iBnrpc1LYcR3y8GVP/4abnA==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>, <scott.davis@xxxxxxxxxx>, <jandryuk@xxxxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 04 Apr 2022 08:09:32 +0000
  • Ironport-data: A9a23:mnsItKy9g2QJXdI1jJV6t+fXxirEfRIJ4+MujC+fZmUNrF6WrkVRm 2YaCj/XM/bYNmDzfI0lYNu280MDvJbRn4dqHgM5+CAxQypGp/SeCIXCJC8cHc8zwu4v7q5Dx 59DAjUVBJlsFhcwnj/0bv656yMUOZigHtIQMsadUsxKbVIiGX9JZS5LwbZj2NY02YPhWWthh PupyyHhEA79s9JLGjp8B5Kr8HuDa9yr5Vv0FnRnDRx6lAe2e0s9VfrzFonoR5fMeaFGH/bSe gr25OrRElU1XfsaIojNfr7TKiXmS1NJVOSEoiI+t6OK2nCuqsGuu0qS2TV1hUp/0l20c95NJ Npl6pyUVgELF/33qM8EEAN+IjFubKBP5+qSSZS/mZT7I0zudnLtx7NlDV0sPJ1e8eFyaY1M3 aVGcnZXNEnF3r/ohuLgIgVvrp1LwM3DJoQQt2sm1TjEJf0nXYrCU+PB4towMDIY2J8fRKiDO JJxhTxHZjvSTiBjfWcuApMsneeB3UXAfgF8gQfAzUYwyzeKl1EguFT3C/LOcduWWYNZl1iZv Urd423jBhgQct2YoRKH+3SgnP7Sngv0XYsTEPuz8fsCqFGcymEcEhQ+SUqwof7/jFW3Hd1YN SQ8+DcqrKU03FymSJ/6RRLQiHKcpRsdR9p4GvU38h2Q0bHT5xuFB28CVXhKb9lOnN87Q3km2 0GEm/vtBCdzq/uFRHSF7LCWoDiufy8PIgc/iTQsFFVfpYO5+cdq00yJHo0L/LOJYsPdRjHU3 DaohXgFt54KztQt5rWrrF3OnGf5znTWdTId6gLSV2Ojywp2Yo+5eoClgWTmAeZ8wJWxFQfY4 iVd8ySKxKVXVMzWynTRKAkYNOvxj8tpJgEwlrKG83MJ0z22s0CucolLiN2VDBc4a51UEdMFj aK6hO+w2HOxFCbxBUOUS9joYyjP8UQGPY64PhwzRoATCqWdjCfdoElTibe4hggBanQEn6AlI ou8es2xF3scAqkP5GPoG7ZFi+d3m3xlmT+7qXXHI/KPi+f2iJm9E+ltDbdzRrphsPPsTPv9r b6zyPdmOz0ACbajM0E7AKYYLEwQLGhTOHwFg5c/SwJ3GSI/QDtJI6aImdsJItU594wIxrag1 izsASdwlQug7UAr3C3XMxiPnpu0Bs0hxZ/6VARxVWuVN48LOt3wvP9GJ8JoJdHKNoVLlJZJc hXMQO3ZatxnQTXb4TUNK577qY1pbhOwggySeSGiZVACk1RIHlChFgPMFuc3yBQzMw==
  • Ironport-hdrordr: A9a23:ln87/qsCbU8Jnn4d+QsrXPK77skCkoMji2hC6mlwRA09TyXGra 6TdaUguiMc1gx8ZJhBo7C90KnpewK7yXdQ2/htAV7EZnibhILIFvAZ0WKG+Vzd8kLFh4tgPM tbAsxD4ZjLfCdHZKXBkXmF+rQbsaG6GcmT7I+0pRodLnAJV0gj1XYDNu/yKDwGeOAsP+tBKH Pz3Lshm9L2Ek5nEPhTS0N1FNTrlpnurtbLcBQGDxko5E2nii6p0qfzF1y90g0FWz1C7L8++S yd+jaJq5mLgrWe8FvxxmXT55NZlJ/IzcZCPtWFjowwJi/3ggilSYx9U/mpvSwzosuo9FE2+e O86SsIDoBW0Tf8b2u1qRzi103J1ysv0WbrzRuijX7qsaXCNUQHIvsEobgcXgrS6kImst05+r lMxXilu51eCg6FtDjh5vDTPisa2HackD4Hq6o+nnZfWYwRZPt6tooE5n5YF58GAWbT9J0nKu 9zF8vRjcwmPm9yV0qp/lWH/ebcHUjaRny9Mwo/U42uonRrdUlCvgolLJd1pAZEyHo/I6M0kN gsfJ4Y0I2mdfVmH56VNN1xMvdfNVa9NC4kEFjiaGgPR5t3c04klfbMkcEIDaeRCds18Kc=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Apr 01, 2022 at 06:52:46PM +0100, Julien Grall wrote:
> Hi,
> 
> On 31/03/2022 13:36, Roger Pau Monné wrote:
> > On Wed, Mar 30, 2022 at 07:05:48PM -0400, Daniel P. Smith wrote:
> > > There are now instances where internal hypervisor logic needs to make 
> > > resource
> > > allocation calls that are protected by XSM checks. The internal 
> > > hypervisor logic
> > > is represented a number of system domains which by designed are 
> > > represented by
> > > non-privileged struct domain instances. To enable these logic blocks to
> > > function correctly but in a controlled manner, this commit introduces a 
> > > pair
> > > of privilege escalation and demotion functions that will make a system 
> > > domain
> > > privileged and then remove that privilege.
> > > 
> > > Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
> > > ---
> > >   xen/include/xsm/xsm.h | 22 ++++++++++++++++++++++
> > 
> > I'm not sure this needs to be in xsm code, AFAICT it could live in a
> > more generic file.
> > 
> > >   1 file changed, 22 insertions(+)
> > > 
> > > 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.
> 
> Hmmm.... I thought adding __init on function defined in header was
> pointless. In particular, if the compiler decides to inline it.

Indeed, I didn't realize, thanks for pointing this out.

> In any case, I think it would be good to check that the system_state <
> SYS_state_active (could potentially be an ASSERT()) to prevent any misuse.

My preference would be to make those non-inline then I think, we could
place them in common/domain.c maybe? There's no performance reason to
have those helpers as inline.

Another option would be what Jason suggested about creating the idle
domain as privileged and then dropping the privileges before starting
any domains (ie: before setting the system as ACTIVE).

This expands the duration the idle domain context is marked as
privileged, but OTOH we don't need to add a hook to set
is_privileged.

Thanks, Roger.



 


Rackspace

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