linux-kernel - Re: [PATCH v2] usb: gadget: f_hid: optional SETUP/SET

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] [day] [month] [year] [list]

Message-ID: <20210820173632.053b1b2d@reki>
Date:   Fri, 20 Aug 2021 17:36:32 +0300
From:   Maxim Devaev <mdevaev@...il.com>
To:     Maciej Żenczykowski <maze@...gle.com>
Cc:     balbi@...nel.org, stern@...land.harvard.edu,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        ruslan.bilovol@...il.com, mika.westerberg@...ux.intel.com,
        jj251510319013@...il.com, linux-usb@...r.kernel.org,
        Kernel hackers <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] usb: gadget: f_hid: optional SETUP/SET_REPORT mode

Maciej Żenczykowski <maze@...gle.com> wrote:
> perhaps better to rephrase as 'the host ceases to change the status of
> the gadget/keyboard LEDs',
> unless this is actually driven by the keyboard as opposed to the other
> way round (which is what I'd expect from AT, PS/2 keyboards).

Since I'm describing the behavior on the gadget side,
it seemed to me that the explanation about the impossibility
of receiving it was more appropriate.

> Not clear what 'not poll' means here.  Why would they (the host) need
> to poll an OUT endpoint?

Poll the IN Endpoint, fixed

> Additionally it seems like any keyboard gadget would want to default
> to the older more compatible mode?
> Or are there compatibility problems with it as well?

Yes, any keyboard should use SETUP/SET_REPORT if it wants maximum
compatibility. This mode has no problems with hosts. I suggest it
as optional only because for the last 9 years the default behavior
has been OUT Endpoint and in the place of those people who use it,
I would be upset if this was changed, since it could lead to strange
problems like lack of a queue and loss of events if f_hid is used
for data transmission, and not for emulating input devices.

> if you look down below, this isn't actually dynamic, should we just
> have hidg_interface_desc_{intout,ssreport} structs?

DYNAMIC is indirectly provided by the no_out_endpoints flag.
I preferred to avoid duplicating the code here.

> may be better to just use an if (hidg->use_out_ep) status =
> usb_assign_descriptors(...) else status = usb_assign_descriptors(...)

Yep, you're right

> maybe it would be better to use consistent naming...
> 
> hidg->no_out_endpoint = opts->no_out_endpoint
> 
> or call the option 'use_ssreport' instead of 'no_out_endpoint'
> (negatives are harder to think about)

Yea, I also thought about it and made such a name precisely
based on consistency. The rest of the code contains the out_ep
variable, so it was logical to make the use_out_ep flag.
In addition, there are no long names like *_out_endpoint anywhere.
At the same time, abbreviations are not used in configfs
and I didn't want to make a flag there that the user should change
to 0 if he does not want to use out endpoint. I would prefer
to leave it as it is, because it does not use negation logic,
and it will be easy for you to grep something like out_ep\>

> Anyway, nothing in here is particularly important, just loose thoughts.
> In general this seems pretty nice.

Thank you for the review! I will fix this and make a third version of the patch.