[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0
On Mon, Aug 28, 2017 at 06:18:13AM +0000, Tian, Kevin wrote: > > From: Roger Pau Monne [mailto:roger.pau@xxxxxxxxxx] > > Sent: Friday, August 25, 2017 9:59 PM > > > > On Fri, Aug 25, 2017 at 06:25:36AM -0600, Jan Beulich wrote: > > > >>> On 25.08.17 at 14:15, <roger.pau@xxxxxxxxxx> wrote: > > > > On Wed, Aug 23, 2017 at 02:16:38AM -0600, Jan Beulich wrote: > > > >> >>> On 22.08.17 at 15:54, <roger.pau@xxxxxxxxxx> wrote: > > > >> > On Tue, Aug 22, 2017 at 06:26:23AM -0600, Jan Beulich wrote: > > > >> >> >>> On 11.08.17 at 18:43, <roger.pau@xxxxxxxxxx> wrote: > > > >> >> > --- a/xen/arch/x86/dom0_build.c > > > >> >> > +++ b/xen/arch/x86/dom0_build.c > > > >> >> > @@ -440,6 +440,10 @@ int __init > > dom0_setup_permissions(struct domain *d) > > > >> >> > rc |= rangeset_add_singleton(mmio_ro_ranges, mfn); > > > >> >> > } > > > >> >> > > > > >> >> > + /* For PVH prevent access to the MMCFG areas. */ > > > >> >> > + if ( dom0_pvh ) > > > >> >> > + rc |= pci_mmcfg_set_domain_permissions(d); > > > >> >> > > > >> >> What about ones reported by Dom0 later on? Which then raises the > > > >> >> question whether ... > > > >> > > > > >> > This should be dealt with in the PHYSDEVOP_pci_mmcfg_reserved > > handler. > > > >> > But since you propose to do white listing, I guess it doesn't matter > > > >> > that much anymore. > > > >> > > > >> Well, a fundamental question is whether white listing would work in > > > >> the first place. I could see room for severe problems e.g. with ACPI > > > >> methods wanting to access MMIO that's not described by any PCI > > > >> devices' BARs. Typically that would be regions in the chipset which > > > >> firmware is responsible for configuring/managing, the addresses of > > > >> which can be found/set in custom config space registers. > > > > > > > > The question would also be what would Xen allow in such white-listing. > > > > Obviously you can get to map the same using both white-list and > > > > black-listing (see below). > > > > > > Not really - what you've said there regarding MMCFG regions is > > > a clear indication that we should _not_ map reserved regions, i.e. > > > it would need to be full white listing with perhaps just the PCI > > > device BARs being handled automatically. > > > > I've tried just mapping the BARs and that sadly doesn't work, the box > > hangs after the IOMMU is enabled: > > > > [...] > > (XEN) [VT-D]d0:PCI: map 0000:3f:13.5 > > (XEN) [VT-D]d0:PCI: map 0000:3f:13.6 > > (XEN) [VT-D]iommu_enable_translation: iommu->reg = ffff82c00021b000 > > > > I will park this ATM and leave it for the Intel guys to diagnose. > > > > For the reference, the specific box I'm testing ATM has a Xeon(R) CPU > > E5-1607 0 @ 3.00GHz and a C600/X79 chipset. > > > > +Chao who can help check whether we have such a box at hand. > > btw please also give your BIOS version. It's a Precision T3600 BIOS A14. Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |