From: SESA644425 <giojahermann@gmail.com>
To: sjg@chromium.org
Cc: gioja.hermann@non.se.com, mr.nuke.me@gmail.com,
jamin_lin@aspeedtech.com, xypron.glpk@gmx.de,
philippe.reynes@softathome.com, thomas.perrot@bootlin.com,
u-boot@lists.denx.de, giojahermann@gmail.com
Subject: [PATCH 2/3] lib: rsa: Leverage existing data buffer instead of systematic copy
Date: Wed, 9 Mar 2022 01:27:16 -0800 [thread overview]
Message-ID: <20220309092717.4203-3-gioja.hermann@non.se.com> (raw)
In-Reply-To: <20220309092717.4203-1-gioja.hermann@non.se.com>
Prior to introduction of modifications in rsassa_pss functions
related to padding verification, doing a pass to reduce memory
consumption of function by replacing memory copies of parts of
const buffer by pointers to the original buffer (masked_db and
h are subparts of msg buffer which is declared const, salt is a
subpart of db which is a working buffer, unmodified after being
filled). New pointers scope is limited to the function where
they are declared (not returned to caller by any mean), zeroing
risk of memory fault related to the change.
Signed-off-by: SESA644425 <gioja.hermann@non.se.com>
---
Despite checkpath.pl recommendation, it is not possible to use u8 instead
of uint8_t. Proceeding with u8 breaks build with error: unknown type name u8
lib/rsa/rsa-verify.c | 37 ++++++++++++++++++-------------------
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index c2c7248f90..de71234cfb 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -208,6 +208,10 @@ out:
* saltlen:-1 "set the salt length to the digest length" is currently
* not supported.
*
+ * msg is a concatenation of : masked_db + h + 0xbc
+ * Once unmasked, db is a concatenation of : [0x00]* + 0x01 + salt
+ * Length of 0-padding at begin of db depends on salt length.
+ *
* @info: Specifies key and FIT information
* @msg: byte array of message, len equal to msg_len
* @msg_len: Message length
@@ -218,27 +222,25 @@ int padding_pss_verify(struct image_sign_info *info,
const uint8_t *msg, int msg_len,
const uint8_t *hash, int hash_len)
{
- uint8_t *masked_db = NULL;
- int masked_db_len = msg_len - hash_len - 1;
- uint8_t *h = NULL, *hprime = NULL;
- int h_len = hash_len;
+ const uint8_t *masked_db = NULL;
uint8_t *db_mask = NULL;
- int db_mask_len = masked_db_len;
- uint8_t *db = NULL, *salt = NULL;
- int db_len = masked_db_len, salt_len = msg_len - hash_len - 2;
+ uint8_t *db = NULL;
+ int db_len = msg_len - hash_len - 1;
+ const uint8_t *h = NULL;
+ uint8_t *hprime = NULL;
+ int h_len = hash_len;
+ uint8_t *salt = NULL;
+ int salt_len = msg_len - hash_len - 2;
uint8_t pad_zero[8] = { 0 };
int ret, i, leftmost_bits = 1;
uint8_t leftmost_mask;
struct checksum_algo *checksum = info->checksum;
/* first, allocate everything */
- masked_db = malloc(masked_db_len);
- h = malloc(h_len);
- db_mask = malloc(db_mask_len);
+ db_mask = malloc(db_len);
db = malloc(db_len);
- salt = malloc(salt_len);
hprime = malloc(hash_len);
- if (!masked_db || !h || !db_mask || !db || !salt || !hprime) {
+ if (!db_mask || !db || !hprime) {
printf("%s: can't allocate some buffer\n", __func__);
ret = -ENOMEM;
goto out;
@@ -252,8 +254,8 @@ int padding_pss_verify(struct image_sign_info *info,
}
/* step 5 */
- memcpy(masked_db, msg, masked_db_len);
- memcpy(h, msg + masked_db_len, h_len);
+ masked_db = &msg[0];
+ h = &msg[db_len];
/* step 6 */
leftmost_mask = (0xff >> (8 - leftmost_bits)) << (8 - leftmost_bits);
@@ -265,7 +267,7 @@ int padding_pss_verify(struct image_sign_info *info,
}
/* step 7 */
- mask_generation_function1(checksum, h, h_len, db_mask, db_mask_len);
+ mask_generation_function1(checksum, h, h_len, db_mask, db_len);
/* step 8 */
for (i = 0; i < db_len; i++)
@@ -283,7 +285,7 @@ int padding_pss_verify(struct image_sign_info *info,
}
/* step 11 */
- memcpy(salt, &db[1], salt_len);
+ salt = &db[1];
/* step 12 & 13 */
compute_hash_prime(checksum, pad_zero, 8,
@@ -295,11 +297,8 @@ int padding_pss_verify(struct image_sign_info *info,
out:
free(hprime);
- free(salt);
free(db);
free(db_mask);
- free(h);
- free(masked_db);
return ret;
}
--
2.25.1
next prev parent reply other threads:[~2022-03-09 13:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 9:27 [PATCH 0/3] Support any-salt for padding pss verification SESA644425
2022-03-09 9:27 ` [PATCH 1/3] lib: rsa: Fix const-correctness of rsassa_pss functions SESA644425
2022-03-12 2:43 ` Simon Glass
2022-04-11 20:14 ` Tom Rini
2022-03-09 9:27 ` SESA644425 [this message]
2022-03-12 2:43 ` [PATCH 2/3] lib: rsa: Leverage existing data buffer instead of systematic copy Simon Glass
2022-04-11 20:14 ` Tom Rini
2022-03-09 9:27 ` [PATCH 3/3] lib: rsa: Update function padding_pss_verify (any-salt) SESA644425
2022-03-12 2:43 ` Simon Glass
2022-04-11 20:14 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220309092717.4203-3-gioja.hermann@non.se.com \
--to=giojahermann@gmail.com \
--cc=gioja.hermann@non.se.com \
--cc=jamin_lin@aspeedtech.com \
--cc=mr.nuke.me@gmail.com \
--cc=philippe.reynes@softathome.com \
--cc=sjg@chromium.org \
--cc=thomas.perrot@bootlin.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox