linux-toradex.git/drivers/xen, branch v4.9.60

xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()

2017-11-02T08:49:13+00:00

commit 298d275d4d9bea3524ff4bc76678c140611d8a8d upstream.

In case gntdev_mmap() succeeds only partially in mapping grant pages
it will leave some vital information uninitialized needed later for
cleanup. This will lead to an out of bounds array access when unmapping
the already mapped pages.

So just initialize the data needed for unmapping the pages a little bit
earlier.

Reported-by: Arthur Borsboom 
Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman

swiotlb-xen: implement xen_swiotlb_dma_mmap callback

2017-10-05T07:44:05+00:00

commit 7e91c7df29b5e196de3dc6f086c8937973bd0b88 upstream.

This function creates userspace mapping for the DMA-coherent memory.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Andrii Anisov 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

xen: fix bio vec merging

2017-08-25T00:12:20+00:00

commit 462cdace790ac2ed6aad1b19c9c0af0143b6aab0 upstream.

The current test for bio vec merging is not fully accurate and can be
tricked into merging bios when certain grant combinations are used.
The result of these malicious bio merges is a bio that extends past
the memory page used by any of the originating bios.

Take into account the following scenario, where a guest creates two
grant references that point to the same mfn, ie: grant 1 -> mfn A,
grant 2 -> mfn A.

These references are then used in a PV block request, and mapped by
the backend domain, thus obtaining two different pfns that point to
the same mfn, pfn B -> mfn A, pfn C -> mfn A.

If those grants happen to be used in two consecutive sectors of a disk
IO operation becoming two different bios in the backend domain, the
checks in xen_biovec_phys_mergeable will succeed, because bfn1 == bfn2
(they both point to the same mfn). However due to the bio merging,
the backend domain will end up with a bio that expands past mfn A into
mfn A + 1.

Fix this by making sure the check in xen_biovec_phys_mergeable takes
into account the offset and the length of the bio, this basically
replicates whats done in __BIOVEC_PHYS_MERGEABLE using mfns (bus
addresses). While there also remove the usage of
__BIOVEC_PHYS_MERGEABLE, since that's already checked by the callers
of xen_biovec_phys_mergeable.

Reported-by: "Jan H. Schönherr" 
Signed-off-by: Roger Pau Monné 
Reviewed-by: Juergen Gross 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

Xen: ARM: Zero reserved fields of xatp before making hypervisor call

2017-08-07T01:59:47+00:00

[ Upstream commit 0b47a6bd1150f4846b1d61925a4cc5a96593a541 ]

Ensure all reserved fields of xatp are zero before making
hypervisor call to XEN in xen_map_device_mmio().
xenmem_add_to_physmap_one() in XEN fails the mapping request if
extra.res reserved field in xatp is not zero for XENMAPSPACE_dev_mmio
request.

Signed-off-by: Jiandi An 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xen/scsiback: Fix a TMR related use-after-free

2017-07-27T22:07:59+00:00

commit 9f4ab18ac51dc87345a9cbd2527e6acf7a0a9335 upstream.

scsiback_release_cmd() must not dereference se_cmd->se_tmr_req
because that memory is freed by target_free_cmd_mem() before
scsiback_release_cmd() is called. Fix this use-after-free by
inlining struct scsiback_tmr into struct vscsibk_pend.

Signed-off-by: Bart Van Assche 
Reviewed-by: Juergen Gross 
Cc: Christoph Hellwig 
Cc: Hannes Reinecke 
Cc: David Disseldorp 
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

swiotlb-xen: update dev_addr after swapping pages

2017-07-05T12:40:22+00:00

[ Upstream commit f1225ee4c8fcf09afaa199b8b1f0450f38b8cd11 ]

In xen_swiotlb_map_page and xen_swiotlb_map_sg_attrs, if the original
page is not suitable, we swap it for another page from the swiotlb
pool.

In these cases, we don't update the previously calculated dma address
for the page before calling xen_dma_map_page. Thus, we end up calling
xen_dma_map_page passing the wrong dev_addr, resulting in
xen_dma_map_page mistakenly assuming that the page is foreign when it is
local.

Fix the bug by updating dev_addr appropriately.

This change has no effect on x86, because xen_dma_map_page is a stub
there.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Pooya Keshavarzi 
Tested-by: Pooya Keshavarzi 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xen/privcmd: Support correctly 64KB page granularity when mapping memory

2017-06-14T13:05:58+00:00

commit 753c09b5652bb4fe53e2db648002ec64b32b8827 upstream.

Commit 5995a68 "xen/privcmd: Add support for Linux 64KB page granularity" did
not go far enough to support 64KB in mmap_batch_fn.

The variable 'nr' is the number of 4KB chunk to map. However, when Linux
is using 64KB page granularity the array of pages (vma->vm_private_data)
contain one page per 64KB. Fix it by incrementing st->index correctly.

Furthermore, st->va is not correctly incremented as PAGE_SIZE !=
XEN_PAGE_SIZE.

Fixes: 5995a68 ("xen/privcmd: Add support for Linux 64KB page granularity")
Reported-by: Feng Kan 
Signed-off-by: Julien Grall 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman

xen: Revert commits da72ff5bfcb0 and 72a9b186292d

2017-05-14T12:00:22+00:00

commit 84d582d236dc1f9085e741affc72e9ba061a67c2 upstream.

Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741)
established that commit 72a9b186292d ("xen: Remove event channel
notification through Xen PCI platform device") (and thus commit
da72ff5bfcb0 ("partially revert "xen: Remove event channel
notification through Xen PCI platform device"")) are unnecessary and,
in fact, prevent HVM guests from booting on Xen releases prior to 4.0

Therefore we revert both of those commits.

The summary of that discussion is below:

  Here is the brief summary of the current situation:

  Before the offending commit (72a9b186292):

  1) INTx does not work because of the reset_watches path.
  2) The reset_watches path is only taken if you have Xen > 4.0
  3) The Linux Kernel by default will use vector inject if the hypervisor
     support. So even INTx does not work no body running the kernel with
     Xen > 4.0 would notice. Unless he explicitly disabled this feature
     either in the kernel or in Xen (and this can only be disabled by
     modifying the code, not user-supported way to do it).

  After the offending commit (+ partial revert):

  1) INTx is no longer support for HVM (only for PV guests).
  2) Any HVM guest The kernel will not boot on Xen < 4.0 which does
     not have vector injection support. Since the only other mode
     supported is INTx which.

  So based on this summary, I think before commit (72a9b186292) we were
  in much better position from a user point of view.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 
Cc: Boris Ostrovsky 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x86@kernel.org
Cc: Konrad Rzeszutek Wilk 
Cc: Bjorn Helgaas 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Vitaly Kuznetsov 
Cc: Paul Gortmaker 
Cc: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: Anthony Liguori 
Cc: KarimAllah Ahmed 
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman

xen/acpi: upload PM state from init-domain to Xen

2017-03-30T07:41:26+00:00

commit 1914f0cd203c941bba72f9452c8290324f1ef3dc upstream.

This was broken in commit cd979883b9ed ("xen/acpi-processor:
fix enabling interrupts on syscore_resume"). do_suspend (from
xen/manage.c) and thus xen_resume_notifier never get called on
the initial-domain at resume (it is if running as guest.)

The rationale for the breaking change was that upload_pm_data()
potentially does blocking work in syscore_resume(). This patch
addresses the original issue by scheduling upload_pm_data() to
execute in workqueue context.

Cc: Stanislaw Gruszka 
Based-on-patch-by: Konrad Wilk 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Stanislaw Gruszka 
Signed-off-by: Ankur Arora 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman

swiotlb: Convert swiotlb_force from int to enum

2017-01-26T07:24:44+00:00

commit ae7871be189cb41184f1e05742b4a99e2c59774d upstream.

Convert the flag swiotlb_force from an int to an enum, to prepare for
the advent of more possible values.

Suggested-by: Konrad Rzeszutek Wilk 
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman