[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v8 2/5] x86/pvh: Allow (un)map_pirq when dom0 is PVH


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Date: Fri, 17 May 2024 08:44:27 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.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=DtLpXzztWnQFiZ/jQJdTjRq4vRU5Crq+vtVahnSG6r0=; b=QPuiO1SRRBQeBBZQDNmggxM09hXY8OIQdLoRP5wd94ygQFnxzaKEAGlIlBjfT0TdVCIy9qMH7le1M4MkdRnpvkJW1J4i3LZLhFTp2G7qnvGDDIfYbgrHYjNJkQpkgCvY5tJ1gbCleHTPXng1dQUIBRDrLKA4sw3bMj7pqmcODqC1mB6c2qrDo4xqQbwCWHQnSFrL06rJKWdmaxJBgd262QE16dbVlhsSpMlxGVIkPXc9J1sw5IvLjMCqsZjZ0tP25tIiOQFZzmIGcqpwyjvcD/aztroHW9O6ryyqRdalWqBCuKTbG0/kaGMULtjtTFUYXZCTQAF0Xk1/9JBoqEAjyw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fENSODaGdX7y8JfBve+NxUutd0XOEYDXq1VxKgBVfyYC5kxQHaz5ZIiyweXNwZX8JQkBxBQq2K8j1NJPOtDLCmxFL5sHSF9IPxCbPV1U7uKXeMCvkeWmNmvHzpkF5asTvIJwcqafBb8kwHbX70BxaNreVnR7TDpR86rjz1Y+qXANY3zC1AH79/NnSpC/PHI/7MKy3e8k6mbUnDBagNLwyRma2LGnTcKt7WYR+iE3GKWr/WAcQwmTGNcRbDemRoBMjuwQ3NU1gF/Y67iNKt/MThbV2LGj4d9nRLbRUtWjwRqXnEmAcJ/uGGqdthG32adq5n2X+EIHNTjCErklm3d68w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Anthony PERARD <anthony@xxxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, "Daniel P . Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, "Hildebrand, Stewart" <Stewart.Hildebrand@xxxxxxx>, "Huang, Ray" <Ray.Huang@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Delivery-date: Fri, 17 May 2024 08:44:36 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHap3bYQFs2wap0sUqpOSsc/BlazbGZ21MAgAG+yQA=
  • Thread-topic: [XEN PATCH v8 2/5] x86/pvh: Allow (un)map_pirq when dom0 is PVH

On 2024/5/16 21:29, Jan Beulich wrote:
> On 16.05.2024 11:52, Jiqian Chen wrote:
>> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
>> a passthrough device by using gsi, see
>> xen_pt_realize->xc_physdev_map_pirq and
>> pci_add_dm_done->xc_physdev_map_pirq.
> 
> xen_pt_realize() is in qemu, which imo wants saying here (for being a 
> different
> repo), the more that pci_add_dm_done() is in libxl.
OK, I will describe more here(in qemu and in libxl).

> 
>> --- a/xen/arch/x86/hvm/hypercall.c
>> +++ b/xen/arch/x86/hvm/hypercall.c
>> @@ -74,6 +74,8 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
>> arg)
>>      {
>>      case PHYSDEVOP_map_pirq:
>>      case PHYSDEVOP_unmap_pirq:
>> +        break;
> 
> I think this could do with a comment as to why it's permitted as well as 
> giving
> a reference to where further restrictions are enforced (or simply mentioning
> the constraint of this only being permitted for management of other domains).
Thanks, will add
/* 
  * Only being permitted for management of other domains.
  * Further restrictions are enforced in do_physdev_op.
  */

> 
>> --- a/xen/arch/x86/physdev.c
>> +++ b/xen/arch/x86/physdev.c
>> @@ -305,11 +305,23 @@ ret_t do_physdev_op(int cmd, 
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>      case PHYSDEVOP_map_pirq: {
>>          physdev_map_pirq_t map;
>>          struct msi_info msi;
>> +        struct domain *d;
>>  
>>          ret = -EFAULT;
>>          if ( copy_from_guest(&map, arg, 1) != 0 )
>>              break;
>>  
>> +        d = rcu_lock_domain_by_any_id(map.domid);
>> +        if ( d == NULL )
>> +            return -ESRCH;
>> +        /* If caller is the same HVM guest as current, check pirq flag */
> 
> The caller is always current. What I think you mean is "caller is same as
> the subject domain". 
Yes, I want to prevent self-map when subject domain(domU) doesn't have 
X86_EMU_USE_PIRQ flag.

> I'm also having trouble with seeing the usefulness of saying "check pirq 
> flag". Instead I think you want to state the
> restriction here that you actually mean to enforce (which would also mean
> mentioning PVH in some way, to distinguish from the "normal HVM" case).
Yes, PVH and the HVM without X86_EMU_USE_PIRQ flag,
If a HVM has X86_EMU_USE_PIRQ flag, map_pirq should be permitted.

I will change this comment to be:
/* Prevent self-map when domain has no X86_EMU_USE_PIRQ flag */

> 
>> +        if ( !is_pv_domain(d) && !has_pirq(d) && map.domid == DOMID_SELF )
> 
> You exclude DOMID_SELF but not the domain's ID? Why not simply check d
> being current->domain, thus covering both cases? 
> Plus you could use rcu_lock_domain_by_id() to exclude DOMID_SELF, and you 
> could use
> rcu_lock_remote_domain_by_id() to exclude the local domain altogether.
But there is a case that hvm hold PIRQ flag and DOMID_SELF id will do this 
pirq_map, see code
physdev_map_pirq.
I think change to check d being current->domain is more suitable.

> Finally I'm not even sure you need the RCU lock here (else you could
> use knownalive_domain_from_domid()). But perhaps that's better to cover
> the qemu-in-stubdom case, which we have to consider potentially malicious.
Yes, for potential safety reasons, let's keep the RCU lock.

> 
> I'm also inclined to suggest to use is_hvm_domain() here in favor of
> !is_pv_domain().
OK, will change to is_hvm_domain in next version.

> 
> Jan

-- 
Best regards,
Jiqian Chen.

 


Rackspace

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