Encrypted zchunk header in delta update

John Michael Edgware

unread,

Mar 16, 2023, 9:42:04 AM3/16/23

to swupdate

Hi,

It would be great to be able to encrypt zchunk header in update file otherwise hashes are in plain text and can be used to reconstruct large parts of image if similar image is available.

Right now encrypting zchunk file itself seems complicated because AES-CBC does not support random access. It could be achieved with AES-CTR combined with ranges on AES block boundaries.

At least by having both zchunk header and sw-description encrypted it is possible to use un-guessable HTTPS URL without leaking secrets. This of course requires server authentication to avoid man in the middle.

Support for HTTPS client authentication with or without PKCS11would be a solution however that also requires access to server configuration which might be challenging to some.

Here is the patch which allows encryption of zchunk header. Not knowing internals of swupdate I am not sure it is the best approach:

diff --git a/handlers/delta_handler.c b/handlers/delta_handler.c
index e848f15..e078157 100644
--- a/handlers/delta_handler.c
+++ b/handlers/delta_handler.c
@@ -37,6 +37,7 @@
#include <pctl.h>
#include <pthread.h>
#include <fs_interface.h>
+#include <sys/mman.h>
#include "delta_handler.h"
#include "multipart_parser.h"
#include "installer.h"
@@ -840,7 +841,7 @@ static int install_delta(struct img_type *img,
{
struct hnd_priv *priv;
int ret = -1;
- int dst_fd = -1, in_fd = -1;
+ int dst_fd = -1, in_fd = -1, mem_fd = -1;
zckChunk *iter;
zckCtx *zckSrc = NULL, *zckDst = NULL;
char *FIFO = NULL;
@@ -965,7 +966,37 @@ static int install_delta(struct img_type *img,
zck_get_error(zckSrc));
goto cleanup;
}
- if (!zck_init_read(zckDst, img->fdin)) {
+
+ mem_fd = memfd_create("zchunk header", 0);
+ if (mem_fd == -1) {
+ ERROR("Cannot create memory file: %s", strerror(errno));
+ goto cleanup;
+ }
+
+ ret = copyfile(img->fdin,
+ &mem_fd,
+ img->size,
+ (unsigned long *)&img->offset,
+ img->seek,
+ 0,
+ img->compressed,
+ &img->checksum,
+ img->sha256,
+ img->is_encrypted,
+ img->ivt_ascii,
+ NULL);
+
+ if (ret != 0) {
+ ERROR("Error %d copying zchunk header, aborting.", ret);
+ goto cleanup;
+ }
+
+ if (lseek(mem_fd, 0, SEEK_SET) < 0) {
+ ERROR("Seeking start of memory file");
+ goto cleanup;
+ }
+
+ if (!zck_init_read(zckDst, mem_fd)) {
ERROR("Unable to read ZCK header from %s : %s",
img->fname,
zck_get_error(zckDst));
@@ -1020,6 +1051,8 @@ static int install_delta(struct img_type *img,
memset(priv_hnd->img.sha256, 0, SHA256_HASH_LENGTH);
strlcpy(priv_hnd->img.type, priv->chainhandler, sizeof(priv_hnd->img.type));
priv_hnd->img.fdin = pipes[PIPE_READ];
+ /* zchunk files are not encrypted, CBC is not suitable for range download */
+ priv_hnd->img.is_encrypted = false;

signal(SIGPIPE, SIG_IGN);

@@ -1064,6 +1097,7 @@ cleanup:
if (zckDst) zck_free(&zckDst);
close(dst_fd);
close(in_fd);
+ close(mem_fd);
if (FIFO) {
unlink(FIFO);
free(FIFO);

John Michael Edgware

unread,

Mar 16, 2023, 12:42:24 PM3/16/23

to swupdate

Small edit - AES-CTR does not depend on alignment to block size - all it needs to know is offset.

Stefano Babic

unread,

Mar 17, 2023, 6:11:36 AM3/17/23

to John Michael Edgware, swupdate

Hi John,

On 16.03.23 14:42, John Michael Edgware wrote:
> Hi,
>
> It would be great to be able to encrypt zchunk header in update file
> otherwise hashes are in plain text and can be used to reconstruct large
> parts of image if similar image is available.
>
> Right now encrypting zchunk file itself seems complicated because
> AES-CBC does not support random access. It could be achieved with
> AES-CTR combined with ranges on AES block boundaries.
>

It cannot be done in this way - let me explain.

To add (full) encryption to zchunk, we need to add this to the format,
that means zchunk must be extended (as I did for the uncompressed files)
to add "zst+encryption" to the chunks. That means, chunks are not only
compressed via zst, but then they are encrypted and the information for
the encription must be added to the meta data, that is in the header.
This should be first discussed zchunk's maintainer (Jonathan Dieter) to
check if it is a suitable way for his project.

> At least by having both zchunk header and sw-description encrypted it is
> possible to use un-guessable HTTPS URL without leaking secrets. This of
> course requires server authentication to avoid man in the middle.

So you are not going to encrypt zchunk (see above), but you want to hide
the URL (more or less) and the meta (zck header).

>
> Support for HTTPS client authentication with or without PKCS11would be a
> solution however that also requires access to server configuration which
> might be challenging to some.
> Here is the patch which allows encryption of zchunk header. Not knowing
> internals of swupdate I am not sure it is the best approach:
>
> diff --git a/handlers/delta_handler.c b/handlers/delta_handler.c
> index e848f15..e078157 100644
> --- a/handlers/delta_handler.c
> +++ b/handlers/delta_handler.c
> @@ -37,6 +37,7 @@
> #include <pctl.h>
> #include <pthread.h>
> #include <fs_interface.h>
> +#include <sys/mman.h>
> #include "delta_handler.h"
> #include "multipart_parser.h"
> #include "installer.h"
> @@ -840,7 +841,7 @@ static int install_delta(struct img_type *img,
> {
> struct hnd_priv *priv;
> int ret = -1;

> -int dst_fd = -1, in_fd = -1;
> +int dst_fd = -1, in_fd = -1, mem_fd = -1;

> zckChunk *iter;
> zckCtx *zckSrc = NULL, *zckDst = NULL;
> char *FIFO = NULL;
> @@ -965,7 +966,37 @@ static int install_delta(struct img_type *img,
> zck_get_error(zckSrc));
> goto cleanup;
> }
> -if (!zck_init_read(zckDst, img->fdin)) {

File is copied at least twice. If artifact is encrypted, the generic
code should already have decompress / decrypted the incoming stream and
the decrypted header should be already availbale to img->fdin (of
course, it works not yet, but I don't think it should be copied again).

Best regards,
Stefano Babic

> +
> +mem_fd = memfd_create("zchunk header", 0);
> +if (mem_fd == -1) {
> +ERROR("Cannot create memory file: %s", strerror(errno));

> +goto cleanup;
> +}
> +
> +ret = copyfile(img->fdin,
> +&mem_fd,
> +img->size,
> +(unsigned long *)&img->offset,
> +img->seek,
> +0,
> +img->compressed,
> +&img->checksum,
> +img->sha256,
> +img->is_encrypted,
> +img->ivt_ascii,
> +NULL);
> +
> +if (ret != 0) {

> +ERROR("Error %d copying zchunk header, aborting.", ret);

> +goto cleanup;
> +}
> +
> +if (lseek(mem_fd, 0, SEEK_SET) < 0) {

> +ERROR("Seeking start of memory file");
> +goto cleanup;
> +}
> +
> +if (!zck_init_read(zckDst, mem_fd)) {

> ERROR("Unable to read ZCK header from %s : %s",
> img->fname,
> zck_get_error(zckDst));
> @@ -1020,6 +1051,8 @@ static int install_delta(struct img_type *img,
> memset(priv_hnd->img.sha256, 0, SHA256_HASH_LENGTH);
> strlcpy(priv_hnd->img.type, priv->chainhandler, sizeof(priv_hnd->img.type));
> priv_hnd->img.fdin = pipes[PIPE_READ];

> +/* zchunk files are not encrypted, CBC is not suitable for range
> download */
> +priv_hnd->img.is_encrypted = false;

>
> signal(SIGPIPE, SIG_IGN);
>
> @@ -1064,6 +1097,7 @@ cleanup:
> if (zckDst) zck_free(&zckDst);
> close(dst_fd);
> close(in_fd);
> +close(mem_fd);
> if (FIFO) {
> unlink(FIFO);
> free(FIFO);
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/44735c49-8e29-40ec-90f7-199155583352n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/44735c49-8e29-40ec-90f7-199155583352n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

John Michael Edgware

unread,

Mar 17, 2023, 7:18:11 AM3/17/23

to swupdate

Hi Stefano,

Thank you!

About AES-CTR - I'm not saying it is the best way but it should work without changes in zchunk. AES-CTR allows random access and it does not have to be aligned to or to be multiple of AES block size. The whole zchunk file can be encrypted without any regard to it's content and when individual chunk is downloaded it can be decrypted just by knowing AES key, IV and chunk offset, my quick guess in network_process_data before zck_get_chunk_digest by using priv->rangestart as offset.

Stefano Babic

unread,

Mar 17, 2023, 8:51:23 AM3/17/23

to John Michael Edgware, swupdate

Hi John,

On 17.03.23 12:18, John Michael Edgware wrote:
> Hi Stefano,
>
> Thank you!
>
> About AES-CTR - I'm not saying it is the best way but it should work
> without changes in zchunk. AES-CTR allows random access and it does not
> have to be aligned to or to be multiple of AES block size. The

Ok- we have an encrypted zck file. Let's say we can decrypt the header.

> whole
> zchunk file can be encrypted without any regard to it's content and when
> individual chunk is downloaded

That is the point I do not understand. How can we get the offsets of the
chunk to be downloaded ? This works if the offsets are exactly the same
of the unencrypted ZCK file. But how this works, I am not yet understanding.

> it can be decrypted just by knowing AES

> key, IV and chunk offset, my quick guess in /network_process_data/
> before /zck_get_chunk_digest /by using /priv->rangestart/ as offset/./

The header contains offset and size, and each chunk can have odd
offsets. Let's see this example:

Chunk Start Comp size Size
0 557754 0 0
1 557754 413 73737
2 558167 173 131072

The offset in the file can have any possible value and it is not block
aligned. SWUpdate can then decrypt the header, but when download a chunk
should get a block in the middle and useless. What do I have not
understood ?

Best regards,
Stefano Babic

> https://groups.google.com/d/msgid/swupdate/44735c49-8e29-40ec-90f7-199155583352n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/44735c49-8e29-40ec-90f7-199155583352n%40googlegroups.com> <https://groups.google.com/d/msgid/swupdate/44735c49-8e29-40ec-90f7-199155583352n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/44735c49-8e29-40ec-90f7-199155583352n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> =====================================================================
> DENX Software Engineering GmbH, Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany

> Phone: +49-8142-66989-53 <tel:+49%208142%206698953> Fax:
> +49-8142-66989-80 <tel:+49%208142%206698980> Email: sba...@denx.de
> =====================================================================

>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/swupdate/228a1d7b-7824-48a2-aca7-34561446414bn%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/228a1d7b-7824-48a2-aca7-34561446414bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

John Michael Edgware

unread,

Mar 17, 2023, 2:29:24 PM3/17/23

to swupdate

Hi Stefano,

With CBC every new block depends on previous block, this requires sequential decryption and of course can't be used here.

However CTR is different - each encrypted block depends on incremental counter which later can be calculated from offset and block size.

Instead of encrypting plaintext directly, it encrypts IV combined with counter and then XORs it to plaintext or ciphertext.

CRT encryption of a block:

block_encrypt(key, IV + counter) ^ plaintext == ciphertext

CRT decryption of a block:

block_encrypt(key, IV + counter) ^ ciphertext == plaintext

This makes encrypted data random accessible because all we need is to calculate block_encrypt(key, IV + counter) for blocks that overlap our chunk, align bytes and do bytewise XOR.

John Michael Edgware

unread,

Mar 21, 2023, 7:41:12 AM3/21/23

to swupdate

Hi Stefano,

In case we want to avoid double copying of data - extract_files() in stream_interface.c must know some handler preferences to know if decryption is needed right there or it is done later by handler using copyimage().

Could it be with new flags parameter in register_handler() or is there a better way?

Stefano Babic

unread,

Mar 21, 2023, 8:51:40 AM3/21/23

to John Michael Edgware, swupdate

On 21.03.23 12:41, John Michael Edgware wrote:
> Hi Stefano,
>

> In case we want to avoid double copying of data - extract_files() in
> stream_interface.c must know some handler preferences to know if
> decryption is needed right there or it is done later by handler using
> copyimage().

Has something to do with the thread title, that is with zchunk ? If not,
do not steal the thread.

System is modular and each step should not know from next step - this is
how it is designed. And there is no double copy when stream is
activated, even in case of encrypted artifact. Parameter is passed to
the handler that calls copyimage(). And in case streaming is not
activated, double copy is requested.

> Could it be with new flags parameter in register_handler()

This is surely wrong - the handler should work with any artifact of a
specific type. Encryption can be decided on artifact base, and can be
activated / deactivated per update. It is not a global setup for the
handler.

Best regards,
Stefano Babic

> >
> > --
> >
> =====================================================================
> > DENX Software Engineering GmbH, Managing Director: Erika Unter
> > HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell,
> Germany
> > Phone: +49-8142-66989-53 <tel:+49%208142%206698953>
> <tel:+49%208142%206698953> Fax:
> > +49-8142-66989-80 <tel:+49%208142%206698980>
> <tel:+49%208142%206698980> Email: sba...@denx.de
> >
> =====================================================================
> >
> > --
> > You received this message because you are subscribed to the
> Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion on the web visit
> >

> https://groups.google.com/d/msgid/swupdate/228a1d7b-7824-48a2-aca7-34561446414bn%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/228a1d7b-7824-48a2-aca7-34561446414bn%40googlegroups.com> <https://groups.google.com/d/msgid/swupdate/228a1d7b-7824-48a2-aca7-34561446414bn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/228a1d7b-7824-48a2-aca7-34561446414bn%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> =====================================================================
> DENX Software Engineering GmbH, Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany

> Phone: +49-8142-66989-53 <tel:+49%208142%206698953> Fax:
> +49-8142-66989-80 <tel:+49%208142%206698980> Email: sba...@denx.de
> =====================================================================
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/swupdate/416ac1d8-e658-4330-9827-fcbcd2979ec8n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/416ac1d8-e658-4330-9827-fcbcd2979ec8n%40googlegroups.com?utm_medium=email&utm_source=footer>.

John Michael Edgware

unread,

Mar 21, 2023, 9:57:03 AM3/21/23

to swupdate

This is not stealing, this thread contains two zchunk topics :) It's about the fact that encrypted zchunk headers currently do not work. To the patch in the first message your answer was that we should avoid copying it again but the only place where copying occurs before zck_init_read() is copyfile() in extract_files(). Currently img->fdin in install_delta() is still encrypted and zck_init_read of course fails.

Stefano Babic

unread,

Mar 21, 2023, 10:32:37 AM3/21/23

to John Michael Edgware, swupdate

Hi John,

On 21.03.23 14:57, John Michael Edgware wrote:
> This is not stealing, this thread contains two zchunk topics :) It's
> about the fact that encrypted zchunk headers currently do not work. To
> the patch in the first message your answer was that we should avoid
> copying it again but the only place where copying occurs before
> zck_init_read() is copyfile() in extract_files(). Currently img->fdin in
> install_delta() is still encrypted and zck_init_read of course fails.

Ah, ok ! I understand now the context, and it is clear to me where we
are going. And I have misunderstood your patch, too.

For delta, that means in SWU we have just the header, streaming is
explicitly off. Header is always small, and there is no advantage having
as stream (see line 853-856). SWUpdate will then always extract from
cpio and put it into TMPDIR.

This is also for design, and just the handler should work with the
artifact - that means, it needs to run copyimage() and it is
automatically decrypted (or copyfile). So your patch was correct and I
have misunderstood, sorry, Nevertheless, patch is not in the right
format (commit message, signed-off-by, etc), and should be reqworked to
be taken by patchwork. But it is correct, you have to run copyfile() to
decrypt it and then pass it to zck_init_read(), that is the consumer of
the header. Sorry for misunderstanding.

> > >
> > > --
> > >
> >
> =====================================================================
> > > DENX Software Engineering GmbH, Managing Director: Erika Unter
> > > HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell,
> > Germany
> > > Phone: +49-8142-66989-53 <tel:+49%208142%206698953>
> <tel:+49%208142%206698953>
> > <tel:+49%208142%206698953> Fax:
> > > +49-8142-66989-80 <tel:+49%208142%206698980>
> <tel:+49%208142%206698980>
> > <tel:+49%208142%206698980> Email: sba...@denx.de
> > >
> >
> =====================================================================
> > >
> > > --
> > > You received this message because you are subscribed to the
> > Google
> > > Groups "swupdate" group.
> > > To unsubscribe from this group and stop receiving emails from
> > it, send
> > > an email to swupdate+u...@googlegroups.com
> > > <mailto:swupdate+u...@googlegroups.com>.
> > > To view this discussion on the web visit
> > >
> >

> >
> > --
> >
> =====================================================================
> > DENX Software Engineering GmbH, Managing Director: Erika Unter
> > HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany
> > Phone: +49-8142-66989-53 <tel:+49%208142%206698953>

> <tel:+49%208142%206698953> Fax:
> > +49-8142-66989-80 <tel:+49%208142%206698980>
> <tel:+49%208142%206698980> Email: sba...@denx.de
> >
> =====================================================================
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion on the web visit
> >

> https://groups.google.com/d/msgid/swupdate/416ac1d8-e658-4330-9827-fcbcd2979ec8n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/416ac1d8-e658-4330-9827-fcbcd2979ec8n%40googlegroups.com> <https://groups.google.com/d/msgid/swupdate/416ac1d8-e658-4330-9827-fcbcd2979ec8n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/416ac1d8-e658-4330-9827-fcbcd2979ec8n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> =====================================================================
> DENX Software Engineering GmbH, Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany

> Phone: +49-8142-66989-53 <tel:+49%208142%206698953> Fax:
> +49-8142-66989-80 <tel:+49%208142%206698980> Email: sba...@denx.de
> =====================================================================
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/swupdate/56a80e1a-312c-43a3-bb49-b1a9d0dbe106n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/56a80e1a-312c-43a3-bb49-b1a9d0dbe106n%40googlegroups.com?utm_medium=email&utm_source=footer>.

John Michael Edgware

unread,

Mar 22, 2023, 7:43:53 AM3/22/23

to swup...@googlegroups.com, John Michael Edgware

Signed-off-by: John Michael Edgware <sir...@gmail.com>
---
handlers/delta_handler.c | 38 ++++++++++++++++++++++++++++++++++++--
1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/handlers/delta_handler.c b/handlers/delta_handler.c
index e848f15..e078157 100644
--- a/handlers/delta_handler.c
+++ b/handlers/delta_handler.c
@@ -37,6 +37,7 @@
#include <pctl.h>
#include <pthread.h>
#include <fs_interface.h>
+#include <sys/mman.h>
#include "delta_handler.h"
#include "multipart_parser.h"
#include "installer.h"
@@ -840,7 +841,7 @@ static int install_delta(struct img_type *img,
{
struct hnd_priv *priv;
int ret = -1;

- int dst_fd = -1, in_fd = -1;
+ int dst_fd = -1, in_fd = -1, mem_fd = -1;

zckChunk *iter;
zckCtx *zckSrc = NULL, *zckDst = NULL;
char *FIFO = NULL;
@@ -965,7 +966,37 @@ static int install_delta(struct img_type *img,
zck_get_error(zckSrc));
goto cleanup;
}

- if (!zck_init_read(zckDst, img->fdin)) {
+

+ mem_fd = memfd_create("zchunk header", 0);

+ if (mem_fd == -1) {

+ ERROR("Cannot create memory file: %s", strerror(errno));

+ goto cleanup;
+ }
+
+ ret = copyfile(img->fdin,
+ &mem_fd,
+ img->size,
+ (unsigned long *)&img->offset,
+ img->seek,
+ 0,
+ img->compressed,
+ &img->checksum,
+ img->sha256,
+ img->is_encrypted,
+ img->ivt_ascii,
+ NULL);
+
+ if (ret != 0) {

+ ERROR("Error %d copying zchunk header, aborting.", ret);

+ goto cleanup;
+ }
+
+ if (lseek(mem_fd, 0, SEEK_SET) < 0) {

+ ERROR("Seeking start of memory file");

+ goto cleanup;
+ }
+

+ if (!zck_init_read(zckDst, mem_fd)) {

ERROR("Unable to read ZCK header from %s : %s",
img->fname,
zck_get_error(zckDst));
@@ -1020,6 +1051,8 @@ static int install_delta(struct img_type *img,
memset(priv_hnd->img.sha256, 0, SHA256_HASH_LENGTH);
strlcpy(priv_hnd->img.type, priv->chainhandler, sizeof(priv_hnd->img.type));
priv_hnd->img.fdin = pipes[PIPE_READ];

+ /* zchunk files are not encrypted, CBC is not suitable for range download */
+ priv_hnd->img.is_encrypted = false;

signal(SIGPIPE, SIG_IGN);

@@ -1064,6 +1097,7 @@ cleanup:
if (zckDst) zck_free(&zckDst);
close(dst_fd);
close(in_fd);
+ close(mem_fd);
if (FIFO) {
unlink(FIFO);
free(FIFO);
--

2.39.2.windows.1

Stefano Babic

unread,

Mar 26, 2023, 11:34:14 AM3/26/23

to John Michael Edgware, swup...@googlegroups.com

Ji John,

See report sent by coverity when upur patch is applied. mem_fd is
negative, and jumping to cleanup calls close() with a negative number.
This issue needs to be solved before applying.

Best regards,
Stefano Babic

John Michael Edgware

unread,

Mar 26, 2023, 11:46:37 AM3/26/23

to swupdate

Hi Stefano,

I usually don't do this even though close(-1) will silently fail with EBADF without any adverse effects, but I took example from close(dst_fd) and close(in_fd) which also lack -1 check.

Stefano Babic

unread,

Mar 26, 2023, 4:46:49 PM3/26/23

to John Michael Edgware, swupdate

Hi John,

On 26.03.23 17:46, John Michael Edgware wrote:
> Hi Stefano,
>
> I usually don't do this even though close(-1) will silently fail with
> EBADF without any adverse effects, but I took example from close(dst_fd)
> and close(in_fd) which also lack -1 check.

True - let's do in this way. I apply the patch, check for -1 can be done
in a follow up patch. Sometimes in code there is the check, sometimes not.

Regards,
Stefano

> Phone: +49-8142-66989-53 <tel:+49%208142%206698953> Fax:
> +49-8142-66989-80 <tel:+49%208142%206698980> Email: sba...@denx.de
> =====================================================================
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/swupdate/80cb66f5-45ff-44da-8af0-008bb3eed905n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/80cb66f5-45ff-44da-8af0-008bb3eed905n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Reply all

Reply to author

Forward

Message has been deleted