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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251018223620.GD1034710.vipinsh@google.com>
Date: Sat, 18 Oct 2025 15:36:20 -0700
From: Vipin Sharma <vipinsh@...gle.com>
To: Lukas Wunner <lukas@...ner.de>
Cc: bhelgaas@...gle.com, alex.williamson@...hat.com,
	pasha.tatashin@...een.com, dmatlack@...gle.com, jgg@...pe.ca,
	graf@...zon.com, pratyush@...nel.org, gregkh@...uxfoundation.org,
	chrisl@...nel.org, rppt@...nel.org, skhawaja@...gle.com,
	parav@...dia.com, saeedm@...dia.com, kevin.tian@...el.com,
	jrhilke@...gle.com, david@...hat.com, jgowans@...zon.com,
	dwmw2@...radead.org, epetron@...zon.de, junaids@...gle.com,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	kvm@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [RFC PATCH 15/21] PCI: Make PCI saved state and capability
 structs public

On 2025-10-18 09:17:33, Lukas Wunner wrote:
> On Fri, Oct 17, 2025 at 05:07:07PM -0700, Vipin Sharma wrote:
> > Move struct pci_saved_state{} and struct pci_cap_saved_data{} to
> > linux/pci.h so that they are available to code outside of the PCI core.
> > 
> > These structs will be used in subsequent commits to serialize and
> > deserialize PCI state across Live Update.
> 
> That's not sufficient as a justification to make these public in my view.
> 
> There are already pci_store_saved_state() and pci_load_saved_state()
> helpers to serialize PCI state.  Why do you need anything more?
> (Honest question.)
> 

In LUO ecosystem, currently,  we do not have a solid solution to do
proper serialization/deserialization of structs along with versioning
between different kernel versions. This work is still being discussed.

Here, I created separate structs (exactly same as the original one) to
have little bit control on what gets saved in serialized state and
correctly gets deserialized after kexec.

For example, if I am using existing structs and not creating my own
structs then I cannot just do a blind memcpy() between whole of the PCI state
prior to kexec to PCI state after the kexec. In the new kernel
layout might have changed like addition or removal of a field.

Having __packed in my version of struct, I can build validation like
hardcoded offset of members. I can add version number (not added in this
series) for checking compatbility in the struct for serialization and
deserialization. Overall, it is providing some freedom to how to pass
data to next kernel without changing or modifying the PCI state structs.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ