Thank you so much for your answer and sorry for keeping the discussion long. On Tue, Jul 20, 2021 at 3:01 PM Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote: > You mean when the TDVF is changed? In this case the unaccepted memory > will be a different memory type, so not lazy accept enabled kernels wouldn't > use it. Thanks Andi for the clarification. I also saw the Kirill's answer. It makes sense. > But for the kexec crash case it would be just attacks against the crash > dump, which I assume are not a real security concern. If the crash kernel is compromised, it can be used to dump the customer memory content to a shared location which is a real security concern, is it not? > The crash kexec > mostly runs in its own memory, which doesn't need this, or is small > enough that it can be fully pre-accepted. And for the previous memory > view probably these issues are acceptable. I think this is where I am getting confused. I agree that we can copy the crashkernel to its own memory (all accepted) and run it. My confusion is: crash kernel will dump the memory which might have some shared pages between. we have 3 options: 1- We can either accept all the pages again, that includes the shared pages and lose the content of it. If we do not care about the content in shared pages, then this is okay. 2- Have a mechanism to transfer the private/shared page mapping and map all the pages accordingly before dumping. 3- Have a #VE handler and to accept the pages on the flight or identify if it is a shared page based on EPT-violation #VE information. I am not sure what crash kernel can do when it accesses a previously shared page (no SEPT entry) as private with the lack of one of the above options or similar one. > > We actually plan to disable those #VEs, to avoid any problems with > the system call gap. Instead the plan is that the kernel will know > in advance what memory has been accepted or not, and accept it before > touching. Make sense. Thanks Andi. -Erdem
