On Thu, Jul 16, 2020 at 06:44:43AM +0200, Heinrich Schuchardt wrote: > On 7/16/20 3:52 AM, AKASHI Takahiro wrote: > > On Wed, Jul 15, 2020 at 04:42:20PM +0200, Heinrich Schuchardt wrote: > > On 15.07.20 16:06, Michal Simek wrote: > >>>> > >>>> > >>>> On 15. 07. 20 15:23, Lukasz Majewski wrote: > >>>>> Hi Heinrich, > >>>>> > >>>>> On 15.07.20 13:24, Lukasz Majewski wrote: > >>>>>>>> Hi Heinrich, > >>>>>>>> > >>>>>>>>> Using UPDATE_TFTP the firmware can be updated from tFTP > >>>>>>>>> by writing to NOR flash. The same is possible by defining > >>>>>>>>> a dfu command in CONFIG_PREBOOT. > >>>>>>>>> > >>>>>>>>> The dfu command cannot only write to NOR but also to > >>>>>>>>> other devices. In README.dfutfp UPDATE_TFTP has been > >>>>>>>>> marked as deprecated. > >>>>>>>> > >>>>>>>> Could you also write in the proper README the steps > >>>>>>>> necessary to have the same functionality as with > >>>>>>>> UPDATE_TFTP with dfu and preboot? I think that it would be > >>>>>>>> good to have it written down in ./doc. > >>>>>>>> > >>>>> > >>>>> doc/README.dfutftp already describes the necessary steps as: > >>>>> > >>>>> * enable CONFIG_DFU_TFTP * enable CONFIG_PREBOOT * put a string > >>>>> like "dfu tftp 0 mmc 0" into the "preboot" env variable > >>>>> > >>>>> Do you want me to explicitly write that "dfu tftp 0 mtd 0" > >>>>> replaces the former auto-update functionality? > >>>> > >>>> I am curious if that command is really dfu tftp 0 mtd 0. > > > > Lukasz was asking about the replacement of the update that was > > executed when running with CONFIG_UPDATE_TFTP=y. This function that I > > am removing could only write to NOR flash. The update defined via > > CONFIG_PREBOOT is much more flexible and can server other storage media. > > > >> One of my concerns regarding CONFIG_PREBOOT is that it depends > >> on the "preboot" variable. > >> What this means is that, if a user unsets this variable (accidentally > >> or not), 'automatic firmware update' won't be executed. > >> This can be a critical issue if the system administrator intends to > >> *enforce* the update. > >> (I know there are more issues regarding enforcement though.) > > You could also defeat the old tFTP auto-update by setting "serverip" to > a reserved value like 240.0.0.0. So there is no new vulnerability > introduced here.
? I'm not talking about tftp here, but about a potential issue in the current framework. -Takahiro Akashi > Anyway no board uses the old tFTP auto-update while DFU is enabled in > 273 config files and DFU_TFTP in 2. > > Best regards > > Heinrich > > > > >> That is why I added UEFI capsule update hook in main_loop() as > >> a compile-time option. > > > >> Thanks, > >> -Takahiro Akashi > > > > > > The different accessible devices are described in doc/README.dfu. > > "ram" is one of them. > > > > Best regards > > > > Heinrich > > > >>>> > >>>> I have just tested it on zynqmp with copying images to ram and > >>>> command is just dfu tftp ram 0. It means I think it would be worth > >>>> to list options which are really used by different back ends > >>>> because it is not fully clear from help how to exactly define it. > >>>> > >>>> dfu tftp [<interface> <dev>] [<addr>] - device firmware upgrade via > >>>> TFTP on device <dev>, attached to interface <interface> [<addr>] - > >>>> address where FIT image has been stored > >>>> > >>>> Thanks, Michal > >>>> > >
