All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [PATCH v2 3/7] common: integrate crypt-based passwords
Date: Mon, 10 May 2021 13:45:14 -0700	[thread overview]
Message-ID: <CAPnjgZ3B2Q4YerQj0N03N+sedfASfzYyhoynoaffHMBmqXxkzg@mail.gmail.com> (raw)
In-Reply-To: <ab6edb6b-ce45-e17d-9217-b5c68b4a896b@eyet-services.de>

Hi Steffen,

On Mon, 10 May 2021 at 13:37, Steffen Jaeckel
<jaeckel-floss@eyet-services.de> wrote:
>
> Hi Simon
>
> On 5/10/21 10:24 PM, Simon Glass wrote:
> > On Mon, 10 May 2021 at 14:06, Steffen Jaeckel
> > <jaeckel-floss@eyet-services.de> wrote:
> >> On 5/10/21 9:19 PM, Simon Glass wrote:
> >>> On Mon, 10 May 2021 at 11:05, Steffen Jaeckel
> >>> <jaeckel-floss@eyet-services.de> wrote:
> >>>> On 5/10/21 6:27 PM, Simon Glass wrote:
> >>>>> On Mon, 10 May 2021 at 00:19, Steffen Jaeckel
> >>>>> <jaeckel-floss@eyet-services.de> wrote:
> >>>>>>
> >>>>>> Hook into the autoboot flow as an alternative to the existing
> >>>>>> mechanisms.
> >>>>>>
> >>>>>> Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
> >>>>>> ---
> >>>>>>
> >>>>>> (no changes since v1)
> >>>>>>
> >>>>>>  common/Kconfig.boot | 37 ++++++++++++++++++---
> >>>>>>  common/autoboot.c   | 80 ++++++++++++++++++++++++++++++++++++++++-----
> >>>>>>  2 files changed, 103 insertions(+), 14 deletions(-)
> >>>>>
> >>>>> Reviewed-by: Simon Glass <sjg@chromium.org>
> >>>>>
> >>>>> But I think you'll need to allow both to be enabled.
> >>>>
> >>>> Sorry, but what exactly do you mean?
> >>>
> >>> I mean the ability to enable both crypt and the sha options rather
> >>> than just one at a time.
> >>
> >> You have a point there. Even though this approach should IMO become the
> >> recommended way to store passwords, one could imagine that support for
> >> both approaches in parallel could be needed, e.g. in a transition period.
> >>
> >> The biggest problem I see is that the passwd_abort_{crypt,sha256}()
> >> functions consume the serial input. I fear that an implementation that
> >> supports both would need to have a painful amount of special case
> >> handling in order to not break the expected behavior of the existing
> >> sha256 implementation.
> >>
> >> Supporting both in a backwards compatible way would make the
> >> implementation a lot more complex and therefor I'd prefer to leave it as is.
> >
> > I don't quite mean that. Only one should be used at once. But would it
> > be possible to support both at runtime, so that (at runtime) you check
> > an env var to decide which is active?
>
> oh okay, that's easier :)
>
> maybe something like this?
>
> diff --git a/common/autoboot.c b/common/autoboot.c
> index 50ab9281e7..6f55abe388 100644
> --- a/common/autoboot.c
> +++ b/common/autoboot.c
> @@ -316,3 +316,4 @@ static int abortboot_key_sequence(int bootdelay)
>         if (IS_ENABLED(CONFIG_AUTOBOOT_ENCRYPTION)) {
> -               if (IS_ENABLED(CONFIG_CRYPT_PW))
> +               if (IS_ENABLED(CONFIG_CRYPT_PW) &&
> +                   env_get_yesno("bootstopusesha256") != 1)
>                         abort = passwd_abort_crypt(etime);

Yes, and then you can enable both in sandbox and potentially have a
test for your code within the standard sandbox build.

Regards,
Simon

  reply	other threads:[~2021-05-10 20:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-10  6:19 [PATCH v2 0/7] common: Introduce crypt-style password support Steffen Jaeckel
2021-05-10  6:19 ` [PATCH v2 1/7] lib: add crypt subsystem Steffen Jaeckel
2021-05-10  6:19 ` [PATCH v2 2/7] lib: wrap crypt API to hide errno usage Steffen Jaeckel
2021-05-10 16:27   ` Simon Glass
2021-05-10 17:05     ` Steffen Jaeckel
2021-05-10  6:19 ` [PATCH v2 3/7] common: integrate crypt-based passwords Steffen Jaeckel
2021-05-10 16:27   ` Simon Glass
2021-05-10 17:05     ` Steffen Jaeckel
2021-05-10 19:19       ` Simon Glass
2021-05-10 20:05         ` Steffen Jaeckel
2021-05-10 20:24           ` Simon Glass
2021-05-10 20:36             ` Steffen Jaeckel
2021-05-10 20:45               ` Simon Glass [this message]
2021-05-11 15:02                 ` Steffen Jaeckel
2021-05-11 15:27                   ` Simon Glass
2021-05-11 18:29                     ` Steffen Jaeckel
2021-05-12 16:17                       ` Simon Glass
2021-05-10  6:19 ` [PATCH v2 4/7] common: Rename macro appropriately Steffen Jaeckel
2021-05-10  6:19 ` [PATCH v2 5/7] cmd: allow disabling of timeout for password entry Steffen Jaeckel
2021-05-10  6:19 ` [PATCH v2 6/7] configs: add new values to bcm963158 defconfig Steffen Jaeckel
2021-05-10  6:19 ` [PATCH v2 7/7] configs: add new sandbox with crypt-based password Steffen Jaeckel
2021-05-10 16:28   ` Simon Glass
2021-05-10 17:04     ` Steffen Jaeckel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPnjgZ3B2Q4YerQj0N03N+sedfASfzYyhoynoaffHMBmqXxkzg@mail.gmail.com \
    --to=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.