netdev - Re: [PATCH net 1/4] pegasus: Use heap buffers for all register access

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 6 Feb 2017 14:51:09 +0200
From:   Petko Manolov <petkan@...leusys.com>
To:     Greg KH <greg@...ah.com>
Cc:     Ben Hutchings <ben@...adent.org.uk>, netdev@...r.kernel.org,
        linux-usb@...r.kernel.org,
        Lisandro Damián Nicanor Pérez Meyer 
        <lisandro@...ian.org>
Subject: Re: [PATCH net 1/4] pegasus: Use heap buffers for all register access

On 17-02-06 09:28:22, Greg KH wrote:
> On Mon, Feb 06, 2017 at 10:14:44AM +0200, Petko Manolov wrote:
> > On 17-02-05 01:30:39, Greg KH wrote:
> > > On Sat, Feb 04, 2017 at 04:56:03PM +0000, Ben Hutchings wrote:
> > > > Allocating USB buffers on the stack is not portable, and no longer works 
> > > > on x86_64 (with VMAP_STACK enabled as per default).
> > > 
> > > It's never worked on other platforms, so these should go to the stable 
> > > releases please.
> > 
> > As far as i know both drivers works fine on other platforms, though I only 
> > tested it on arm and mipsel. ;)
> 
> It all depends on the arm and mips platforms, the ones that can not DMA from 
> stack memory are the ones that would always fail here (since the 2.2 kernel 
> days).

Seems like most modern SOCs have decent DMA controllers.

> > Random thought: isn't it better to add the alloc/free code in 
> > usb_control_msg() and avoid code duplication all over the driver space?
> 
> A very long time ago we considered it, but realized that the majority of 
> drivers already had the memory dynamically allocated, so we just went with 
> this.  Perhaps we could revisit that if it turns out we were wrong, and would 
> simplify things.

A quick glance at usb_control_msg() users (looked only at .../net/usb and 
.../usb/serial) shows that most of them have the buffer allocated in stack.  
These transfers are relatively infrequent and quite small the performance hit 
caused by memcpy() should also be negligible.

I suspect getting the buffer allocation in usb_control_msg() will help with two 
things in the same time:

 - allocate in DMA-able memory;
 - code reduction;

On the bad side i've no idea who'll volunteer to go through all 
usb_control_msg() sites and perform the fix.  Seems like the right job for an 
intern to me. :D


cheers,
Petko