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: <56DD4C84.1090506@felipetonello.com>
Date:	Mon, 7 Mar 2016 09:40:20 +0000
From:	Felipe Ferreri Tonello <eu@...ipetonello.com>
To:	Felipe Balbi <balbi@...nel.org>, linux-usb@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org,
	Michal Nazarewicz <mina86@...a86.com>,
	Clemens Ladisch <clemens@...isch.de>
Subject: Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on
 bmAttributes

Hi Balbi,

On 07/03/16 07:34, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Ferreri Tonello <eu@...ipetonello.com> writes:
>> [ text/plain ]
>> Hi Balbi, 
>>
>> On March 4, 2016 7:16:42 AM GMT+00:00, Felipe Balbi <balbi@...nel.org> wrote:
>>>
>>> Hi,
>>>
>>> "Felipe F. Tonello" <eu@...ipetonello.com> writes:
>>>> [ text/plain ]
>>>> This gadget uses a bmAttributes and MaxPower that requires the USB
>>> bus to be
>>>> powered from the host, which is not correct because this
>>> configuration is device
>>>> specific, not a USB-MIDI requirement.
>>>>
>>>> This patch adds two modules parameters, bmAttributes and MaxPower,
>>> that allows
>>>> the user to set those flags. The default values are what the gadget
>>> used to use
>>>> for backward compatibility.
>>>>
>>>> Signed-off-by: Felipe F. Tonello <eu@...ipetonello.com>
>>>> ---
>>>>  drivers/usb/gadget/legacy/gmidi.c | 14 ++++++++++++--
>>>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/usb/gadget/legacy/gmidi.c
>>> b/drivers/usb/gadget/legacy/gmidi.c
>>>> index fc2ac150f5ff..0553435cc360 100644
>>>> --- a/drivers/usb/gadget/legacy/gmidi.c
>>>> +++ b/drivers/usb/gadget/legacy/gmidi.c
>>>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>>>>  module_param(out_ports, uint, S_IRUGO);
>>>>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>>>>  
>>>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
>>>> +module_param(bmAttributes, uint, S_IRUGO);
>>>> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>>> bmAttributes parameter");
>>>> +
>>>> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
>>>> +module_param(MaxPower, uint, S_IRUGO);
>>>> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>>> Descriptor's bMaxPower parameter");
>>>
>>> you didn't run checkpatch, did you ? Also, are you sure you will need
>>> to
>>> change this by simply reloading the module ? I'm not convinced.
>>
>> Yes I always run checkpatch :)
> 
> do you really ? Why do you have a 98-character line, then ?
> 
>> What do you mean by reloading the module?
> 
> modprobe g_midi MaxPower=4
> modprobe -r g_midi
> modprobe g_midi MaxPower=10
> 
> I'm not convinced this is a valid use-case. Specially since you can just
> provide several configurations and let the host choose the one it suits
> it best.

Ok, I will further test it.

> 
>>>> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>>>>  	.label		= "MIDI Gadget",
>>>>  	.bConfigurationValue = 1,
>>>>  	/* .iConfiguration = DYNAMIC */
>>>> -	.bmAttributes	= USB_CONFIG_ATT_ONE,
>>>
>>> nack, nackety nack nack nack :-)
>>>
>>> USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>>> give users the oportunity to violate USB spec.
>>
>> You are right. It needs to check the value before it assigns to
>> bmAttributes.
> 
> why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
> case, I'm not convinced this is necessary at all.

Right.

This is necessary because this driver is actually wrong in which is
asking for the host to power itself. This is not specified on USB-MIDI
specification, neither makes any sense since this configuration is
device specific.

What is your suggestion to make it configurable? Maybe at compile-time?
I really don't know what is the best solution if this is not something
you like it.

Felipe

Download attachment "0x92698E6A.asc" of type "application/pgp-keys" (7196 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ