On Fri, Oct 24, 2025 at 10:55 AM Jason Gunthorpe <[email protected]> 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: > > 1. A caller preserves one small slab object. > > 2. 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. > > 4. 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
