linux-kernel - Re: usb-storage: how to extend quirks flags to 64bit?

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:   Sun, 27 Aug 2023 11:50:12 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Milan Broz <gmazyland@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, usb-storage@...ts.one-eyed-alien.net,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: usb-storage: how to extend quirks flags to 64bit?

On Sun, Aug 27, 2023 at 11:32:05AM +0200, Milan Broz wrote:
> Hello,
> 
> I tried to extend USB storage for the passthrough of Opal
> security commands,

What sort of changes are needed?  Where is this passthrough mechanism 
documented?

>  and some adapters are clearly "not perfect".

Which ones?

> I would need to introduce a new quirks flag to turn it off.
> 
> Seems that we are already out of quirks flags on 32bit
> for usb storage - in usb_usual.h the last entry in mainline is
>   US_FLAG(SENSE_AFTER_SYNC, 0x80000000)
> 
> Adding a new flag will work for 64-bit systems but not
> for platforms with 32-bit unsigned long like i686.
> 
> How do we allow new flag definitions?
> 
> Struct us_data fflags can be made 64bit (defined in
> drivers/usb/storage/usb.h), but the major problem is that these
> are transferred through the generic driver_info field
> defined in linux/mod_devicetable.h as unsigned long).
> Making this 64bit is IMO an extensive API change (if even possible).
> I guess this is not the way to go.
> 
> Could USB maintainers please help to advise what is the correct
> solution? I am not familiar with the USB driver model here
> and I see no easy way how it can be solved by a trivial static
> allocation inside the USB storage driver.
> 
> Someone will need a new quirks flag in the future anyway... :)

I can think of only one way to accomplish this on 32-bit systems: Change 
the driver_info field from a bit array to an index into a static table 
of 64-bit flags values.  Each unusual_devs structure would have its own 
entry in this table.  As far as I can tell, the other unusual_*.h tables
could retain their current driver_info interpretations, since no new 
quirk bits are likely to be relevant to them.

Making this change would be an awkward nuisance, but it should be 
doable.

Alan Stern