This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.
Karl gmkarl at gmail.comHey, 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 >