[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH RFC v2 3/3] x86/altp2m: p2m_altp2m_propagate_change() should honor present page order
> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |