On Mon, Jul 19, 2021 at 10:17 PM Andi Kleen [off-list ref] 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.

quoted

quoted

quoted

Also in general i don't think it will really happen, at least

initially.

quoted

quoted

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

quoted

quoted

quoted

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