: "You should
ask on the
linux-arch@xxxxxxxxxxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, and
linux-kernel@xxxxxxxxxxxxxxx mailing lists."
I was using the zerocopy buffer feature, and just wondering if anybody
ended up following this up on those kernel lists. I didn't find it
mentioned with a brief google.
Dumping kernel ram to userspace is obviously a serious security issue,
so maybe it's not being discussed via public channels. But it would
be tragic if it were not being discussed at all.
On 10/9/18, Steve Markgraf <steve(a)steve-m.de> wrote:
Hi,
so it turned out that this is indeed a Kernel issue. I have implemented
a crude workaround for both rtl-sdr and osmo-fl2k to detect the bug, and
fall back to buffers in userspace if it is present.
I've sent the mail below to the linux-usb list, but didn't get any reply
so far. Let's see.
--
When I debugged the issue, I found out that the Kernel maps seemingly
random memory to my transfer buffers, containing memory of other
processes or even the Kernel itself.
The code that does the mapping in drivers/usb/core/devio.c:
(line 243 in v4.19-rc7)
if (remap_pfn_range(vma, vma->vm_start,
virt_to_phys(usbm->mem) >> PAGE_SHIFT,
size, vma->vm_page_prot) < 0) {
With the following change the issue is fixed for ARM systems, but it
breaks x86 systems:
- virt_to_phys(usbm->mem) >> PAGE_SHIFT,
+ page_to_pfn(virt_to_page(dma_addr)),
Both usbm->mem and dma_addr are returned by the previous call to
usb_alloc_coherent().
Here's an example of the pointers generated by the two macros on an
ARM64 system for the same buffer:
virt_to_phys(usbm->mem) >> PAGE_SHIFT: 00000000808693ce
page_to_pfn(virt_to_page(dma_addr)): 000000009775a856
From what I read so far I got the impression that the 'proper' way would
be to use dma_mmap_coherent() with dma_addr instead of
remap_pfn_range(), however, I did not get it to work. Can anyone help
out?
Best Regards,
Steve Markgraf