linux-kernel - Re: Allocating buffers for USB transfers (again)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 07 Jul 2011 14:14:00 +0200
From:	Clemens Ladisch <clemens@...isch.de>
To:	Daniel Mack <zonque@...il.com>
CC:	linux-usb@...r.kernel.org, alsa-devel@...a-project.org,
	Takashi Iwai <tiwai@...e.de>, florian@...kler.org,
	pedrib@...il.com, William Light <wrl@...est.net>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: Allocating buffers for USB transfers (again)

Daniel Mack wrote:
> I have to revisit an issue we've discussed in length around a year ago
> and which still remains unsolved. I've been getting feedback from more
> users of my driver snd-usb-caiaq who report the issue found in bug
> #15580 in the kernel bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=15580
> 
> Let me quickly summarize the current state of this issue as I see it.
> 
> The problem seems to be that certain 64bit chipsets can't deal with
> the fact that an URB's transfer_buffer is allocated with
> kmalloc(GFP_KERNEL). The effect is that kmalloc() is very likely to
> hand out memory which is not addressable by devices that are connected
> via 32bit PCI busses, such as EHCI controllers. In theory, DMA bounce
> buffers should be installed in such cases, or the IOMMU would be in
> charge to re-map these buffers to suitable locations, but for at least
> two people who have reported the issue, this obviously fails.

The problem is that snd-usb-caiaq modifies the URB buffer after
submission.

USB drivers must always be prepared to work with host controllers that
use double buffering.  (IIRC there are some exotic ones where the
hardware works only with internal SRAM.)  DMA mapping, if available, is
only an optimization.

> The question now is how to proceed. I see three possible ways.
> ...
> 3. re-activate the currently disabled functions
> usb_buffer_{map,unmap,sync} functions and let the USB stack do the
> memory mapping

This is the only way that allows bounce buffers to be copied at the
correct time.

> What really puzzles me is that this doesn't hit a lot more people with
> other drivers.

I don't think there is any other driver that relies on the buffer being
coherently DMA-mapped.


Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/