#
467382ca |
|
14-Dec-2023 |
Tom Rini <trini@konsulko.com> |
lib: Remove <common.h> inclusion from these files After some header file cleanups to add missing include files, remove common.h from all files in the lib directory. This primarily means just dropping the line but in a few cases we need to add in other header files now. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> |
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> |
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
8479333c |
|
14-Sep-2020 |
Robert Reither <robert.reither@external.thalesgroup.com> |
rsa: crash in br_i32_decode() called from rsa_gen_key_prop() Fixes problem for unaligned 32bit big-endian access in lib/rsa/rsa-keyprop.c. Exchanges br_i32_decode() with get_unaligned_be32(). This will keep the unaligned access for architectures capable and will do some byte-shift magic for the not so capable ones. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-by: Robert Reither <robert.reither@external.thalesgroup.com> Remove unused include. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
eda753be |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: free local arrays after use in rsa_gen_key_prop() n, rr and rrtmp are used for internal calculations, but in the end the results are copied into separately allocated elements of the actual key_prop, so the n, rr and rrtmp elements are not used anymore when returning from the function and should of course be freed. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
49d0ea37 |
|
07-Jul-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop() When calculating rrtmp/rr rsa_gen_key_prop() tries to make (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] with rlen being num_bits * 2 On a 4096bit key this comes down to to 257 uint32_t elements in rr and 256 elements in rrtmp but with the current allocation rr and rrtmp only have 129 uint32_t elements. On 2048bit keys this works by chance as the defined max_rsa_size=4096 allocates a suitable number of elements, but with an actual 4096bit key this results in other memory parts getting overwritten. So as suggested by Heinrich Schuchardt just use the actual bit-size of the key as base for the size calculation, in turn making the code compatible to any future keysizes. Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8434b437 |
|
18-Jun-2020 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
lib: rsa: bring exp_len in line when generating a key_prop The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
#
e0d310b0 |
|
20-Feb-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
lib: rsa: generate additional parameters for public key In the current implementation of FIT_SIGNATURE, five parameters for a RSA public key are required while only two of them are essential. (See rsa-mod-exp.h and uImage.FIT/signature.txt) This is a result of considering relatively limited computer power and resources on embedded systems, while such a assumption may not be quite practical for other use cases. In this patch, added is a function, rsa_gen_key_prop(), which will generate additional parameters for other uses, in particular UEFI secure boot, on the fly. Note: the current code uses some "big number" routines from BearSSL for the calculation. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|