All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabio Estevam <festevam@gmail.com>
To: u-boot@lists.denx.de
Subject: [PATCH v2] fit_image: Use calloc() to fix reproducibility issue
Date: Mon, 27 Jul 2020 21:03:13 -0300	[thread overview]
Message-ID: <20200728000313.31130-1-festevam@gmail.com> (raw)

Vagrant Cascadian reported that mx6cuboxi target no longer builds
reproducibility on Debian.

One example of builds mismatches:

00096680: 696e 6700 736f 756e 642d 6461 6900 6465  ing.sound-dai.de
-00096690: 7465 6374 2d67 7069 6f73 0000            tect-gpios..
+00096690: 7465 6374 2d67 7069 6f73 0061            tect-gpios.a

This problem happens because all the buffers in fit_image.c are
allocated via malloc(), which does not zero out the allocated buffer.

Using calloc() fixes this unpredictable behaviour as it guarantees
that the allocated buffer are zero initialized.

Reported-by: Vagrant Cascadian <vagrant@reproducible-builds.org>
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
---
Changes since v1:
- Improve the commit log description by stating why calloc() helps.

 tools/fit_image.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/fit_image.c b/tools/fit_image.c
index a082d9386d..0c6185d892 100644
--- a/tools/fit_image.c
+++ b/tools/fit_image.c
@@ -388,7 +388,7 @@ static int fit_build(struct image_tool_params *params, const char *fname)
 	size = fit_calc_size(params);
 	if (size < 0)
 		return -1;
-	buf = malloc(size);
+	buf = calloc(1, size);
 	if (!buf) {
 		fprintf(stderr, "%s: Out of memory (%d bytes)\n",
 			params->cmdname, size);
@@ -467,7 +467,7 @@ static int fit_extract_data(struct image_tool_params *params, const char *fname)
 	 * Allocate space to hold the image data we will extract,
 	 * extral space allocate for image alignment to prevent overflow.
 	 */
-	buf = malloc(fit_size + (align_size * image_number));
+	buf = calloc(1, fit_size + (align_size * image_number));
 	if (!buf) {
 		ret = -ENOMEM;
 		goto err_munmap;
@@ -572,7 +572,7 @@ static int fit_import_data(struct image_tool_params *params, const char *fname)
 
 	/* Allocate space to hold the new FIT */
 	size = sbuf.st_size + 16384;
-	fdt = malloc(size);
+	fdt = calloc(1, size);
 	if (!fdt) {
 		fprintf(stderr, "%s: Failed to allocate memory (%d bytes)\n",
 			__func__, size);
@@ -673,7 +673,7 @@ static int copyfile(const char *src, const char *dst)
 		goto out;
 	}
 
-	buf = malloc(512);
+	buf = calloc(1, 512);
 	if (!buf) {
 		printf("Can't allocate buffer to copy file\n");
 		goto out;
-- 
2.17.1

             reply	other threads:[~2020-07-28  0:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28  0:03 Fabio Estevam [this message]
2020-07-28 19:07 ` [PATCH v2] fit_image: Use calloc() to fix reproducibility issue Vagrant Cascadian
2020-08-05 20:28 ` 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=20200728000313.31130-1-festevam@gmail.com \
    --to=festevam@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

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

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