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

RE: [PATCH v4] IOMMU: make DMA containment of quarantined devices optional


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Mon, 30 Nov 2020 08:05:00 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.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=TSRI63inD66yhT2lieGsWekufNP7pjGEqdM9WiLQXJM=; b=QIVhH9WEOu/fbqytAtIVKc/BIDtu3mh5CQNKu1w/wh5LUZoskOgmE8jovhp7GNhVCpV1+v7EOuQ9ATqNqrppaw/BOGIGJe7kOZ95/ej3etlK/W9iMguPOtj2Dt/llXBxC8bL3gyYeA0NOdgcpsyDisTFqUUWfGzkqNxPY1V/s4ilzcBfRjeSWsAeGiPLCFdFZT8xgTU8uhkXv8jLsRcqAtwzHCoumhVGVb8KZQgLqZhs0wPjgRNjXmmoMvnInqG6Go44F7A4BA6KLqk04oFx++VEON9T1XNy/2JyqzdHIZcruN8lQUENrHqHhEynrjrK8gMp+XgfF4uFegGJsXanbw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WTMZ1WUCfmm94ovKo5W2Qb3v4lvRYFsDWVWC2d0huDoYhQDEZeawfhCTC2a1qplm0YxroolK8+d40us2kO29NVeTCsHie45Ld8wXsVR/ff/TUBW2iARZNIiB3Y8EPi4iXlQH38LxiS/LjzGRjDjak9vGLaWHHAEWxSsSj0kwTdB6KE4zYrreTIjkePP0NN97aTgo/URjgwItTHRx+CVCIYqbMSbEYxIFIr75G8M0JnAKrsXouzCM5fGtibhK99W0atXk/7D3kLBblpLq+yqoigKIdBHv867/AOYOzGFqfxZRsYGMTUxtnC3sW8u32dAqfo//CcWf9oOsxi97bLuqow==
  • Authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=intel.com;
  • Cc: "Cooper, Andrew" <andrew.cooper3@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 30 Nov 2020 08:05:22 +0000
  • Dlp-product: dlpe-windows
  • Dlp-reaction: no-action
  • Dlp-version: 11.5.1.3
  • Ironport-sdr: zwIGe8/fX9a0M8tNyoPjkyJEN3yVL1qHl2WTfnXgpiZTINDrg6K0HhX96BNsFGyaDdXspJMVgl dLduDVTj6JXg==
  • Ironport-sdr: 0uvb9IOEpBYqk1ojjgpsZLhKIN8ww4jkZrKGXPIZUjrV3KVqtBkvRsrozRLIkgQUobJfj6UhhZ MDOQk4VWRKrQ==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWxNzT5+yOOE/aLkyGjNnv/rbw96ngL6OggAAdYYCAAAakUA==
  • Thread-topic: [PATCH v4] IOMMU: make DMA containment of quarantined devices optional

> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: Monday, November 30, 2020 3:35 PM
> 
> On 30.11.2020 07:13, Tian, Kevin wrote:
> >> From: Jan Beulich <jbeulich@xxxxxxxx>
> >> Sent: Saturday, November 28, 2020 12:46 AM
> >>
> >> @@ -1316,11 +1316,32 @@ boolean (e.g. `iommu=no`) can override t
> >>      will prevent Xen from booting if IOMMUs aren't discovered and
> enabled
> >>      successfully.
> >>
> >> -*   The `quarantine` boolean can be used to control Xen's behavior when
> >> -    de-assigning devices from guests.  If enabled (the default), Xen 
> >> always
> >> +*   The `quarantine` option can be used to control Xen's behavior when
> >> +    de-assigning devices from guests.
> >> +
> >> +    When a PCI device is assigned to an untrusted domain, it is possible
> >> +    for that domain to program the device to DMA to an arbitrary address.
> >> +    The IOMMU is used to protect the host from malicious DMA by making
> >> +    sure that the device addresses can only target memory assigned to the
> >> +    guest.  However, when the guest domain is torn down, assigning the
> >> +    device back to the hardware domain would allow any in-flight DMA to
> >> +    potentially target critical host data.  To avoid this, quarantining
> >> +    should be enabled.  Quarantining can be done in two ways: In its basic
> >> +    form, all in-flight DMA will simply be forced to encounter IOMMU
> >> +    faults.  Since there are systems where doing so can cause host lockup,
> >> +    an alternative form is available where writes to memory will be made
> >> +    fault, but reads will be directed to a dummy page.  The implication
> >> +    here is that such reads will go unnoticed, i.e. an admin may not
> >> +    become aware of the underlying problem.
> >> +
> >> +    Therefore, if this option is set to true (the default), Xen always
> >>      quarantines such devices; they must be explicitly assigned back to
> Dom0
> >> -    before they can be used there again.  If disabled, Xen will only
> >> -    quarantine devices the toolstack hass arranged for getting 
> >> quarantined.
> >> +    before they can be used there again.  If set to "scratch-page", still
> >> +    active DMA reads will additionally be directed to a "scratch" page.  
> >> If
> >> +    set to false, Xen will only quarantine devices the toolstack has
> arranged
> >> +    for getting quarantined.
> >
> > Here let's be clear about the quarantine policy when the quarantine
> > devices are arranged by toolstack. Based on this patch it is the 'basic'
> > form i.e. always getting IOMMU faults for such devices.
> 
> Well, the policy is always as chosen via command line. Therefore do
> you perhaps merely mean the default mode to be spelled out? This is
> already the case at the beginning of the 2nd paragraph.

When I read above paragraphs, it's clear about the enabled case where
two quarantine forms are available (basic vs. scratch-page) and how to
choose them, but it's not crystal clear about the disabled case which 
form is assumed for toolstack-managed devices, from an user p.o.v.

Thanks,
Kevin

 


Rackspace

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