Librtlsdr zerocopy buffers not working on Tinkerboard Armbian

[Karl]

Hey, to follow this up ...

I saw there was a reply on the linux-usb list at
https://www.spinics.net/lists/linux-usb/msg173393.html: "You should
ask on the
linux-arch at xxxxxxxxxxxxxxx, linux-arm-kernel at xxxxxxxxxxxxxxxxxxx, and
linux-kernel at 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 at 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
>