[PATCH] tools/xenstored: Propagate correctly the error message from lu_start()

[PATCH] tools/xenstored: Propagate correctly the error message from lu_start()

[Julien Grall]

From: Julien Grall <jgrall@amazon.com>

lu_start() will only set errno when it returns NULL. For all the
other cases, the value is unknown.

This means that when lu_start() returns an error message, it may not
be propagated to the client.

The check that errno is a non-zero value is now dropped and instead
the value is returned when no error message is provided. This
relies on errno to always be set when ret == NULL.

Fixes: af216a99fb ("tools/xenstore: add the basic framework for doing the live update")
Signed-off-by: Julien Grall <jgrall@amazon.com>
---
 tools/xenstore/xenstored_control.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/xenstore/xenstored_control.c b/tools/xenstore/xenstored_control.c
index ff9863c17fa4..6b68b79faac7 100644
--- a/tools/xenstore/xenstored_control.c
+++ b/tools/xenstore/xenstored_control.c
@@ -795,10 +795,8 @@ static int do_control_lu(void *ctx, struct connection *conn,
 				return EINVAL;
 		}
 		ret = lu_start(ctx, conn, force, to);
-		if (errno)
-			return errno;
 		if (!ret)
-			return 0;
+			return errno;
 	} else {
 		errno = 0;
 		ret = lu_arch(ctx, conn, vec, num);
-- 
2.17.1

Re: [PATCH] tools/xenstored: Propagate correctly the error message from lu_start()

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 701 bytes --]

On 29.07.21 13:06, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> lu_start() will only set errno when it returns NULL. For all the
> other cases, the value is unknown.
> 
> This means that when lu_start() returns an error message, it may not
> be propagated to the client.
> 
> The check that errno is a non-zero value is now dropped and instead
> the value is returned when no error message is provided. This
> relies on errno to always be set when ret == NULL.
> 
> Fixes: af216a99fb ("tools/xenstore: add the basic framework for doing the live update")
> Signed-off-by: Julien Grall <jgrall@amazon.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[PATCH] tools/xenstored: Fix off-by-one in dump_state_nodes()

[Julien Grall]

From: Julien Grall <jgrall@amazon.com>

The maximum path length supported by Xenstored protocol is
XENSTORE_ABS_PATH_MAX (i.e 3072). This doesn't take into account the
NUL at the end of the path.

However, the code to dump the nodes will allocate a buffer
of XENSTORE_ABS_PATH. As a result it may not be possible to live-update
if there is a node name of XENSTORE_ABS_PATH.

Fix it by allocating a buffer of XENSTORE_ABS_PATH_MAX + 1 characters.

Take the opportunity to pass the max length of the buffer as a
parameter of dump_state_node_tree(). This will be clearer that the
check in the function is linked to the allocation in dump_state_nodes().

Signed-off-by: Julien Grall <jgrall@amazon.com>

---

This was spotted when backporting Live-Update to 4.11 because the
commit 924bf8c793 "tools/xenstore: rework path length check" is
not present. On the latest upstream, this is looks more a latent bug
because I didn't manage to create such large node.

(4.11)

42sh# xenstore-write $(python -c "print('/' + 'A' * 3071)") ""
42sh# xenstore-control live-update /usr/local/sbin/xenstored
Starting live update failed:
Dump node path length error
---
 tools/xenstore/xenstored_core.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 16c856730c55..0d4c73d6e20c 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -2574,7 +2574,8 @@ const char *dump_state_node_perms(FILE *fp, const struct xs_permissions *perms,
 	return NULL;
 }
 
-static const char *dump_state_node_tree(FILE *fp, char *path)
+static const char *dump_state_node_tree(FILE *fp, char *path,
+					unsigned int path_max_len)
 {
 	unsigned int pathlen, childlen, p = 0;
 	struct xs_state_record_header head;
@@ -2642,10 +2643,10 @@ static const char *dump_state_node_tree(FILE *fp, char *path)
 	}
 	while (p < hdr->childlen) {
 		childlen = strlen(child) + 1;
-		if (pathlen + childlen > XENSTORE_ABS_PATH_MAX)
+		if (pathlen + childlen > path_max_len)
 			return "Dump node path length error";
 		strcpy(path + pathlen, child);
-		ret = dump_state_node_tree(fp, path);
+		ret = dump_state_node_tree(fp, path, path_max_len);
 		if (ret)
 			return ret;
 		p += childlen;
@@ -2661,13 +2662,13 @@ const char *dump_state_nodes(FILE *fp, const void *ctx)
 {
 	char *path;
 
-	path = talloc_size(ctx, XENSTORE_ABS_PATH_MAX);
+	path = talloc_size(ctx, XENSTORE_ABS_PATH_MAX + 1);
 	if (!path)
 		return "Path buffer allocation error";
 
 	strcpy(path, "/");
 
-	return dump_state_node_tree(fp, path);
+	return dump_state_node_tree(fp, path, XENSTORE_ABS_PATH_MAX + 1);
 }
 
 void read_state_global(const void *ctx, const void *state)
-- 
2.17.1

Re: [PATCH] tools/xenstored: Fix off-by-one in dump_state_nodes()

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 1223 bytes --]

On 29.07.21 11:34, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> The maximum path length supported by Xenstored protocol is
> XENSTORE_ABS_PATH_MAX (i.e 3072). This doesn't take into account the
> NUL at the end of the path.
> 
> However, the code to dump the nodes will allocate a buffer
> of XENSTORE_ABS_PATH. As a result it may not be possible to live-update
> if there is a node name of XENSTORE_ABS_PATH.
> 
> Fix it by allocating a buffer of XENSTORE_ABS_PATH_MAX + 1 characters.
> 
> Take the opportunity to pass the max length of the buffer as a
> parameter of dump_state_node_tree(). This will be clearer that the
> check in the function is linked to the allocation in dump_state_nodes().
> 
> Signed-off-by: Julien Grall <jgrall@amazon.com>

Reviewed-by: Juergen Gross <jgross@suse.com>

> 
> ---
> 
> This was spotted when backporting Live-Update to 4.11 because the
> commit 924bf8c793 "tools/xenstore: rework path length check" is
> not present. On the latest upstream, this is looks more a latent bug
> because I didn't manage to create such large node.

Yes, the path length is limited to "/local/domain/<id>/" + the max
relative path length.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH] tools/xenstored: Fix off-by-one in dump_state_nodes() [and 3 more messages]

[Ian Jackson]

Julien Grall writes ("[PATCH] tools/xenstored: Fix off-by-one in dump_state_nodes()"):
> The maximum path length supported by Xenstored protocol is
> XENSTORE_ABS_PATH_MAX (i.e 3072). This doesn't take into account the
> NUL at the end of the path.
...

Julien Grall writes ("[PATCH] tools/xenstored: Propagate correctly the error message from lu_start()"):
> lu_start() will only set errno when it returns NULL. For all the
> other cases, the value is unknown.

Thanks, and to Juergen for the reviews.  Pushed.

Ian.