From mboxrd@z Thu Jan 1 00:00:00 1970 From: AKASHI Takahiro Date: Tue, 21 Jul 2020 20:56:59 +0900 Subject: [RFC] dfu: remove UPDATE_TFTP In-Reply-To: <3608fdda-f66a-583f-487c-2f927c740f13@gmx.de> References: <20200715104518.20554-1-xypron.glpk@gmx.de> <20200715132436.4f8725a3@jawa> <20200715152338.48f7fcc4@jawa> <098f26e2-a6f2-fbaa-f8da-92627e14147b@gmx.de> <20200716015246.GD12429@laputa> <3608fdda-f66a-583f-487c-2f927c740f13@gmx.de> Message-ID: <20200721115659.GA10366@laputa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 [ ] [] - device firmware upgrade via > >>>> TFTP on device , attached to interface [] - > >>>> address where FIT image has been stored > >>>> > >>>> Thanks, Michal > >>>> > >