* [Xen-devel] Xen Security Advisory 306 v3 (CVE-2019-19579) - Device quarantine for alternate pci assignment methods
@ 2019-12-05 14:21 Xen.org security team
0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2019-12-05 14:21 UTC (permalink / raw)
To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team
[-- Attachment #1: Type: text/plain, Size: 4573 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2019-19579 / XSA-306
version 3
Device quarantine for alternate pci assignment methods
UPDATES IN VERSION 3
====================
CVE assigned.
ISSUE DESCRIPTION
=================
XSA-302 relies on the use of libxl's "assignable-add" feature to
prepare devices to be assigned to untrusted guests.
Unfortunately, this is not considered a strictly required step for
device assignment. The PCI passthrough documentation on the wiki
describes alternate ways of preparing devices for assignment, and
libvirt uses its own ways as well. Hosts where these "alternate"
methods are used will still leave the system in a vulnerable state
after the device comes back from a guest.
IMPACT
======
An untrusted domain with access to a physical device can DMA into host
memory, leading to privilege escalation.
VULNERABLE SYSTEMS
==================
Only systems where guests are given direct access to physical devices
capable of DMA (PCI pass-through) are vulnerable. Systems which do
not use PCI pass-through are not vulnerable.
Only systems which use "alternate" methods to assign devices to pciback
before assignment are vulnerable. These methods include:
- Assigning devices on the Linux command-line using `xen-pciback.hide`
- Assigning devices via xen-pciback module parameters
- Assigning devices manually via sysfs
- Assigning devices using libvirt
Systems which use `xl pci-assignable-add` or
libxl_device_pci_assignable_add, or have the assignable state handled
automatically via setting the `seize` parameter, are not affected.
MITIGATION
==========
For xl and libvirt, before assigning a device to a guest, manually run
`xl pci-assignable-add`. This will quarantine the device even if the
device has already been assigned to pciback by one of the alternate
methods. This may also work for other libxl-based toolstacks,
depending on the particular implementation.
CREDITS
=======
This issue was discovered by Marek Marczykowski-Górecki of Invisible
Things Lab.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
Note that this patch will quarantine the device after the domain is
destroyed by default. It must be un-quarantined before it can be used
by domain 0 again. This can be done by executing `xl
pci-assignable-remove`. This will be effective even if the device was
assigned to pciback with one of the alternate methods.
xsa306.patch xen-unstable
xsa306-4.12.patch Xen 4.12.x
xsa306-4.11.patch Xen 4.11.x, Xen 4.10.x
xsa306-4.9.patch Xen 4.9.x, Xen 4.8.x
$ sha256sum xsa306*
07468dcdfbe34b794fd0618bce7d6d1edb6b10b234dccf1e5dd1f1120a0affe7 xsa306.meta
3534ec46f03bb8dac3011e0e3739fc75400559078e4361bbe5385d97b7892650 xsa306.patch
426e32bfa7d7787fe6778685e623966f8762857f7920443a0ca73347df9d6624 xsa306-4.9.patch
b00e58c9f96b0ff654dfd4904c675a54356148af718eb9b2adca0253b900dfc1 xsa306-4.11.patch
69857d08969903452fbf009905a145e06a5aef9966e969de9fbb22e62c557ffd xsa306-4.12.patch
$
DEPLOYMENT DURING EMBARGO
=========================
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl3pEgkMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZawYIAJ1rXxormDa8TB3hgabjaFGEBtEptWEf0eI/zqxJ
AC0l9TIdXSkcv2ZBFjxx3YDHetC8MjloBZOP84blVWH+Y9voOvDQPf2Q2AHEoHm7
KwEBFox8eyy0H1mKuhda+QqxO7XEuGUn0a0kxHiO1HMg7xY4FmxYv51E3B17ytAD
TyDOsJq3MevQg+GNPwranDPS7UtpYKFBqEEf63KsA9bU5OS+BaAijRQ379qwh//8
bpWoEFBPRWK6Pf46iSlhifnTUDZiAVOSAxolH3b1UZKOWFaVIrLOpY49QLFg5zfC
yhvCgVumONdyIX+x35kGuIDvYFbrEswFPmrn0pmXtdKyBEI=
=8lme
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa306.meta --]
[-- Type: application/octet-stream, Size: 1561 bytes --]
{
"XSA": 306,
"SupportedVersions": [
"master",
"4.12",
"4.11",
"4.10",
"4.9",
"4.8"
],
"Trees": [
"xen"
],
"Recipes": {
"4.10": {
"Recipes": {
"xen": {
"StableRef": "1da3dab86cf219c179a23a0518021ab601d08661",
"Prereqs": [],
"Patches": [
"xsa306-4.11.patch"
]
}
}
},
"4.11": {
"Recipes": {
"xen": {
"StableRef": "006b2041242129896fbd30135b3dc6f575894a07",
"Prereqs": [],
"Patches": [
"xsa306-4.11.patch"
]
}
}
},
"4.12": {
"Recipes": {
"xen": {
"StableRef": "278e46ae8f99485915ae662e7905c8333a55048a",
"Prereqs": [],
"Patches": [
"xsa306-4.12.patch"
]
}
}
},
"4.8": {
"Recipes": {
"xen": {
"StableRef": "80e67e435fc1f730c123eb475f9a7de9210b54c3",
"Prereqs": [],
"Patches": [
"xsa306-4.9.patch"
]
}
}
},
"4.9": {
"Recipes": {
"xen": {
"StableRef": "8c52ee2679f24e6281de93ad68683edcad7ef3ce",
"Prereqs": [],
"Patches": [
"xsa306-4.9.patch"
]
}
}
},
"master": {
"Recipes": {
"xen": {
"StableRef": "3683290fc0b0d6500392db733811cc78bcb35eab",
"Prereqs": [],
"Patches": [
"xsa306.patch"
]
}
}
}
}
}
[-- Attachment #3: xsa306.patch --]
[-- Type: application/octet-stream, Size: 4180 bytes --]
From: Jan Beulich <jbeulich@suse.com>
Subject: IOMMU: default to always quarantining PCI devices
XSA-302 relies on the use of libxl's "assignable-add" feature to prepare
devices to be assigned to untrusted guests.
Unfortunately, this is not considered a strictly required step for
device assignment. The PCI passthrough documentation on the wiki
describes alternate ways of preparing devices for assignment, and
libvirt uses its own ways as well. Hosts where these alternate methods
are used will still leave the system in a vulnerable state after the
device comes back from a guest.
Default to always quarantining PCI devices, but provide a command line
option to revert back to prior behavior (such that people who both
sufficiently trust their guests and want to be able to use devices in
Dom0 again after they had been in use by a guest wouldn't need to
"manually" move such devices back from DomIO to Dom0).
This is XSA-306.
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>
---
v3: Adjust command line doc.
v2: Adjust description.
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1194,7 +1194,7 @@ detection of systems known to misbehave
> Default: `new` unless directed-EOI is supported
### iommu
- = List of [ <bool>, verbose, debug, force, required,
+ = List of [ <bool>, verbose, debug, force, required, quarantine,
sharept, intremap, intpost, crash-disable,
snoop, qinval, igfx, amd-iommu-perdev-intremap,
dom0-{passthrough,strict} ]
@@ -1232,6 +1232,12 @@ 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
+ 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.
+
* The `sharept` boolean controls whether the IOMMU pagetables are shared
with the CPU-side HAP pagetables, or allocated separately. Sharing
reduces the memory overhead, but doesn't work in combination with CPU-side
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -30,6 +30,7 @@ bool_t __initdata iommu_enable = 1;
bool_t __read_mostly iommu_enabled;
bool_t __read_mostly force_iommu;
bool_t __read_mostly iommu_verbose;
+bool __read_mostly iommu_quarantine = true;
bool_t __read_mostly iommu_igfx = 1;
bool_t __read_mostly iommu_snoop = 1;
bool_t __read_mostly iommu_qinval = 1;
@@ -78,6 +79,8 @@ static int __init parse_iommu_param(cons
else if ( (val = parse_boolean("force", s, ss)) >= 0 ||
(val = parse_boolean("required", s, ss)) >= 0 )
force_iommu = val;
+ else if ( (val = parse_boolean("quarantine", s, ss)) >= 0 )
+ iommu_quarantine = val;
else if ( (val = parse_boolean("igfx", s, ss)) >= 0 )
iommu_igfx = val;
else if ( (val = parse_boolean("verbose", s, ss)) >= 0 )
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -922,7 +922,8 @@ static int deassign_device(struct domain
return -ENODEV;
/* De-assignment from dom_io should de-quarantine the device */
- target = (pdev->quarantine && pdev->domain != dom_io) ?
+ target = ((pdev->quarantine || iommu_quarantine) &&
+ pdev->domain != dom_io) ?
dom_io : hardware_domain;
while ( pdev->phantom_stride )
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -53,7 +53,7 @@ static inline bool_t dfn_eq(dfn_t x, dfn
}
extern bool_t iommu_enable, iommu_enabled;
-extern bool_t force_iommu, iommu_verbose, iommu_igfx;
+extern bool force_iommu, iommu_quarantine, iommu_verbose, iommu_igfx;
extern bool_t iommu_snoop, iommu_qinval, iommu_intremap, iommu_intpost;
#if defined(CONFIG_IOMMU_FORCE_PT_SHARE)
[-- Attachment #4: xsa306-4.9.patch --]
[-- Type: application/octet-stream, Size: 3987 bytes --]
From: Jan Beulich <jbeulich@suse.com>
Subject: IOMMU: default to always quarantining PCI devices
XSA-302 relies on the use of libxl's "assignable-add" feature to prepare
devices to be assigned to untrusted guests.
Unfortunately, this is not considered a strictly required step for
device assignment. The PCI passthrough documentation on the wiki
describes alternate ways of preparing devices for assignment, and
libvirt uses its own ways as well. Hosts where these alternate methods
are used will still leave the system in a vulnerable state after the
device comes back from a guest.
Default to always quarantining PCI devices, but provide a command line
option to revert back to prior behavior (such that people who both
sufficiently trust their guests and want to be able to use devices in
Dom0 again after they had been in use by a guest wouldn't need to
"manually" move such devices back from DomIO to Dom0).
This is XSA-306.
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1043,7 +1043,7 @@ debug hypervisor only).
> Default: `new` unless directed-EOI is supported
### iommu
-> `= List of [ <boolean> | force | required | intremap | intpost | qinval | snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | workaround_bios_bug | igfx | verbose | debug ]`
+> `= List of [ <boolean> | force | required | quarantine | intremap | intpost | qinval | snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | workaround_bios_bug | igfx | verbose | debug ]`
> Sub-options:
@@ -1063,6 +1063,15 @@ debug hypervisor only).
>> Don't continue booting unless IOMMU support is found and can be initialized
>> successfully.
+> `quarantine`
+
+> Default: `true`
+
+>> Control Xen's behavior when de-assigning devices from guests. If enabled,
+>> 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.
+
> `intremap`
> Default: `true`
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -52,6 +52,7 @@ custom_param("iommu", parse_iommu_param)
bool_t __initdata iommu_enable = 1;
bool_t __read_mostly iommu_enabled;
bool_t __read_mostly force_iommu;
+bool __read_mostly iommu_quarantine = true;
bool_t __hwdom_initdata iommu_dom0_strict;
bool_t __read_mostly iommu_verbose;
bool_t __read_mostly iommu_workaround_bios_bug;
@@ -96,6 +97,8 @@ static void __init parse_iommu_param(cha
iommu_enable = 0;
else if ( !strcmp(s, "force") || !strcmp(s, "required") )
force_iommu = val;
+ else if ( !strcmp(s, "quarantine") )
+ iommu_quarantine = val;
else if ( !strcmp(s, "workaround_bios_bug") )
iommu_workaround_bios_bug = val;
else if ( !strcmp(s, "igfx") )
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1460,7 +1460,8 @@ int deassign_device(struct domain *d, u1
return -ENODEV;
/* De-assignment from dom_io should de-quarantine the device */
- target = (pdev->quarantine && pdev->domain != dom_io) ?
+ target = ((pdev->quarantine || iommu_quarantine) &&
+ pdev->domain != dom_io) ?
dom_io : hardware_domain;
while ( pdev->phantom_stride )
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -28,7 +28,7 @@
#include <asm/iommu.h>
extern bool_t iommu_enable, iommu_enabled;
-extern bool_t force_iommu, iommu_verbose;
+extern bool force_iommu, iommu_quarantine, iommu_verbose;
extern bool_t iommu_workaround_bios_bug, iommu_igfx, iommu_passthrough;
extern bool_t iommu_snoop, iommu_qinval, iommu_intremap, iommu_intpost;
extern bool_t iommu_hap_pt_share;
[-- Attachment #5: xsa306-4.11.patch --]
[-- Type: application/octet-stream, Size: 4080 bytes --]
From: Jan Beulich <jbeulich@suse.com>
Subject: IOMMU: default to always quarantining PCI devices
XSA-302 relies on the use of libxl's "assignable-add" feature to prepare
devices to be assigned to untrusted guests.
Unfortunately, this is not considered a strictly required step for
device assignment. The PCI passthrough documentation on the wiki
describes alternate ways of preparing devices for assignment, and
libvirt uses its own ways as well. Hosts where these alternate methods
are used will still leave the system in a vulnerable state after the
device comes back from a guest.
Default to always quarantining PCI devices, but provide a command line
option to revert back to prior behavior (such that people who both
sufficiently trust their guests and want to be able to use devices in
Dom0 again after they had been in use by a guest wouldn't need to
"manually" move such devices back from DomIO to Dom0).
This is XSA-306.
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1112,7 +1112,7 @@ detection of systems known to misbehave
> Default: `new` unless directed-EOI is supported
### iommu
-> `= List of [ <boolean> | force | required | intremap | intpost | qinval | snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | workaround_bios_bug | igfx | crash-disable | verbose | debug ]`
+> `= List of [ <boolean> | force | required | quarantine | intremap | intpost | qinval | snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | workaround_bios_bug | igfx | crash-disable | verbose | debug ]`
> Sub-options:
@@ -1132,6 +1132,15 @@ detection of systems known to misbehave
>> Don't continue booting unless IOMMU support is found and can be initialized
>> successfully.
+> `quarantine`
+
+> Default: `true`
+
+>> Control Xen's behavior when de-assigning devices from guests. If enabled,
+>> 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.
+
> `intremap`
> Default: `true`
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -52,6 +52,7 @@ custom_param("iommu", parse_iommu_param)
bool_t __initdata iommu_enable = 1;
bool_t __read_mostly iommu_enabled;
bool_t __read_mostly force_iommu;
+bool __read_mostly iommu_quarantine = true;
bool_t __hwdom_initdata iommu_dom0_strict;
bool_t __read_mostly iommu_verbose;
bool_t __read_mostly iommu_workaround_bios_bug;
@@ -99,6 +100,8 @@ static int __init parse_iommu_param(cons
else if ( !cmdline_strcmp(s, "force") ||
!cmdline_strcmp(s, "required") )
force_iommu = val;
+ else if ( !cmdline_strcmp(s, "quarantine") )
+ iommu_quarantine = val;
else if ( !cmdline_strcmp(s, "workaround_bios_bug") )
iommu_workaround_bios_bug = val;
else if ( !cmdline_strcmp(s, "igfx") )
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1511,7 +1511,8 @@ int deassign_device(struct domain *d, u1
return -ENODEV;
/* De-assignment from dom_io should de-quarantine the device */
- target = (pdev->quarantine && pdev->domain != dom_io) ?
+ target = ((pdev->quarantine || iommu_quarantine) &&
+ pdev->domain != dom_io) ?
dom_io : hardware_domain;
while ( pdev->phantom_stride )
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -29,7 +29,7 @@
#include <asm/iommu.h>
extern bool_t iommu_enable, iommu_enabled;
-extern bool_t force_iommu, iommu_verbose;
+extern bool force_iommu, iommu_quarantine, iommu_verbose;
extern bool_t iommu_workaround_bios_bug, iommu_igfx, iommu_passthrough;
extern bool_t iommu_snoop, iommu_qinval, iommu_intremap, iommu_intpost;
extern bool_t iommu_hap_pt_share;
[-- Attachment #6: xsa306-4.12.patch --]
[-- Type: application/octet-stream, Size: 4144 bytes --]
From: Jan Beulich <jbeulich@suse.com>
Subject: IOMMU: default to always quarantining PCI devices
XSA-302 relies on the use of libxl's "assignable-add" feature to prepare
devices to be assigned to untrusted guests.
Unfortunately, this is not considered a strictly required step for
device assignment. The PCI passthrough documentation on the wiki
describes alternate ways of preparing devices for assignment, and
libvirt uses its own ways as well. Hosts where these alternate methods
are used will still leave the system in a vulnerable state after the
device comes back from a guest.
Default to always quarantining PCI devices, but provide a command line
option to revert back to prior behavior (such that people who both
sufficiently trust their guests and want to be able to use devices in
Dom0 again after they had been in use by a guest wouldn't need to
"manually" move such devices back from DomIO to Dom0).
This is XSA-306.
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1171,7 +1171,7 @@ detection of systems known to misbehave
> Default: `new` unless directed-EOI is supported
### iommu
- = List of [ <bool>, verbose, debug, force, required,
+ = List of [ <bool>, verbose, debug, force, required, quarantine,
sharept, intremap, intpost, crash-disable,
snoop, qinval, igfx, amd-iommu-perdev-intremap,
dom0-{passthrough,strict} ]
@@ -1209,6 +1209,12 @@ 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
+ 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.
+
* The `sharept` boolean controls whether the IOMMU pagetables are shared
with the CPU-side HAP pagetables, or allocated separately. Sharing
reduces the memory overhead, but doesn't work in combination with CPU-side
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -30,6 +30,7 @@ bool_t __initdata iommu_enable = 1;
bool_t __read_mostly iommu_enabled;
bool_t __read_mostly force_iommu;
bool_t __read_mostly iommu_verbose;
+bool __read_mostly iommu_quarantine = true;
bool_t __read_mostly iommu_igfx = 1;
bool_t __read_mostly iommu_snoop = 1;
bool_t __read_mostly iommu_qinval = 1;
@@ -74,6 +75,8 @@ static int __init parse_iommu_param(cons
else if ( (val = parse_boolean("force", s, ss)) >= 0 ||
(val = parse_boolean("required", s, ss)) >= 0 )
force_iommu = val;
+ else if ( (val = parse_boolean("quarantine", s, ss)) >= 0 )
+ iommu_quarantine = val;
else if ( (val = parse_boolean("igfx", s, ss)) >= 0 )
iommu_igfx = val;
else if ( (val = parse_boolean("verbose", s, ss)) >= 0 )
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1548,7 +1548,8 @@ int deassign_device(struct domain *d, u1
return -ENODEV;
/* De-assignment from dom_io should de-quarantine the device */
- target = (pdev->quarantine && pdev->domain != dom_io) ?
+ target = ((pdev->quarantine || iommu_quarantine) &&
+ pdev->domain != dom_io) ?
dom_io : hardware_domain;
while ( pdev->phantom_stride )
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -53,7 +53,7 @@ static inline bool_t dfn_eq(dfn_t x, dfn
}
extern bool_t iommu_enable, iommu_enabled;
-extern bool_t force_iommu, iommu_verbose, iommu_igfx;
+extern bool force_iommu, iommu_quarantine, iommu_verbose, iommu_igfx;
extern bool_t iommu_snoop, iommu_qinval, iommu_intremap, iommu_intpost;
extern bool_t iommu_hap_pt_share;
extern bool_t iommu_debug;
[-- Attachment #7: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2019-12-05 14:44 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-05 14:21 [Xen-devel] Xen Security Advisory 306 v3 (CVE-2019-19579) - Device quarantine for alternate pci assignment methods Xen.org security team
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).