[RFC] regarding Uboot AUTOBOOT_STOP_STR_SHA256

[RFC] regarding Uboot AUTOBOOT_STOP_STR_SHA256

[Joel Peshkin]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4166 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20201120/5616275d/attachment.bin>

[RFC] regarding Uboot AUTOBOOT_STOP_STR_SHA256

[Harm Berntsen]

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 <joel.peshkin@broadcom.com>
To: Stefan Roese <sr@denx.de>, u-boot at lists.denx.de
<u-boot@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