From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick Wildt Date: Sat, 30 May 2020 22:53:52 +0200 Subject: [PATCH] ARM: imx: hab: panic on authentication failure In-Reply-To: <374631a8-bd6b-5cee-47e4-29e57d26c243@denx.de> References: <20200530182900.159874-1-marex@denx.de> <20200530201457.GA8838@ryzen.blueri.se> <374631a8-bd6b-5cee-47e4-29e57d26c243@denx.de> Message-ID: <20200530205352.GA681@ryzen.blueri.se> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sat, May 30, 2020 at 10:29:19PM +0200, Marek Vasut wrote: > On 5/30/20 10:14 PM, Patrick Wildt wrote: > > On Sat, May 30, 2020 at 03:31:29PM -0300, Fabio Estevam wrote: > >> Hi Marek, > >> > >> [Adding Breno] > >> > >> On Sat, May 30, 2020 at 3:29 PM Marek Vasut wrote: > >>> > >>> Instead of hang()ing the system and thus disallowing any automated > >>> recovery possibility from a HAB authentication failure, panic() . > >>> The panic() function can be configured to hang() the system after > >>> printing an error message, however the default is to reset the > >>> system instead. > >>> > >>> This allows redundant boot to work correctly. In case the primary > >>> or secondary image cannot be authenticated, the system reboots and > >>> bootrom can try to start the other one. > >>> > >>> Signed-off-by: Marek Vasut > >>> Cc: Fabio Estevam > >>> Cc: NXP i.MX U-Boot Team > >>> Cc: Peng Fan > >>> Cc: Stefano Babic > >> > >> This is a better behavior indeed: > >> > >> Reviewed-by: Fabio Estevam > > > > What about this? Have you ignored this patch for a reason? :/ > > > > https://marc.info/?l=u-boot&m=159069441005730&w=2 > > Yes, and the reason is I was not even aware of your patch, sorry. The CC > list in this mail should cover all the interested parties, so use it > when sending V2, or use patman. I already had 11 people on CC, but apparently I missed you. > The patch looks fine, one nit is that you should return errno.h return > value and another is that it changes the current behavior. Now that I > look at this imx code, board_spl_fit_post_load() should not even be in > arch/ , sigh, but that's for separate patch either way. > > So I think if you want to support this sort of fallback, you should make > the board_spl_fit_post_load() be in board/ files, with default __weak > implementation calling some arch_hab_authenticate...() which implements > current content of board_spl_fit_post_load(), and let boards decide how > to handle the fallback if it needs to be altered. > > Would that work ? I'm not sure. In comparison to the people from NXP who are paid to upstream their code and still don't do it correctly, I'm doing this in my spare time and I'm not sure I want to bikeshed all day long. I can send a V3 that replaces the -1 with EINVAL, EACCESS, EPERM or something the like. If you want to clean up after NXP, feel free to. Which errno would you like to see? Best regards, Patrick