[PATCH v4 01/13] liveupdate: change file_set->count type to u64 for type safety
Pasha Tatashin
pasha.tatashin at soleen.com
Sun May 31 06:35:48 PDT 2026
On 05-30 22:19, Pasha Tatashin wrote:
> This improves type safety and aligns the in-memory file_set->count with
> the serialized count type. It avoids potential truncation or sign
> conversion mismatch issues.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin at soleen.com>
> ---
> kernel/liveupdate/luo_internal.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/liveupdate/luo_internal.h b/kernel/liveupdate/luo_internal.h
> index dd53d4a7277e..ae58206f14ac 100644
> --- a/kernel/liveupdate/luo_internal.h
> +++ b/kernel/liveupdate/luo_internal.h
> @@ -52,7 +52,7 @@ static inline int luo_ucmd_respond(struct luo_ucmd *ucmd,
> struct luo_file_set {
> struct list_head files_list;
> struct luo_file_ser *files;
> - long count;
> + u64 count;
>From Sashiko 1:
...
Since FLBs use a single contiguous block for serialization, an untrusted
KHO payload could provide an abnormally large count.
...
Answer: NO, there is a chain of trust during live update. The previous
kernel acts as a boot loader for the next kernel, and performs all the
necessary verifications. We trust the previous kernel to pass the right
things if compatability strings and format matches. KHO payload has the
same trust as the previous kernel.
Therefore, we assume the serialized metadata is well-formed and valid.
Defending against a malicious or hostile KHO payload is outside the
threat model of this system.
>From Sashiko 2:
...
If luo_session_finish_one() fails (for example, if a file handler returns
-EBUSY), the early return skips luo_session_remove() and
luo_session_free(). Since this is called during the VFS release operation
via fput(), VFS will unconditionally destroy the file descriptor regardless
of the return value.
...
Answer: NO. A finish failure means that we cannot safely release
resources, as they might be associated with devices and DMA activity. We
deliberately leak these resources to avoid memory corruption and data
leaks. When userspace fails to finish properly and closes the session,
the only way to recover these resources is to perform a cold reboot or
another live update.
> };
>
> /**
> --
> 2.53.0
>
More information about the kexec
mailing list