[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: Thu, 31 Mar 2022 14:36:46 +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=qUD+Aef2G2wBse57yFY1CeNDuTTiUsMk8fpA8sTCLuQ=; b=No7xCWSAB3wX3023MMlbOl16VHEjcbY/kZN2OY209gdD6W9hleqlR/PE1XQLOQ7S+8jUIjqGp7+WZln6Wwraq2w3LbDAGbvAoe7rf75pVwYf43yZhelNYF6uy7bkROl+NTF4SaQyuwKT6oGkqcahNYcPuS7ZotvsPhmfqtCPxpto6PjiLVC9RgbXXVQ9Dxv2O1/3VS8TvL6Jbmzr01O7/l+WQmcHGA8LxOM9zKQJNy73yZfgbsqz3bKT+X6q1GYf8gvacvPfI2PROC/zdg/NgbZZgU9ytiA4htGXsKOuz7vc+RO3Y6c/2bfZ6k9yHMCodpO2bPAaiqI2unSLOcXPhg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MW1bP/eBRnIX0yVT+M875lWK+MlUruiy9w0sflvJXVrFWQ+BtP/fKebv5EjmLaO8nMwlYIXaGlfNLRfAeljPFAA1B8VuAFZgjTNASj+7A3qMzqWB7VDOHdx3duLJH/4w/hNe8EAKU8hLFqSt0FW2hGZRGHljIQlAUSp+h0oFnnTW3PXNShQgvSbuMVOb1JSzM5HIBGvgdhvAJ7buZInde793howqyaLcb1NdGi8W37LfsZMoY3rymMqsPZ647hmRrfj5T9J1z5/nNzmYzS8jdw7yH9Aa/RAsPMxcechDlGC14YSwfPiR9AdwI1gucQYDM/MT55VR0O4NPZlhBX3oBQ==
  • Authentication-results: esa6.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>
  • Delivery-date: Thu, 31 Mar 2022 12:37:03 +0000
  • Ironport-data: A9a23:Wf9y8KohYQz29jQLmgfU4rdfQbBeBmLJZRIvgKrLsJaIsI4StFCzt garIBnXPvmNMWX0e4h+O4XjoUIA6JLRndQ1GQU/ryhgEH8W85uZCYyVIHmrMnLJJKUvbq7GA +byyDXkBJppJpMJjk71atANlVEliefQAOCU5NfsYkidfyc9IMsaoU8lyrZRbrJA24DjWVvW4 oqq+aUzBXf+s9JKGjNMg068gEsHUMTa4Fv0aXRnOJinFHeH/5UkJMp3yZOZdhMUcaENdgKOf M7RzanRw4/s10xF5uVJMFrMWhZirrb6ZWBig5fNMkSoqkAqSicais7XOBeAAKv+Zvrgc91Zk b1wWZKMpQgBeYvI38RabQJkCCBibf1hyOadE3+/vpnGp6HGWyOEL/RGCUg3OcsT+/ptAHEI/ vsdQNwPRknd3aTsmuv9E7QywJR4RCXoFNp3VnVI1zbWAOxgWZnea67L+cVZzHE7gcUm8fP2O ZVENGEzNUqojxtnFFcIJowzvLaRj3CgKyRngg2rq5cr2j2GpOB2+Oe0a4eEEjCQfu1Xl0CUv HPb/Ez2BxgbMJqUzj/t2n6jiuLAhyrTRJMZFLr+8OVjxlKU2AQ7ExYRSUf9rfCni1WWQM5WM Ugd8GwvqsAa+FSwS9jhXzWxuHOeogMHQN1UDvE77weWjKHT5m6xFmUCCzJMdtEinMs3XiAxk E+EmcvzAj5iu6HTTmiSnop4thvrZ3JTdzVbI3ZZE01VuLEPvb3fkDqIaNIkMOmLleHuGC2gk xe69XIMgLUc2JtjO7qAwXjLhDelp57sRwEz5xnKUm/N0j6VdLJJdKTztwGFsK8owJKxCwDY4 SNaw5T2APUmV8nlqcCbfAka8FhFDd6hOSaUv1NgFoJJG9+Fqy/6JtA4DN2TyS5U3ic4ld3BP Re7VeB5vsY70J6WgUlfOdjZ5yMCl/SIKDgdfqqIBueim7AoHON9wAlgZFSLw0fmm1U2nKc0N P+zKJjwXShEVPs5lmfpGo/xNIPHIAhknws/orihknyaPUe2PibJGd/pznPQBgzG0E90iFqMq IsOXyd74x5eTPf/ckHqHX07djg3wYwALcmu8aR/L7fbSiI/QT1JI6KBkNsJJt0+94wIx7igw 51IchIBoLYJrSacclvih7EKQO6HYKuTWlpgY3R2ZAz4iiV7CWtthY9GH6YKkXAc3LUL5dZ/T uUfetXGBfJKSz/d/C8aY4W7p4tnHClHTyrXV8Z5SFDTp6JdejE=
  • Ironport-hdrordr: A9a23:7odmTaEV9PJjriczpLqFBpHXdLJyesId70hD6qkvc3Jom52j+P xGws526faVslYssHFJo6HnBEClewKgyXcV2/hqAV7GZmjbUQSTXeRfBOfZslnd8mjFh5JgPM RbAtlD4b/LfCBHZK/BiWHSebtQo6jkzEnrv5ak854Ed3AVV0gK1XYBNu/0KDwQeOEQbqBJa6 Z0q/A37waISDAyVICWF3MFV+/Mq5nik4/nWwcPA1oC5BOVhT2lxbbmG1zAty1uGQ9n8PMHyy zoggb57qKsv7WSzQLd7Xba69BzlMH6wtVOKcSQgow+KynqiCyveIN9Mofy9wwdkaWK0hIHgd PMqxAvM4Ba7G7QRHi8pV/X1wzpwF8Vmgjf4G7dpUGmjd3yRTo8BcYEr5leaAHl500pu8w5+L 5X3kqC3qAnQi/orWDY3ZzlRhtqnk27rT4JiugIlUFSVoMYdft4sZEfxkVIC50NdRiKpLzPKN MeTf002cwmMW9zNxvizypSKZ2XLzkO9y69MwY/Upf/6UkVoJh7p3FosPD30E1wsa7VcKM0lN gsAp4Y5I2mcfVmH56VJN1xN/dfWVa9CC4lDgqpUCHa/ec8Sjbwl6I=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

> +{
> +    if ( is_system_domain(d) )
> +    {
> +        d->is_privileged = true;
> +        return 0;
> +    }
> +

I would add an ASSERT_UNREACHABLE(); here, I don't think we have any
use case for trying to elevate the privileges of a non-system domain.

Thanks, Roger.



 


Rackspace

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