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

Re: [PATCH for-4.15 v2] xen/dmop: Strip __XEN_TOOLS__ header guard from public API


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Paul Durrant <paul@xxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Wed, 10 Mar 2021 17:22:39 +0000
  • 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-SenderADCheck; bh=l/GN8YxH78Q+enrgfjv7pEctB1xoozBobcdx1vlh3ek=; b=NivRnMVQN9qfn8SjAw32HT1vwAtZ62zbl3qbvARtKr6NAcY5wQ6+MKJOjF8hGAxNOptLvdnU8HAPxtEAKdTnyuo2YQGMDjYjiUZNnoYJWIEGKvThB3HvpWw1UB9iHz2hwUgQwkqsZm2r+NK+EPSWTPq2BJJge8frPla9vtdpHXuzDcO50Gta1Kjy/xQgJ4PDcDnw7oclNx7u/UK5YVRCleKWyIG5tO0dopVzIrqhItI0LE0y6+E2EG5lJke/mbcLIWDlznj6QH8HXo8pjx13HGn4Cj9Evghgb/fmTtNKkE9PNtOaxQBhOcFc69aBbH5nw9odJZpN7KoNPcI3rlOM8g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fO5rKa0x1EfYYttfR/akf7wHqFFx8KjLaUP0FtpFmBpvUywGyFXoAlMTs2xGNcsd+WtyscHt2OgVqF4IkSXS6B2zMUI9G5p8zANGNhjdUO/OregpM7Z7/ja9DvEHy2CyHqytWEyJ/OOEj/5dqb/yn9mSHIyULbGpI6ulRTcb377Ycjkcmt8AFcEY60nbUQbbuowsHPGn7Dhz9UuwOTS+ko2X1dJZ1xnraMolKtsTqF/JPB6uHzDLaUCasSuFojKogva+1NpGDCosPO//vlzYZsS72cry1JmoPTQMBKNNwAeEC/cfZkVzvslIh8MIombbFaVvW/27lIyjXh/rq9GIww==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 10 Mar 2021 17:23:09 +0000
  • Ironport-hdrordr: A9a23:ZwijdKjIa7GqMkM/c1cRYIkaknBQXwB13DAbvn1ZSRFFG/Gwv9 yynfgdyB//gCsQXnZlotybJKycWxrnmKJdy48XILukQU3aqHKlRbsSiLfK7h/BP2nF9uBb3b p9aKQWMrfNJHVzkMqS2maFOvk6xt3vys6VrMP/61socg1wcaFn6G5Ce2SmO2l7XhNPC5Z8NL f03Kp6jgGtc3gWcci3b0NtN4T+jubGiY78Zlo+DwMngTPksRqT9LX4HxKEty1uMA9n/LFKyw n4uj283IqPmbWRyhjQ12jchq4m4ufJ+594K+GnzuQQIjXooA60aIpmQK3qhkFJnMifrGwEvf OJjxA8P9liy365RBDInTLdnzPO/Rxry3j+xUSWiXHuyPaJOw4SOo56qq9yNj76gnBQ2O1U4e Zw8E+y86dzN1fmmh/w4tDZPisa7nackD4ZvsM4y0BEXZB2Us43kaUvuHl7Pb0nByzA5IUuAI BVfbrhzccTS1+cYnzD11MfpuCEbzA2FheCdEAIptaY5ThQhGx41EsV3qUk7w49yK4=
  • Ironport-sdr: /mNcPxlxtqBGbbq4mEkC1hXStTRa5vploDomN314OkC5ssLJmdkV9I18TY13BXMzr0tJdZxG1E bwV1Y3ImbBIOP9AZkCFSp1F4S39ks0bLD0jsYeR0DnhDrnCi2Y0C+DXk1O94w8tuRPSkDn73+/ uIT3u4a2Njlql89vQ0g8gVY3U3Yib6waSjhdqLWIirgIjtAbCqTbqg092/kKPhZ3rmY3MjL/HV XAuqka13+IekiWj76hST92V7WjUDG/L8E2WGCN5KK98KImj/OpLWEtRHHii6znT+afNI4Px2uL 21w=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10/03/2021 17:12, Jan Beulich wrote:
> On 10.03.2021 16:07, Andrew Cooper wrote:
>> --- a/docs/designs/dmop.pandoc
>> +++ b/docs/designs/dmop.pandoc
>> @@ -4,9 +4,13 @@ DMOP
>>  Introduction
>>  ------------
>>  
>> -The aim of DMOP is to prevent a compromised device model from compromising
>> -domains other than the one it is providing emulation for (which is therefore
>> -likely already compromised).
>> +The DMOP hypercall has a new ABI design to solve problems in the Xen
>> +ecosystem.  First, the ABI is fully stable, to reduce the coupling between
>> +device models and the version of Xen.
>> +
>> +Secondly, for device models in userspace, the ABI is designed specifically 
>> to
>> +allow a kernel to audit the memory ranges used, without having to know the
>> +internal structure of sub-ops.
> I appreciate the editing, but the cited points still don't justify ...
>
>> --- a/xen/include/public/hvm/dm_op.h
>> +++ b/xen/include/public/hvm/dm_op.h
>> @@ -25,9 +25,6 @@
>>  #define __XEN_PUBLIC_HVM_DM_OP_H__
>>  
>>  #include "../xen.h"
>> -
>> -#if defined(__XEN__) || defined(__XEN_TOOLS__)
>> -
>>  #include "../event_channel.h"
>>  
>>  #ifndef uint64_aligned_t
>> @@ -491,8 +488,6 @@ struct xen_dm_op {
>>      } u;
>>  };
>>  
>> -#endif /* __XEN__ || __XEN_TOOLS__ */
>> -
>>  struct xen_dm_op_buf {
>>      XEN_GUEST_HANDLE(void) h;
>>      xen_ulong_t size;
> ... this removal: What the kernel needs for its auditing (your 2nd
> point) is already outside of this guarded region, as you can see
> from the context above. You said there was a design goal of allowing
> use of this interface by (and not only through) the kernel, e.g. by
> a kernel module (which I don't think you mean to be covered by
> "device models"). If that was indeed a goal (Paul - can you confirm
> this?), this would now want listing as a 3rd item. Without such a
> statement I'd call it a bug to not have the guards there, and hence
> might either feel tempted myself to add them back at some point, or
> would ack a patch doing so.

Xen has absolutely no business dictating stuff like this.  It is an
internal and opaque property of the domain if the hypercalls happen to
originate from logic in user mode or kernel mode.  Stubdomains would
fall into the same "kernel" category as xengt in the dom0 i915 driver.

However, the actual bug I'm trying to fix with this is the need for
userspace, which doesn't link against libxc, to do

#define __XEN_TOOLS__
#include <xendevicemodel.h>

to be able to use the libxendevicemodel stable library.

The __XEN_TOOLS__ guard is buggy even ignoring the kernel device model
aspect.

~Andrew




 


Rackspace

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