On Tue, 2023-01-10 at 16:30 -0800, Hansen, Dave wrote: > On 1/10/23 16:13, Huang, Kai wrote: > > On Tue, 2023-01-10 at 07:27 -0800, Dave Hansen wrote: > ... > > > Think about it this way: kexec() is modifying persistent (across kexec) > > > state to get the system ready for the new kernel. The caches are > > > persistent state. Devices have persistent state. Memory state persists > > > across kexec(). The memory integrity metadata persists. > > > > > > What persistent state does a conversion to KeyID-0 affect? It resets > > > the integrity metadata and the memory contents. > > > > > > Kexec leaves memory contents in place and doesn't zero them, so memory > > > contents don't matter. The integrity metadata also doesn't matter > > > because the memory will be used as KeyID-0 and that KeyID doesn't read > > > the integrity metadata. > > > > Right. So I guess we just need to call out the new kernel will use memory as > > KeyID-0? > > Not even that. > > Say the new kernel wanted to use the memory as KeyID-3. What would it > do? It would *ASSUME* that the memory *WASN'T* KeyID-3. It would > convert it to KeyID-3. That conversion would work from *any* KeyID. > > So: > > KeyID-0: OK, because it has no integrity enforcement > KeyID-1: OK, new kernel will convert the page > KeyID-2: OK, new kernel will convert the page > ... > KeyID-$MAX: OK, new kernel will convert the page > > So, "OK" everywhere. Nothing to do... anywhere. > > Either I'm totally missing how this works, or you're desperately trying > to make this more complicated than it is. > You are right. The page conversion must do MOVDIR64B first even converting the page from KeyID 0. I was wrongly thinking when converting from KeyID 0 we don't need to do MOVDIR64B. My bad. Sorry for the noise. Thanks for your time. I'll remove all those staff.
