linux-kernel - RE: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

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:	Wed, 13 Oct 2010 11:41:12 -0700
From:	Kevin Hayes <kevin@...eros.com>
To:	"Luis R. Rodriguez" <mcgrof@...il.com>
CC:	Luis Rodriguez <Luis.Rodriguez@...eros.com>,
	Marcel Holtmann <marcel@...tmann.org>,
	Henry Ptasinski <henryp@...adcom.com>,
	Suraj Sumangala <Suraj.Sumangala@...eros.com>,
	David Woodhouse <dwmw2@...radead.org>,
	linux-bluetooth <linux-bluetooth@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-wireless <linux-wireless@...r.kernel.org>
Subject: RE: Firmware versioning best practices: ath3k-2.fw rename or
 replace ath3k-1.fw ?

Hi Luis,

> -----Original Message-----
> From: linux-bluetooth-owner@...r.kernel.org [mailto:linux-bluetooth-
> owner@...r.kernel.org] On Behalf Of Luis R. Rodriguez
> Sent: Wednesday, October 13, 2010 11:10 AM
> To: Kevin Hayes
> Cc: Luis Rodriguez; Marcel Holtmann; Henry Ptasinski; Suraj Sumangala;
> David Woodhouse; linux-bluetooth; linux-kernel@...r.kernel.org; linux-
> wireless
> Subject: Re: Firmware versioning best practices: ath3k-2.fw rename or
> replace ath3k-1.fw ?
> 
> On Wed, Oct 13, 2010 at 10:54 AM, Kevin Hayes <kevin@...eros.com>
> wrote:
> > Hi Luis,
> >
> >
> >> -----Original Message-----
> >> From: linux-bluetooth-owner@...r.kernel.org [mailto:linux-bluetooth-
> >> owner@...r.kernel.org] On Behalf Of Luis R. Rodriguez
> >> Sent: Wednesday, October 13, 2010 10:43 AM
> >> To: Marcel Holtmann
> >> Cc: Henry Ptasinski; Suraj Sumangala; Luis Rodriguez; David
> Woodhouse;
> >> linux-bluetooth; linux-kernel@...r.kernel.org; linux-wireless
> >> Subject: Re: Firmware versioning best practices: ath3k-2.fw rename
> or
> >> replace ath3k-1.fw ?
> >>
> >> On Wed, Oct 13, 2010 at 3:06 AM, Marcel Holtmann
> <marcel@...tmann.org>
> >> wrote:
> >> > Hi Henry,
> >> >
> >> >> > > Marcel had answered me before. It makes sense to have same
> file
> >> name.
> >> >> > > Other ways we end up changing the driver whenever there is a
> >> firmware
> >> >> > > change.
> >> >> >
> >> >> > > > I last tried to document a thread we had over this here:
> >> >> > > >
> >> >> > > >
> >> http://wireless.kernel.org/en/developers/Documentation/firmware-
> >> versioning
> >> >> > > >
> >> >> >
> >> >> > Thanks, I've updated that link above to document bug fixing
> does
> >> not require
> >> >> > a filename change.
> >> >>
> >> >> I don't really understand why you would not want to change the
> code
> >> revision
> >> >> part of the filename.
> >> >>
> >> >> I totally agree that you don't want to change the driver every
> time
> >> the
> >> >> firmware gets a bug fix, but wasn't that the whole point of
> >> splitting the name
> >> >> into API and code revisions portions, and symlinking the file to
> one
> >> that just
> >> >> has the API version?
> >> >>
> >> >> What's the issue with using the process as originally documented?
> >> >
> >> > as I stated before, for Bluetooth this makes no sense. You don't
> need
> >> > API version numbers since the API is a STANDARD. It is called HCI.
> So
> >> > please don't use API version numbers in the firmware files.
> >> >
> >> > I will reject firmware file versions for upstream drivers.
> >>
> >> Does the HCI standard ever get improved upon? If so, how do devices
> >> never get firmware updates that would allow them to use some newer
> HCI
> >> APIs?
> >>
> >> I've updated the documentation above for 802.11 and Bluetooth with
> the
> >> above, please feel free to further extend it as you see fit.
> >>
> >>   Luis
> >
> > HCI is always backward compatible.  Newer commands are properly
> discoverable by both sides of the HCI link.
> > As long as the procedure to download firmware does not depend on new
> HCI commands (it does not), then the firmware itself can teach an old
> controller to learn new tricks.
> 
> Does HCI support uploading firmware? Can't we resolve this blacklist
> crap issue if devices just used HCI to upload firmware?
> 
>   Luis
> --

Not really because there is not enough space in the sflash to do much of anything except report the PID.
It must be some external code that picks the firmware to load and inject it into the controller.
That external code is the DFU bit.  We must blacklist the device so that btusb does not claim it, so we can use the DFU.

    K++

[Pardon the garbage that our mail server adds...]