On Fri, Oct 24, 2025 at 10:55 AM Jason Gunthorpe jgg@ziepe.ca wrote:
On Fri, Oct 24, 2025 at 10:36:45AM -0400, Pasha Tatashin wrote:
We do not zero memory on kexec/KHO/LU; instead, the next kernel zeroes memory on demand during allocation. My point is that the KHO interface retrieves a full page in the next kernel, not an individual slab. Consequently, a caller might retrieve data that was preserved as a slab in the previous kernel, expose that data to the user, and unintentionally leak the remaining part of the page as well.
I don't think preventing that is part of the kho threat model..
There's also the inefficiency. The unpreserved parts of that page are unusable by the new kernel until the preserved object is freed.
Thats not how I see slab preservation working. When the slab page is unpreserved all the free space in that page should be immediately available to the sucessor kernel.
This ties into the same problem. The scenario I'm worried about is:
- A caller preserves one small slab object.
- In the new kernel, the caller retrieves the entire page that
contains this object. 3. The caller uses the data from that slab object without freeing it.
- When slab restores the page it immediately makes all the free slots
available on its free list.
Right, we do not have this functionality.
other patches are small and allocating a whole page is pretty wasteful too.
If we're going to support this, it would have to be specifically engineered as full slab support for KHO preservation, where the interface retrieves slab objects directly, not the pages they're on,
Yes
and I think would require using a special GFP_PRESERVED flag.
Maybe so, I was hoping not..
Jason