Re: [PATCH v2 2/6] x86/HVM: restrict guest-induced WBINVD to cache writeback

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, May 14, 2025 at 02:46:32PM +0200, Jan Beulich wrote:
> On 14.05.2025 13:30, Roger Pau Monné wrote:
> > On Tue, May 13, 2025 at 03:54:56PM +0200, Jan Beulich wrote:
> >> On 13.05.2025 15:41, Roger Pau Monné wrote:
> >>> It's my understanding that the same is possible on native, as the CPU
> >>> might speculatively pull lines into the cache.  So there's no reason
> >>> for an OS to use wbinvd if wbnoinvd is available?
> >>
> >> Speculatively pulling data into the cache is possible only when page
> >> table entries permit caching. Hence after changing all mappings of a
> >> certain page to UC, an OS may have a need to ensure that no data of
> >> this page is left in any cache (and it can't be pulled back in
> >> speculatively then).
> > 
> > Is this realistic taking into account the OS is running virtualized?
> > 
> > At least with Xen there's the direct map, so once context is switched
> > back to Xen (for example to execute the wbinvd itself) there's no
> > guarantee the CPU won't speculatively populate the cache with entries
> > from the direct map.
> 
> Well, we've been knowing for a long time that we're not doing things fully
> correctly there. Once a guest has changed all mappings of a page it owns,
> we ought to make the direct map one follow suit (or simply unmap it from
> there).

Keeping track of guests mappings seems extremely complicated - maybe
doable for PV, but not for HVM with HAP I would think?

Also we would need to do something similar if guest enables CR0.CD and
switch all the direct map entries to uncached?

Address Space Isolation (and the removal of the direct map) might
solve part of this, but still I don't think we can fully guarantee Xen
won't have any mapping of guest pages with a different set of cache
attributes.

Thanks, Roger.