| Message ID | c958f3776e602143efb2fb7c146a0c18a3fcd262.1587490511.git.tamas.lengyel@intel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | VM forking | expand |
On Tue, Apr 21, 2020 at 10:47:24AM -0700, Tamas K Lengyel wrote: > The memory sharing subsystem by default doesn't allow a domain to share memory > if it has an IOMMU active for obvious security reasons. However, when fuzzing a > VM fork, the same security restrictions don't necessarily apply. While it makes > no sense to try to create a full fork of a VM that has an IOMMU attached as only > one domain can own the pass-through device at a time, creating a shallow fork > without a device model is still very useful for fuzzing kernel-mode drivers. > > By allowing the parent VM to initialize the kernel-mode driver with a real > device that's pass-through, the driver can enter into a state more suitable for > fuzzing. Some of these initialization steps are quite complex and are easier to > perform when a real device is present. After the initialization, shallow forks > can be utilized for fuzzing code-segments in the device driver that don't > directly interact with the device. > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Thanks.
On Wed, Apr 22, 2020 at 3:09 AM Roger Pau Monné <roger.pau@citrix.com> wrote: > > On Tue, Apr 21, 2020 at 10:47:24AM -0700, Tamas K Lengyel wrote: > > The memory sharing subsystem by default doesn't allow a domain to share memory > > if it has an IOMMU active for obvious security reasons. However, when fuzzing a > > VM fork, the same security restrictions don't necessarily apply. While it makes > > no sense to try to create a full fork of a VM that has an IOMMU attached as only > > one domain can own the pass-through device at a time, creating a shallow fork > > without a device model is still very useful for fuzzing kernel-mode drivers. > > > > By allowing the parent VM to initialize the kernel-mode driver with a real > > device that's pass-through, the driver can enter into a state more suitable for > > fuzzing. Some of these initialization steps are quite complex and are easier to > > perform when a real device is present. After the initialization, shallow forks > > can be utilized for fuzzing code-segments in the device driver that don't > > directly interact with the device. > > > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com> > > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Thanks! This can be merged independent of the other patches in the series. Tamas
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c index d8ed660abb..e690d2fa13 100644 --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -1445,7 +1445,8 @@ static int range_share(struct domain *d, struct domain *cd, return rc; } -static inline int mem_sharing_control(struct domain *d, bool enable) +static inline int mem_sharing_control(struct domain *d, bool enable, + uint16_t flags) { if ( enable ) { @@ -1455,7 +1456,8 @@ static inline int mem_sharing_control(struct domain *d, bool enable) if ( unlikely(!hap_enabled(d)) ) return -ENODEV; - if ( unlikely(is_iommu_enabled(d)) ) + if ( unlikely(is_iommu_enabled(d) && + !(flags & XENMEM_FORK_WITH_IOMMU_ALLOWED)) ) return -EXDEV; } @@ -1848,7 +1850,8 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg) if ( rc ) goto out; - if ( !mem_sharing_enabled(d) && (rc = mem_sharing_control(d, true)) ) + if ( !mem_sharing_enabled(d) && + (rc = mem_sharing_control(d, true, 0)) ) return rc; switch ( mso.op ) @@ -2086,7 +2089,9 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg) struct domain *pd; rc = -EINVAL; - if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] || mso.u.fork.pad[2] ) + if ( mso.u.fork.pad ) + goto out; + if ( mso.u.fork.flags & ~XENMEM_FORK_WITH_IOMMU_ALLOWED ) goto out; rc = rcu_lock_live_remote_domain_by_id(mso.u.fork.parent_domain, @@ -2101,7 +2106,8 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg) goto out; } - if ( !mem_sharing_enabled(pd) && (rc = mem_sharing_control(pd, true)) ) + if ( !mem_sharing_enabled(pd) && + (rc = mem_sharing_control(pd, true, mso.u.fork.flags)) ) { rcu_unlock_domain(pd); goto out; @@ -2122,7 +2128,7 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg) struct domain *pd; rc = -EINVAL; - if ( mso.u.fork.pad[0] || mso.u.fork.pad[1] || mso.u.fork.pad[2] ) + if ( mso.u.fork.pad || mso.u.fork.flags ) goto out; rc = -ENOSYS; @@ -2159,7 +2165,7 @@ int mem_sharing_domctl(struct domain *d, struct xen_domctl_mem_sharing_op *mec) switch ( mec->op ) { case XEN_DOMCTL_MEM_SHARING_CONTROL: - rc = mem_sharing_control(d, mec->u.enable); + rc = mem_sharing_control(d, mec->u.enable, 0); break; default: diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index d36d64b8dc..e56800357d 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -536,7 +536,9 @@ struct xen_mem_sharing_op { } debug; struct mem_sharing_op_fork { /* OP_FORK */ domid_t parent_domain; /* IN: parent's domain id */ - uint16_t pad[3]; /* Must be set to 0 */ +#define XENMEM_FORK_WITH_IOMMU_ALLOWED (1u << 0) + uint16_t flags; /* IN: optional settings */ + uint32_t pad; /* Must be set to 0 */ } fork; } u; };
The memory sharing subsystem by default doesn't allow a domain to share memory if it has an IOMMU active for obvious security reasons. However, when fuzzing a VM fork, the same security restrictions don't necessarily apply. While it makes no sense to try to create a full fork of a VM that has an IOMMU attached as only one domain can own the pass-through device at a time, creating a shallow fork without a device model is still very useful for fuzzing kernel-mode drivers. By allowing the parent VM to initialize the kernel-mode driver with a real device that's pass-through, the driver can enter into a state more suitable for fuzzing. Some of these initialization steps are quite complex and are easier to perform when a real device is present. After the initialization, shallow forks can be utilized for fuzzing code-segments in the device driver that don't directly interact with the device. Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com> --- v16: Minor fixes based on feedback --- xen/arch/x86/mm/mem_sharing.c | 20 +++++++++++++------- xen/include/public/memory.h | 4 +++- 2 files changed, 16 insertions(+), 8 deletions(-)