Re: [PATCH RFC v2 3/3] x86/altp2m: p2m_altp2m_propagate_change() should honor present page order

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

> Hmm, I continue to be puzzled. Let's take the XSA-304 workaround as an
> example. Suppose an introspection agent has removed X from a 4k page
> in an altp2m of a guest. Suppose one of the vCPU-s of this guest runs
> on the host p2m. If this vCPU hits the (presumably) 2M or 1G mapping
> covering said 4k page for an insn fetch, the page will be shattered
> and the removed X in one (or more) of the altp2m-s will, afaict, be
> lost. This looks like a bug to me.

Yeap, that can happen if you are using large pages and allow execution
on the hosp2m. We explicitly disable large pages when we use altp2m's
though so it's not an issue for us. Someone implementing an
introspection solution where they keep large pages would have to
pre-shatter all the large pages in the hostp2m and only then apply the
altp2m changes. Or have a separate altp2m view that's used only for
execution and the hostp2m is never used. So the way things are can
certainly be worked with and it's not a show-stopper, it's just
convoluted and you can certainly have bugs if you do it wrong that
would be hard to figure out.

As I said, I don't see much upside in why the current propagation
mechanism is in place and we don't use it, so if someone wants to
switch it because of preference or because it's less error-prone, I
wouldn't object.

Tamas