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. > > 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
