| Message ID | 20210510061916.3388626-4-jaeckel-floss@eyet-services.de |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | common: Introduce crypt-style password support | expand |
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.
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?
Hi Steffen, 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. Regards, Simon
Hi Simon, 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. Cheers Steffen
Hi Steffen, On Mon, 10 May 2021 at 14:06, Steffen Jaeckel <jaeckel-floss@eyet-services.de> wrote: > > Hi Simon, > > 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? Regards, Simon
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); Cheers Steffen
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
Hi Simon, On 5/10/21 10:45 PM, Simon Glass wrote: > On Mon, 10 May 2021 at 13:37, Steffen Jaeckel > <jaeckel-floss@eyet-services.de> wrote: [snip] >> 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. What kind of tests do you want to have added? Python based or C based ones? TBH I don't see an easy way (yet) to add more tests than the ones I already added, as enabling AUTOBOOT_KEYED (which is required for both, crypt and sha256) would change the startup behavior of the sandbox... Cheers Steffen
Hi Steffen, On Tue, 11 May 2021 at 09:02, Steffen Jaeckel <jaeckel-floss@eyet-services.de> wrote: > > Hi Simon, > > On 5/10/21 10:45 PM, Simon Glass wrote: > > On Mon, 10 May 2021 at 13:37, Steffen Jaeckel > > <jaeckel-floss@eyet-services.de> wrote: > > [snip] > > >> 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. > > What kind of tests do you want to have added? Python based or C based ones? > > TBH I don't see an easy way (yet) to add more tests than the ones I > already added, as enabling AUTOBOOT_KEYED (which is required for both, > crypt and sha256) would change the startup behavior of the sandbox... Here is my idea...we have console monitoring, like this: console_record_reset(); run_command("acpi dump rdst", 0); ut_assert_nextline("Table 'RDST' not found"); ut_assert_console_end(); What is needed is the ability to inject console input. We have gd->console_in (in console.c) but there is currently no function to add input to it. Something similar to console_record_puts() is needed, perhaps called console_write_in(), which does a membuff_put(&gd->console_in, ...) with some input data (the hash). That way the input can be read by sandbox. Then I think you could write a test like this: console_record_reset(); console_write_in(hash_string, strlen(hash_string)); ut_assertok(autoboot_command("")); ut_assert_nextline("whatever indicates success"); ut_assert_console_end(); Regards, SImon
Hi Simon, On 5/11/21 5:27 PM, Simon Glass wrote: >> >> [snip] >> >>>> 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. >> >> What kind of tests do you want to have added? Python based or C based ones? >> >> TBH I don't see an easy way (yet) to add more tests than the ones I >> already added, as enabling AUTOBOOT_KEYED (which is required for both, >> crypt and sha256) would change the startup behavior of the sandbox... > > Here is my idea...we have console monitoring, like this: > > console_record_reset(); > run_command("acpi dump rdst", 0); > ut_assert_nextline("Table 'RDST' not found"); > ut_assert_console_end(); > > What is needed is the ability to inject console input. We have > gd->console_in (in console.c) but there is currently no function to > add input to it. Something similar to console_record_puts() is needed, > perhaps called console_write_in(), which does a > membuff_put(&gd->console_in, ...) with some input data (the hash). > That way the input can be read by sandbox. > > Then I think you could write a test like this: > > console_record_reset(); > console_write_in(hash_string, strlen(hash_string)); > ut_assertok(autoboot_command("")); > ut_assert_nextline("whatever indicates success"); > ut_assert_console_end(); OK, that sounds fine, with the only problem that there's no way to enable the necessary features without also having them enabled in the autoboot flow!? i.e. instead of having a single keypress to enable the console of the sandbox, one would always have to enter the password, or am I missing something? Cheers Steffen
Hi Steffen, On Tue, 11 May 2021 at 12:30, Steffen Jaeckel <jaeckel-floss@eyet-services.de> wrote: > > Hi Simon, > > On 5/11/21 5:27 PM, Simon Glass wrote: > >> > >> [snip] > >> > >>>> 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. > >> > >> What kind of tests do you want to have added? Python based or C based ones? > >> > >> TBH I don't see an easy way (yet) to add more tests than the ones I > >> already added, as enabling AUTOBOOT_KEYED (which is required for both, > >> crypt and sha256) would change the startup behavior of the sandbox... > > > > Here is my idea...we have console monitoring, like this: > > > > console_record_reset(); > > run_command("acpi dump rdst", 0); > > ut_assert_nextline("Table 'RDST' not found"); > > ut_assert_console_end(); > > > > What is needed is the ability to inject console input. We have > > gd->console_in (in console.c) but there is currently no function to > > add input to it. Something similar to console_record_puts() is needed, > > perhaps called console_write_in(), which does a > > membuff_put(&gd->console_in, ...) with some input data (the hash). > > That way the input can be read by sandbox. > > > > Then I think you could write a test like this: > > > > console_record_reset(); > > console_write_in(hash_string, strlen(hash_string)); > > ut_assertok(autoboot_command("")); > > ut_assert_nextline("whatever indicates success"); > > ut_assert_console_end(); > > OK, that sounds fine, with the only problem that there's no way to > enable the necessary features without also having them enabled in the > autoboot flow!? > > i.e. instead of having a single keypress to enable the console of the > sandbox, one would always have to enter the password, or am I missing > something? Yes I see. Perhaps have a function to indicate whether it should be enabled at runtime? For sandbox it can return false? You could add a sandbox command-line flag to make it skip this, I suppose. An environment variable is another option. We often have little tweaks with tests to get them to do what we want. Regards, Simon
diff --git a/common/Kconfig.boot b/common/Kconfig.boot index 5a18d62d78..f81a44b23e 100644 --- a/common/Kconfig.boot +++ b/common/Kconfig.boot @@ -812,10 +812,17 @@ config AUTOBOOT_ENCRYPTION depends on AUTOBOOT_KEYED help This option allows a string to be entered into U-Boot to stop the - autoboot. The string itself is hashed and compared against the hash - in the environment variable 'bootstopkeysha256'. If it matches then - boot stops and a command-line prompt is presented. - + autoboot. + The behavior depends whether CONFIG_CRYPT_PW from lib is enabled + or not. + In case CONFIG_CRYPT_PW is enabled, the string will be forwarded + to the crypt-based functionality and be compared against the + string in the environment variable 'bootstopkeycrypt'. + In case CONFIG_CRYPT_PW is disabled the string itself is hashed + and compared against the hash in the environment variable + 'bootstopkeysha256'. + If it matches in either case then boot stops and + a command-line prompt is presented. This provides a way to ship a secure production device which can also be accessed at the U-Boot command line. @@ -853,9 +860,29 @@ config AUTOBOOT_KEYED_CTRLC Setting this variable provides an escape sequence from the limited "password" strings. +config AUTOBOOT_STOP_STR_ENABLE + bool "Enable fixed string to stop autobooting" + depends on AUTOBOOT_KEYED && AUTOBOOT_ENCRYPTION + help + This option enables the feature to add a fixed stop + string that is defined at compile time. + In every case it will be tried to load the stop + string from the environment. + In case this is enabled and there is no stop string + in the environment, this will be used as default value. + +config AUTOBOOT_STOP_STR_CRYPT + string "Stop autobooting via crypt-hashed password" + depends on AUTOBOOT_STOP_STR_ENABLE + help + This option adds the feature to only stop the autobooting, + and therefore boot into the U-Boot prompt, when the input + string / password matches a values that is hashed via + one of support crypt options and saved in the environment. + config AUTOBOOT_STOP_STR_SHA256 string "Stop autobooting via SHA256 encrypted password" - depends on AUTOBOOT_KEYED && AUTOBOOT_ENCRYPTION + depends on AUTOBOOT_STOP_STR_ENABLE help This option adds the feature to only stop the autobooting, and therefore boot into the U-Boot prompt, when the input diff --git a/common/autoboot.c b/common/autoboot.c index 0bb08e7a4c..d52f88dd54 100644 --- a/common/autoboot.c +++ b/common/autoboot.c @@ -23,6 +23,7 @@ #include <linux/delay.h> #include <u-boot/sha256.h> #include <bootcount.h> +#include <crypt.h> DECLARE_GLOBAL_DATA_PTR; @@ -38,18 +39,75 @@ DECLARE_GLOBAL_DATA_PTR; static int stored_bootdelay; static int menukey; -#ifdef CONFIG_AUTOBOOT_ENCRYPTION -#define AUTOBOOT_STOP_STR_SHA256 CONFIG_AUTOBOOT_STOP_STR_SHA256 -#else -#define AUTOBOOT_STOP_STR_SHA256 "" +#if !defined(CONFIG_AUTOBOOT_STOP_STR_CRYPT) +#define CONFIG_AUTOBOOT_STOP_STR_CRYPT "" +#endif +#if !defined(CONFIG_AUTOBOOT_STOP_STR_SHA256) +#define CONFIG_AUTOBOOT_STOP_STR_SHA256 "" #endif - #ifdef CONFIG_USE_AUTOBOOT_MENUKEY #define AUTOBOOT_MENUKEY CONFIG_USE_AUTOBOOT_MENUKEY #else #define AUTOBOOT_MENUKEY 0 #endif +/** + * passwd_abort_crypt() - check for a crypt-style hashed key sequence to abort booting + * + * This checks for the user entering a password within a given time. + * + * The entered password is hashed via one of the crypt-style hash methods + * and compared to the pre-defined value from either + * the environment variable "bootstopkeycrypt" + * or + * the config value CONFIG_AUTOBOOT_STOP_STR_CRYPT + * + * @etime: Timeout value ticks (stop when get_ticks() reachs this) + * @return 0 if autoboot should continue, 1 if it should stop + */ +static int passwd_abort_crypt(uint64_t etime) +{ + const char *crypt_env_str = env_get("bootstopkeycrypt"); + char presskey[MAX_DELAY_STOP_STR]; + u_int presskey_len = 0; + int abort = 0; + int err; + + if (IS_ENABLED(CONFIG_AUTOBOOT_STOP_STR_ENABLE) && !crypt_env_str) + crypt_env_str = CONFIG_AUTOBOOT_STOP_STR_CRYPT; + + if (!crypt_env_str) + return 0; + + /* We expect the stop-string to be newline-terminated */ + do { + if (tstc()) { + /* Check for input string overflow */ + if (presskey_len >= sizeof(presskey)) + return 0; + + presskey[presskey_len] = getchar(); + + if ((presskey[presskey_len] == '\r') || + (presskey[presskey_len] == '\n')) { + presskey[presskey_len] = '\0'; + err = crypt_compare(crypt_env_str, presskey, + &abort); + if (err) + debug_bootkeys( + "crypt_compare() failed with: %s\n", + errno_str(err)); + /* you had one chance */ + break; + } else { + presskey_len++; + } + } + } while (get_ticks() <= etime); + + return abort; +} + /* * Use a "constant-length" time compare function for this * hash compare: @@ -89,7 +147,7 @@ static int passwd_abort_sha256(uint64_t etime) int ret; if (sha_env_str == NULL) - sha_env_str = AUTOBOOT_STOP_STR_SHA256; + sha_env_str = CONFIG_AUTOBOOT_STOP_STR_SHA256; presskey = malloc_cache_aligned(MAX_DELAY_STOP_STR); c = strstr(sha_env_str, ":"); @@ -245,10 +303,14 @@ static int abortboot_key_sequence(int bootdelay) printf(CONFIG_AUTOBOOT_PROMPT, bootdelay); # endif - if (IS_ENABLED(CONFIG_AUTOBOOT_ENCRYPTION)) - abort = passwd_abort_sha256(etime); - else + if (IS_ENABLED(CONFIG_AUTOBOOT_ENCRYPTION)) { + if (IS_ENABLED(CONFIG_CRYPT_PW)) + abort = passwd_abort_crypt(etime); + else + abort = passwd_abort_sha256(etime); + } else { abort = passwd_abort_key(etime); + } if (!abort) debug_bootkeys("key timeout\n");
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(-)