| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CA+CK2bC_z_6hgYu_qB7cBK2LrBSs8grjw7HCC+QrtUSrFuN5ZQ@mail.gmail.com>
Date: Mon, 17 Nov 2025 10:09:28 -0500
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Mike Rapoport <rppt@...nel.org>
Cc: pratyush@...nel.org, jasonmiu@...gle.com, graf@...zon.com,
dmatlack@...gle.com, rientjes@...gle.com, corbet@....net,
rdunlap@...radead.org, ilpo.jarvinen@...ux.intel.com, kanie@...ux.alibaba.com,
ojeda@...nel.org, aliceryhl@...gle.com, masahiroy@...nel.org,
akpm@...ux-foundation.org, tj@...nel.org, yoann.congal@...le.fr,
mmaurer@...gle.com, roman.gushchin@...ux.dev, chenridong@...wei.com,
axboe@...nel.dk, mark.rutland@....com, jannh@...gle.com,
vincent.guittot@...aro.org, hannes@...xchg.org, dan.j.williams@...el.com,
david@...hat.com, joel.granados@...nel.org, rostedt@...dmis.org,
anna.schumaker@...cle.com, song@...nel.org, linux@...ssschuh.net,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, linux-mm@...ck.org,
gregkh@...uxfoundation.org, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
rafael@...nel.org, dakr@...nel.org, bartosz.golaszewski@...aro.org,
cw00.choi@...sung.com, myungjoo.ham@...sung.com, yesanishhere@...il.com,
Jonathan.Cameron@...wei.com, quic_zijuhu@...cinc.com,
aleksander.lobakin@...el.com, ira.weiny@...el.com,
andriy.shevchenko@...ux.intel.com, leon@...nel.org, lukas@...ner.de,
bhelgaas@...gle.com, wagi@...nel.org, djeffery@...hat.com,
stuart.w.hayes@...il.com, ptyadav@...zon.de, lennart@...ttering.net,
brauner@...nel.org, linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org,
saeedm@...dia.com, ajayachandra@...dia.com, jgg@...dia.com, parav@...dia.com,
leonro@...dia.com, witu@...dia.com, hughd@...gle.com, skhawaja@...gle.com,
chrisl@...nel.org
Subject: Re: [PATCH v6 04/20] liveupdate: luo_session: add sessions support
> > +/**
> > + * struct luo_session_ser - Represents the serialized metadata for a LUO session.
> > + * @name: The unique name of the session, copied from the `luo_session`
> > + * structure.
>
> I'd phase it as
>
> The unique name of the session provided by the userspace at
> the time of session creation.
Done
>
> > + * @files: The physical address of a contiguous memory block that holds
> > + * the serialized state of files.
>
> Maybe add ^ in this session?
Done
>
> > + * @pgcnt: The number of pages occupied by the `files` memory block.
> > + * @count: The total number of files that were part of this session during
> > + * serialization. Used for iteration and validation during
> > + * restoration.
> > + *
> > + * This structure is used to package session-specific metadata for transfer
> > + * between kernels via Kexec Handover. An array of these structures (one per
> > + * session) is created and passed to the new kernel, allowing it to reconstruct
> > + * the session context.
> > + *
> > + * If this structure is modified, LUO_SESSION_COMPATIBLE must be updated.
>
> This comment applies to the luo_session_header_ser description as well.
Done
>
> > + */
> > +struct luo_session_ser {
> > + char name[LIVEUPDATE_SESSION_NAME_LENGTH];
> > + u64 files;
> > + u64 pgcnt;
> > + u64 count;
> > +} __packed;
> > +
> > #endif /* _LINUX_LIVEUPDATE_ABI_LUO_H */
> > diff --git a/include/uapi/linux/liveupdate.h b/include/uapi/linux/liveupdate.h
> > index df34c1642c4d..d2ef2f7e0dbd 100644
> > --- a/include/uapi/linux/liveupdate.h
> > +++ b/include/uapi/linux/liveupdate.h
> > @@ -43,4 +43,7 @@
> > /* The ioctl type, documented in ioctl-number.rst */
> > #define LIVEUPDATE_IOCTL_TYPE 0xBA
> >
> > +/* The maximum length of session name including null termination */
> > +#define LIVEUPDATE_SESSION_NAME_LENGTH 56
>
> You decided not to bump it to 64 in the end? ;-)
I bumped it to 64, but in the next patch, I will fix it in the next version.
>
> > +
> > #endif /* _UAPI_LIVEUPDATE_H */
> > diff --git a/kernel/liveupdate/Makefile b/kernel/liveupdate/Makefile
> > index 413722002b7a..83285e7ad726 100644
> > --- a/kernel/liveupdate/Makefile
> > +++ b/kernel/liveupdate/Makefile
> > @@ -2,7 +2,8 @@
> >
> > luo-y := \
> > luo_core.o \
> > - luo_ioctl.o
> > + luo_ioctl.o \
> > + luo_session.o
> >
> > obj-$(CONFIG_KEXEC_HANDOVER) += kexec_handover.o
> > obj-$(CONFIG_KEXEC_HANDOVER_DEBUG) += kexec_handover_debug.o
>
> ...
>
> > +int luo_session_retrieve(const char *name, struct file **filep)
> > +{
> > + struct luo_session_header *sh = &luo_session_global.incoming;
> > + struct luo_session *session = NULL;
> > + struct luo_session *it;
> > + int err;
> > +
> > + scoped_guard(rwsem_read, &sh->rwsem) {
> > + list_for_each_entry(it, &sh->list, list) {
> > + if (!strncmp(it->name, name, sizeof(it->name))) {
> > + session = it;
> > + break;
> > + }
> > + }
> > + }
> > +
> > + if (!session)
> > + return -ENOENT;
> > +
> > + scoped_guard(mutex, &session->mutex) {
> > + if (session->retrieved)
> > + return -EINVAL;
> > + }
> > +
> > + err = luo_session_getfile(session, filep);
> > + if (!err) {
> > + scoped_guard(mutex, &session->mutex)
> > + session->retrieved = true;
>
> Retaking the mutex here seems a bit odd.
> Do we really have to lock session->mutex in luo_session_getfile()?
Moved it out of luo_session_getfile(), and added
lockdep_assert_held(&session->mutex); to luo_session_getfile
> > +int luo_session_deserialize(void)
> > +{
> > + struct luo_session_header *sh = &luo_session_global.incoming;
> > + int err;
> > +
> > + if (luo_session_is_deserialized())
> > + return 0;
> > +
> > + luo_session_global.deserialized = true;
> > + if (!sh->active) {
> > + INIT_LIST_HEAD(&sh->list);
> > + init_rwsem(&sh->rwsem);
> > + return 0;
>
> How this can happen? luo_session_deserialize() is supposed to be called
> from ioctl and luo_session_global.incoming should be set up way earlier.
No LUO was passed from the previous kernel, so
luo_session_global.incoming.active stays false, as it is not
participating.
> And, why don't we initialize ->list and ->rwsem statically?
Good idea, done.
> > + }
> > +
> > + for (int i = 0; i < sh->header_ser->count; i++) {
> > + struct luo_session *session;
> > +
> > + session = luo_session_alloc(sh->ser[i].name);
> > + if (IS_ERR(session)) {
> > + pr_warn("Failed to allocate session [%s] during deserialization %pe\n",
> > + sh->ser[i].name, session);
> > + return PTR_ERR(session);
> > + }
>
> The allocated sessions still need to be freed if an insert fails ;-)
No. We have failed to deserialize, so anyways the machine will need to
be rebooted by the user in order to release the preserved resources.
This is something that Jason Gunthrope also mentioned regarding IOMMU:
if something is not correct (i.e., if a session cannot finish for some
reason), don't add complicated "undo" code that cleans up all
resources. Instead, treat them as a memory leak and allow a reboot to
perform the cleanup.
While in this particular patch the clean-up looks simple, later in the
series we are adding file deserialization to each session to this
function. So, the clean-up will look like this: we would have to free
the resources for each session we deserialized, and also free the
resources for files that were deserialized for those sessions, only to
still boot into a "maintenance" mode where bunch of resources are not
accessible from which the machine would have to be rebooted to get
back to a normal state. This code will never be tested, and never be
used, so let's use reboot to solve this problem, where devices are
going to be properly reset, and memory is going to be properly freed.
Powered by blists - more mailing lists