linux-kernel - Re: Buffer allocation for USB transfers

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]

Message-ID: <496E8193.9070603@shaw.ca>
Date:	Wed, 14 Jan 2009 18:21:39 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Christian Eggers <ceggers@....de>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Buffer allocation for USB transfers

Christian Eggers wrote:
> In different drivers I've found several methods for allocating buffers 
> transfered with usb_control_msg() or usb_submit_urb():
> 
> - usb_stor_msg_common() in "drivers/usb/storage/transport.c" uses buffers 
> allocated with usb_buffer_alloc(). These buffers are used with 
> URB_NO_xxx_DMA_MAP in urb->transfer_flags.
> 
> - asix_read_cmd() in "drivers/net/usb/asix.c" uses kmalloc(GFP_KERNEL).
> 
> - mcs7830_get_reg() in "drivers/net/usb/mcs7830.c" uses buffers from 
> the stack.
> 
> At least the latter does not work on my SH-4 platform. It seems that other 
> variables on the stack are overwritten after calling usb_control_msg(), probably as 
> result of incorrect alignment.

Indeed, DMA to/from the stack is not allowed (on some platforms it may 
invalidate other data in the same cache line, etc. which is likely what 
you are seeing). Assuming that the USB core is DMAing directly to/from 
that memory, it's a bug in that mcs7830 driver.

> 
> For some reason the second example (kmalloc()) doesn't seem to cause problems (on 
> my platform) but is there are guarantee that kmalloc() 
> without GFP_DMA does always return a DMA capable buffer?

Yes, as long as the DMA mapping API is used properly to map the buffer 
(which I'm assuming it is, not being a USB core expert.) GFP_DMA is not 
intended for this, drivers should not be using that flag, unless maybe 
they are doing ISA transfers which is not the case with USB.

> 
> Shall all buffers used for usb_control_msg() and usb_submit_urb() be 
> allocated with usb_buffer_alloc()? It seems that usb_control_msg() doesn't 
> offer a way to set the URB_NO_xxx_DMA_MAP in urb->transfer_flags so that 
> usb_buffer_alloc() can not be used here???
> 
> regards
> Christian Eggers
> 
> Please CC to ceggers@....de
> 

--
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/