Hi Steffen, On Sat, 1 May 2021 at 03:51, Steffen Jaeckel <jaeckel-fl...@eyet-services.de> wrote: > > Hi Simon, > > On 4/29/21 6:10 PM, Simon Glass wrote: > >> diff --git a/include/crypt.h b/include/crypt.h > >> new file mode 100644 > >> index 0000000000..e0be2832ff > >> --- /dev/null > >> +++ b/include/crypt.h > >> @@ -0,0 +1,13 @@ > >> +/* SPDX-License-Identifier: GPL-2.0+ */ > >> +/* Copyright (C) 2020 Steffen Jaeckel <jaeckel-fl...@eyet-services.de> */ > >> + > >> +/** > >> + * Compare should with the processed passphrase. > >> + * > >> + * @should The crypt-style string to compare against > >> + * @passphrase The plaintext passphrase > >> + * @equal Pointer to an int where the result is stored > >> + * '0' = unequal > >> + * '1' = equal > > > > Can this be a return value from the function? true/false > > ... the next patch in the series changes the return type to int ... I'll > rework those to make this better visible. > > The concept stayed the same as IMO this would complicate the handling in > the caller and with this pattern the usage is a lot easier: > * return value indicates success of the operation > * `equal` argument returns whether the given crypt-style string equals > the hashed passphrase
Well that's up to you, but it is pretty common in U-Boot to return an error code or a true/false value. > > > >> + */ > >> +void crypt_compare(const char *should, const char *passphrase, int > >> *equal); > >> diff --git a/lib/Kconfig b/lib/Kconfig > >> index 6d2d41de30..c7c0b87ec7 100644 > >> --- a/lib/Kconfig > >> +++ b/lib/Kconfig > >> @@ -297,6 +297,7 @@ config AES > >> > >> source lib/rsa/Kconfig > >> source lib/crypto/Kconfig > >> +source lib/crypt/Kconfig > >> > >> config TPM > >> bool "Trusted Platform Module (TPM) Support" > >> diff --git a/lib/Makefile b/lib/Makefile > >> index 6825671955..f0d91986b1 100644 > >> --- a/lib/Makefile > >> +++ b/lib/Makefile > >> @@ -65,6 +65,7 @@ obj-$(CONFIG_FIT_SIGNATURE) += hash-checksum.o > >> obj-$(CONFIG_SHA1) += sha1.o > >> obj-$(CONFIG_SHA256) += sha256.o > >> obj-$(CONFIG_SHA512_ALGO) += sha512.o > >> +obj-$(CONFIG_CRYPT_PW) += crypt/ > >> > >> obj-$(CONFIG_$(SPL_)ZLIB) += zlib/ > >> obj-$(CONFIG_$(SPL_)ZSTD) += zstd/ > >> diff --git a/lib/crypt/Kconfig b/lib/crypt/Kconfig > >> new file mode 100644 > >> index 0000000000..6f828cefd6 > >> --- /dev/null > >> +++ b/lib/crypt/Kconfig > >> @@ -0,0 +1,29 @@ > >> +config CRYPT_PW > >> + bool "Add crypt support for password-based unlock" > >> + help > >> + Enable support for crypt-style hashed passphrases. > >> + This will then be used as the mechanism of choice to > >> + verify whether the entered password to unlock the > >> + console is correct or not. > >> + To make it fully functional, one has also to enable > >> + CONFIG_AUTOBOOT_KEYED and CONFIG_AUTOBOOT_ENCRYPTION > > > > So should CRYPT_PW depend on one or both of those? > > Should it depend or can it also select? Depend is better, as I understand it, but not sure if this applies to you: https://docs.zephyrproject.org/1.14.0/guides/kconfig/index.html#select-pitfalls > > > ... > >> diff --git a/lib/crypt/crypt-sha256.c b/lib/crypt/crypt-sha256.c > >> new file mode 100644 > >> index 0000000000..37127d41e1 > >> --- /dev/null > >> +++ b/lib/crypt/crypt-sha256.c > >> @@ -0,0 +1,313 @@ > >> +/* One way encryption based on the SHA256-based Unix crypt implementation. > >> + * > >> + * Written by Ulrich Drepper <drepper at redhat.com> in 2007 [1]. > >> + * Modified by Zack Weinberg <zackw at panix.com> in 2017, 2018. > >> + * Composed by Björn Esser <besser82 at fedoraproject.org> in 2018. > >> + * Modified by Björn Esser <besser82 at fedoraproject.org> in 2020. > >> + * Modified by Steffen Jaeckel <jaeckel-floss at eyet-services.de> in > >> 2020. > >> + * To the extent possible under law, the named authors have waived all > >> + * copyright and related or neighboring rights to this work. > >> + * > >> + * See https://creativecommons.org/publicdomain/zero/1.0/ for further > >> + * details. > >> + * > >> + * This file is a modified except from [2], lines 648 up to 909. > >> + * > >> + * [1] https://www.akkadia.org/drepper/sha-crypt.html > >> + * [2] https://www.akkadia.org/drepper/SHA-crypt.txt > > > > Can you add SPDX to the new files? > > Sure, after we're done with those files I'll see which parts I can > upstream to libxcrypt. OK. Regards, Simon