linux-stable.git/include/linux/dma-mapping.h, branch v4.19.282

Reinstate some of "swiotlb: rework "fix info leak with DMA_FROM_DEVICE""

2022-05-25T07:10:41+00:00

commit 901c7280ca0d5e2b4a8929fbe0bfb007ac2a6544 upstream.

Halil Pasic points out [1] that the full revert of that commit (revert
in bddac7c1e02b), and that a partial revert that only reverts the
problematic case, but still keeps some of the cleanups is probably
better.  

And that partial revert [2] had already been verified by Oleksandr
Natalenko to also fix the issue, I had just missed that in the long
discussion.

So let's reinstate the cleanups from commit aa6f8dcbab47 ("swiotlb:
rework "fix info leak with DMA_FROM_DEVICE""), and effectively only
revert the part that caused problems.

Link: https://lore.kernel.org/all/20220328013731.017ae3e3.pasic@linux.ibm.com/ [1]
Link: https://lore.kernel.org/all/20220324055732.GB12078@lst.de/ [2]
Link: https://lore.kernel.org/all/4386660.LvFx2qVVIh@natalenko.name/ [3]
Suggested-by: Halil Pasic 
Tested-by: Oleksandr Natalenko 
Cc: Christoph Hellwig" 
Signed-off-by: Linus Torvalds 
[OP: backport to 4.19: adjusted context]
Signed-off-by: Ovidiu Panait 
Signed-off-by: Greg Kroah-Hartman

swiotlb: fix info leak with DMA_FROM_DEVICE

2022-05-25T07:10:41+00:00

commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e upstream.

The problem I'm addressing was discovered by the LTP test covering
cve-2018-1000204.

A short description of what happens follows:
1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
   interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV
   and a corresponding dxferp. The peculiar thing about this is that TUR
   is not reading from the device.
2) In sg_start_req() the invocation of blk_rq_map_user() effectively
   bounces the user-space buffer. As if the device was to transfer into
   it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in
   sg_build_indirect()") we make sure this first bounce buffer is
   allocated with GFP_ZERO.
3) For the rest of the story we keep ignoring that we have a TUR, so the
   device won't touch the buffer we prepare as if the we had a
   DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device
   and the  buffer allocated by SG is mapped by the function
   virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here
   scatter-gather and not scsi generics). This mapping involves bouncing
   via the swiotlb (we need swiotlb to do virtio in protected guest like
   s390 Secure Execution, or AMD SEV).
4) When the SCSI TUR is done, we first copy back the content of the second
   (that is swiotlb) bounce buffer (which most likely contains some
   previous IO data), to the first bounce buffer, which contains all
   zeros.  Then we copy back the content of the first bounce buffer to
   the user-space buffer.
5) The test case detects that the buffer, which it zero-initialized,
  ain't all zeros and fails.

One can argue that this is an swiotlb problem, because without swiotlb
we leak all zeros, and the swiotlb should be transparent in a sense that
it does not affect the outcome (if all other participants are well
behaved).

Copying the content of the original buffer into the swiotlb buffer is
the only way I can think of to make swiotlb transparent in such
scenarios. So let's do just that if in doubt, but allow the driver
to tell us that the whole mapped buffer is going to be overwritten,
in which case we can preserve the old behavior and avoid the performance
impact of the extra bounce.

Signed-off-by: Halil Pasic 
Signed-off-by: Christoph Hellwig 
[OP: backport to 4.19: adjusted context]
Signed-off-by: Ovidiu Panait 
Signed-off-by: Greg Kroah-Hartman

dma-mapping: fix return type of dma_set_max_seg_size()

2019-12-13T07:51:54+00:00

[ Upstream commit c9d76d0655c06b8c1f944e46c4fd9e9cf4b331c0 ]

The function dma_set_max_seg_size() can return either 0 on success or
-EIO on error. Change its return type from unsigned int to int to
capture this.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

dma-mapping: relax warning for per-device areas

2018-07-25T11:32:58+00:00

The reasons why dma_free_attrs() should not be called from IRQ context
are not necessarily obvious and somewhat buried in the development
history, so let's start by documenting the warning itself to help anyone
who does happen to hit it and wonder what the deal is.

However, this check turns out to be slightly over-restrictive for the
way that per-device memory has been spliced into the general API, since
for that case we know that dma_declare_coherent_memory() has created an
appropriate CPU mapping for the entire area and nothing dynamic should
be happening. Given that the usage model for per-device memory is often
more akin to streaming DMA than 'real' coherent DMA (e.g. allocating and
freeing space to copy short-lived packets in and out), it is also
somewhat more reasonable for those operations to happen in IRQ handlers
for such devices.

Therefore, let's move the irqs_disabled() check down past the per-device
area hook, so that that gets a chance to resolve the request before we
reach definite "you're doing it wrong" territory.

Reported-by: Fredrik Noring 
Tested-by: Fredrik Noring 
Signed-off-by: Robin Murphy 
Signed-off-by: Christoph Hellwig

x86/pci-dma: switch the VIA 32-bit DMA quirk to use the struct device flag

2018-05-28T10:48:25+00:00

Instead of globally disabling > 32bit DMA using the arch_dma_supported
hook walk the PCI bus under the actually affected bridge and mark every
device with the dma_32bit_limit flag.  This also gets rid of the
arch_dma_supported hook entirely.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Thomas Gleixner

dma-mapping: remove unused gfp_t parameter to arch_dma_alloc_attrs

2018-05-25T09:23:06+00:00

Signed-off-by: Huaisheng Ye 
Signed-off-by: Christoph Hellwig

dma-mapping: provide a generic dma-noncoherent implementation

2018-05-19T06:46:12+00:00

Add a new dma_map_ops implementation that uses dma-direct for the
address mapping of streaming mappings, and which requires arch-specific
implemenations of coherent allocate/free.

Architectures have to provide flushing helpers to ownership trasnfers
to the device and/or CPU, and can provide optional implementations of
the coherent mmap functionality, and the cache_flush routines for
non-coherent long term allocations.

Signed-off-by: Christoph Hellwig 
Tested-by: Alexey Brodkin 
Acked-by: Vineet Gupta

dma-mapping: move the NEED_DMA_MAP_STATE config symbol to lib/Kconfig

2018-05-09T04:56:08+00:00

This way we have one central definition of it, and user can select it as
needed.  Note that we now also always select it when CONFIG_DMA_API_DEBUG
is select, which fixes some incorrect checks in a few network drivers.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Anshuman Khandual

PCI: remove PCI_DMA_BUS_IS_PHYS

2018-05-07T05:15:41+00:00

This was used by the ide, scsi and networking code in the past to
determine if they should bounce payloads.  Now that the dma mapping
always have to support dma to all physical memory (thanks to swiotlb
for non-iommu systems) there is no need to this crude hack any more.

Signed-off-by: Christoph Hellwig 
Acked-by: Palmer Dabbelt  (for riscv)
Reviewed-by: Jens Axboe

Merge tag 'dma-mapping-4.17' of git://git.infradead.org/users/hch/dma-mapping

2018-04-05T17:23:24+00:00

Pull dma-mapping updates from Christoph Hellwig:
 "Very light this round as the interesting dma mapping changes went
  through the x86 tree.

  This just provides proper stubs for architectures not supporting dma
  (Geert Uytterhoeven)"

* tag 'dma-mapping-4.17' of git://git.infradead.org/users/hch/dma-mapping:
  usb: gadget: Add NO_DMA dummies for DMA mapping API
  scsi: Add NO_DMA dummies for SCSI DMA mapping API
  mm: Add NO_DMA dummies for DMA pool API
  dma-coherent: Add NO_DMA dummies for managed DMA API
  dma-mapping: Convert NO_DMA get_dma_ops() into a real dummy