From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harm Berntsen Date: Mon, 23 Nov 2020 14:38:27 +0000 Subject: [RFC] regarding Uboot AUTOBOOT_STOP_STR_SHA256 In-Reply-To: References: Message-ID: <987a02fe1c45c047276d4c92ba62d839c72ecbf3.camel@nedap.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Joel, Regarding 2, In my implementation I have the following: bootcmd=run bootcmd2 || reset In case bootcmd2 fails, the board will reset instead of dropping to a prompt. Maybe this is also sufficient for you :). Kind regards, Harm Berntsen -----Original Message----- From: Joel Peshkin To: Stefan Roese , u-boot at lists.denx.de Subject: [RFC] regarding Uboot AUTOBOOT_STOP_STR_SHA256 Date: Fri, 20 Nov 2020 11:16:03 -0800 Hi Stefan, ??? I have a patch ( https://patchwork.ozlabs.org/project/uboot/patch/20201120180524.30251-1-jp933255 at xl-irv-13.lvn.broadcom.net/ ) under review that adds optional SALT to AUTOBOOT_STOP_STR_SHA256 without breaking backward compatibility.? As I see that you were involved with the original requirements, I want to bring that patch to your attention and ask you about several others that I plan to follow with.?? I presume I should explicitly add you to the CC on those. ?? Do you have any concerns about the following changes?? 1) Prior to entering the autoboot.c, it is possible that there would already be characters in the UART receive buffer that are not part of the password.? For my application, it is preferable to swallow any existing characters before starting to accept characters into the password.?? Is this something that would be a problem for anyone who might rely on beginning to type the password before the device gets to the prompt?? Would I need to make this a config option? 2) If the password is not given, autoboot will not permit CLI access before bootcmd.? However, if bootcmd returns (most likely fails), the current implementation permits access without a password.? My requirements would require the password even if the boot fails.? Is this something that should be configurable or should I make the change to autoboot so that, if the boot fails, the password is required again and the device will require reset if the password is not given then? 3) The passwords themselves may be relatively long and we do not want to have a long timeout increasing boot time.? My current implementation treats the timeout as the time to BEGIN typing the password and adds one second for every character typed.? So, I can have a 5 second timeout and, if the password is 10 characters long, then the user doesn't time out as long as they start typing within the 5 seconds and average one character per second.?? Would this be something that needs to be configurable in Kconfig or would it be OK to specify the added 1 second time in a #define ?? Thank You, Joel Peshkin