On 19.08.2026 19:49, Chuck Zmudzinski wrote: > On 8/19/2026 11:47 AM, Chuck Zmudzinski wrote: >> On 8/19/2026 9:51 AM, Jan Beulich wrote: >>> On 19.08.2026 14:36, Chuck Zmudzinski wrote: >>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote: >>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM >>>>> can get >>>>> a copy of the OpRegion and read its contents so most of this can be done >>>>> in the >>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch >>>>> will be more >>>>> about avoiding the layering violation than anything else. >>>> >>>> However, there is one advantage, from the viewpoint of the Xen >>>> virtualization platform >>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in >>>> the DM. >>>> >>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide >>>> a common >>>> solution for extended VBT support for Intel IGD devices that would be >>>> compatible with >>>> all DM implementations, not just with Qemu. So why not do the patching of >>>> the OpRegion >>>> in hvmloader? >>> >>> As indicated before: If the OpRegion holds data that is needed to drive the >>> device, and if the OpRegion is exposed writable to guests, then guest can >>> screw up that data such that subsequent guests won't work anymore. Hence >>> exposing to guests (which includes hvmloader) needs to be stopped, or at >>> least be limited to r/o. That, in fact, includes exposing to any privilege- >>> restricted DM as well. >>> >>> Exposing r/o may be entirely okay (i.e. may not be a layering violation), >>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui >>> it's not addressed by any of the BARs, yet it looks like it needs similar >>> treatment. Earlier on we also talked about the region not necessarily being >>> page-aligned. That poses, even with r/o exposure, the question of other >>> data on the same (leading / trailing) pages. This may imply that the >>> copying needs to be done strictly in Dom0, for both DM and guest to only >>> ever act on copies (which may then as well be r/w). >> >> Yes, I am thinking the DM should make a copy host OpRegion and never expose >> the host OpRegion to the guest but only a copy of it. >> >> The reason we need a patch like this is that with the introduction of the >> rvda/rvds fields into the OpRegion, the OpRegion is not always >> position-independent >> so its contents might be unsuitable in the guest address space, so in those >> cases >> we need to patch the copy of the OpRegion that will be exposed to the guest. >> If there is an extended VBT the DM will also get a copy of it, make a copy of >> it, and expose it to the guest by appending it contiguous with the OpRegion. >> Since in this scenario we are assuming the DM knows the contents of the >> OpRegion, >> then it can find the host VBT and make a copy of it without needing hvmloader >> to send the rvda and rvds values to it. >> >> Then, the remaining question is which component (DM or hvmloader) will patch >> it >> if it needs to be patched to make the guest's copy of it compatible with the >> guest >> address space. > > As I noted earlier, it think it would be advantageous for the Xen platform as > whole > for the patching to be done in hvmloader. That way, support for extended VBT > is > automatically added for all implementations of the DM, not just for Qemu. But > the > downside is that for hvmloader to do the patching, it needs to know the host > OpRegion > address, which one could argue it should not need to know. This is the only > reason I > can think of to do the patching of the OpRegion in the DM instead of in > hvmloader: to > avoid disclosing the host OpRegion address to the guest. > > But we trust hvmloader, don't we, to not abuse this knowledge of the host's > OpRegion > address?
No, we cannot (fully) trust hvmloader. Jan > The point is, hvmloader will discard the host OpRegion address and not > disclose it to guest firmware (ovmf/seabios) nor to the bootloader or guest > OS, so > I think the advantage of adding support for extended VBT to all DMs that rely > on > hvmloader outweighs the risk of disclosing the host OpRegion to the guest > (hvmloader, > which, for security reasons, should not disclose it to ovmf or seabios). > > Chuck
