[U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting

[Stefan Schmidt]

Hello.

On Tue, 2014-04-01 at 11:00, Lukasz Majewski wrote:
> Hi Tormod,
> 
> > On Mon, Mar 31, 2014 at 10:44 PM, Lukasz Majewski wrote:
> > > The DFU 1.1 standard in its appendinx B specifies the DFU suffix.
> > > It has the crc32 for the whole file, vendorID, device ID and other
> > > handy fields.
> > >
> > > Unfortunately, this part of the standard is not supported neither at
> > > dfu implementation in u-boot nor dfu-util (v.0.5 - debian).
> > >
> > > It would be handy for small files (like bootloaders, kernels) where
> > > we download all the data at once. For critical files it should be
> > > definitely implemented. From my glimpse observation the dfu-util
> > > would require some extension to support the DFU suffix (Tormod,
> > > please correct me if I'm wrong).
> > 
> > You are wrong :) Please don't use what's available in Debian (stable?)
> > as a reference.
> 
> I'm regarding this as a reference since 80% of developers will download
> the dfu-util with apt-get on debian.

You really believe that 80% of all developers are using Debian? If
they ship an old version there is nothing Tormod can do about it. I
implemented the dfu suffix feature one or two years ago and made a
release after it. If distros are not picking it up you have to fill a
bug for them to update.

> > I don't know what their maintainer is up to. dfu-util
> > supports the DFU suffix according to the DFU standard. That means it
> > checks the CRC after reading the file, and also checks that
> > vendor/product values match, then sends the firmware to the device
> > after stripping off the suffix.
> 
> So this means that:
> 1. The file before reading by dfu-util has to be equipped with suffix.
> 2. The dfu-util reads it and then if matching sends data (with sufix
> stripped) to target. This means that we are "protected" from downloading
> wrong firmware to device, however
> 3. The target doesn't have any means to check if the downloaded data is
> consistent - the information about CRC is stripped at dfu-util.

Correct. That is how the DFU spec defines it.

> > 
> > Are you wanting to do some CRC checking at the device side? That would
> > be outside the DFU standard. 
> 
> I hoped that the suffix is appended by dfu-util and then sent with the
> binary to target. As a result we would be able to perform some integrity
> tests.

The spec requires to remove it. I also found that odd when
implementing it but the spec is clear on this.

> > But you can always put whatever you want
> > in the "firmware", including proprietary headers or suffices.
> 
> I think that this would be finally required for updating small (crucial)
> files - like bootloaders, kernels.
> 
> > We
> > already support some of those, please see the dfu-util (and
> > dfu-suffx/dfu-prefix) code at dfu-util.gnumonks.org.
> 
> Ok, I see. This would probably require extension of ./src/prefix.c file.
> In this way u-boot community would impose some kind of standard
> prefix/suffix only for u-boot. It's a pity, that integrity checking is
> not standardized in the DFU.

It all depends on how much you want to be compatible with the DFU
spec.

regards
Stefan Schmidt