On Mon, Jul 19, 2021 at 10:17 PM Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote: > > First I suspect for crash it's not a real security problem if a > malicious hypervisor would inject zeroed pages. That means actual strong > checks against revalidation/reaccept are not needed. That still leaves > the issue of triggering an exception when the memory is not there. TDX > has an option to trigger a #VE in this case, but we will actually force > disable it to avoid #VE in the system call gap. But the standard crash > dump tools already know how to parse mem_map to distinguish different > types of pages. So they already would be able to do that. We just need > some kind of safety mechanism to prevent any crashes, but that should be > doable. Actually I'm not sure they're really needed because that's a > root operation. Just to make sure that I am not confused. We are talking about a scenario where no private/shared page mapping is transferred between normal kernel and crash kernel. It is very hard to identify a security issue without seeing an implementation but if the crash kernel does not revalidate the memory, it might use a memory which was not accepted before (for example a previously shared page) and then it needs to handle EPT-violation #VE to accept it and now the content is gone. - assuming that we want to dump all the pages. I might be missing something obvious here but I am not sure how to crash kernel dumps all the memory when #VE handler is disabled or without having some private/shared page mapping. Once you have that #VE handler to accept pages, then VMM can inject zeroed pages to any location unless the guest keeps track of what has been accepted before. > > >> Also in general i don't think it will really happen, at least > > initially. > > >> All the shared buffers we use are allocated and never freed. So such a > > >> problem could be deferred. > > > > Does it not depend on kernel configs? Currently, there is a valid > > control path in dma_alloc_coherent which might alloc and free shared > > pages. > > If the device filter is active it won't. > If I am not missing something, I do not see that the device filter checks for CONFIG_DMA_COHERENT_POOL and if it is not enabled, dma_alloc_coherent will allocate a regular memory, convert it to shared and convert it back to private when it is freed. -Erdem > > >> At the risk of asking a potentially silly question, would it be > > >> reasonable to treat non-validated memory as not-present for kernel > > >> purposes and hot-add it in a thread as it gets validated? > > > > My concern with this is, it assumes that all the present memory is > > private. UEFI might have some pages which are shared therefore also > > are present. > > > Hot add is nearly always a bad idea. > > > -Andi > > >
