linux-kernel - Re: [PATCH 2/2] PCI: vmd: Fix shadow offsets to reflect spec changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <087e23dc3bb7b94bb96c33b380732ebd1285e467.camel@intel.com>
Date:   Tue, 17 Sep 2019 14:45:03 +0000
From:   "Derrick, Jonathan" <jonathan.derrick@...el.com>
To:     "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Busch, Keith" <keith.busch@...el.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "helgaas@...nel.org" <helgaas@...nel.org>
Subject: Re: [PATCH 2/2] PCI: vmd: Fix shadow offsets to reflect spec changes

On Tue, 2019-09-17 at 15:05 +0100, Lorenzo Pieralisi wrote:
> On Tue, Sep 17, 2019 at 01:55:59PM +0000, Derrick, Jonathan wrote:
> > On Tue, 2019-09-17 at 11:41 +0100, Lorenzo Pieralisi wrote:
> > > On Mon, Sep 16, 2019 at 07:54:35AM -0600, Jon Derrick wrote:
> > > > The shadow offset scratchpad was moved to 0x2000-0x2010. Update the
> > > > location to get the correct shadow offset.
> > > 
> > > Hi Jon,
> > > 
> > > what does "was moved" mean ? Would this code still work on previous HW ?
> > > 
> > The previous code won't work on (not yet released) hw. Guests using the
> > domain will see the wrong offset and enumerate the domain incorrectly.
> 
> That's true also for new kernels on _current_ hardware, isn't it ?
> 
> What I am saying is that there must be a way to detect the right
> offset from HW probing or firmware otherwise things will break
> one way of another.
> 
I think this is basically that, but the spec changed which register
addresses contained the offset. The offset was still discoverable
either way, but is now within 0x2000-0x2010, with 0x2010-0x2090 as oob
interface.



> > > We must make sure that the address move is managed seamlessly by the
> > > kernel.
> > If we need to avoid changing addressing within stable, then that's
> > fine. But otherwise is there an issue merging with 5.4?
> 
> See above. Would 5.4 with this patch applied work on systems where
> the offset is the same as the _current_ one without this patch
> applied ?
I understand your concern, but these systems with wrong addressing
won't exist because the hardware isn't released yet.

In the future, the hardware will be released and users will inevitably
load some unfixed kernel, and we would like to point to stable for the
fix.



> 
> > > For the time being I have to drop this fix and it is extremely
> > > tight to get it in v5.4, I can't send stable changes that we may
> > > have to revert.
> > Aren't we in the beginning of the merge window?
> 
> Yes and that's the problem, patches for v5.4 should have already
> being queued a while ago, I do not know when Bjorn will send the
> PR for v5.4 but that's going to happen shortly, I am making an
> exception to squeeze these patches in since it is vmd only code
> but still it is very very tight.
> 
If you feel there's a risk, then I think it can be staged for v5.5.
Hardware will not be available for some time.



Best regards,
Jon


> Thanks,
> Lorenzo
> 
> > > Thanks,
> > > Lorenzo
> > > 
> > > > Cc: stable@...r.kernel.org # v5.2+
> > > > Fixes: 6788958e ("PCI: vmd: Assign membar addresses from shadow registers")
> > > > Signed-off-by: Jon Derrick <jonathan.derrick@...el.com>
> > > > ---
> > > >  drivers/pci/controller/vmd.c | 9 ++++++---
> > > >  1 file changed, 6 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> > > > index 2e4da3f51d6b..a35d3f3996d7 100644
> > > > --- a/drivers/pci/controller/vmd.c
> > > > +++ b/drivers/pci/controller/vmd.c
> > > > @@ -31,6 +31,9 @@
> > > >  #define PCI_REG_VMLOCK		0x70
> > > >  #define MB2_SHADOW_EN(vmlock)	(vmlock & 0x2)
> > > >  
> > > > +#define MB2_SHADOW_OFFSET	0x2000
> > > > +#define MB2_SHADOW_SIZE		16
> > > > +
> > > >  enum vmd_features {
> > > >  	/*
> > > >  	 * Device may contain registers which hint the physical location of the
> > > > @@ -578,7 +581,7 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
> > > >  		u32 vmlock;
> > > >  		int ret;
> > > >  
> > > > -		membar2_offset = 0x2018;
> > > > +		membar2_offset = MB2_SHADOW_OFFSET + MB2_SHADOW_SIZE;
> > > >  		ret = pci_read_config_dword(vmd->dev, PCI_REG_VMLOCK, &vmlock);
> > > >  		if (ret || vmlock == ~0)
> > > >  			return -ENODEV;
> > > > @@ -590,9 +593,9 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
> > > >  			if (!membar2)
> > > >  				return -ENOMEM;
> > > >  			offset[0] = vmd->dev->resource[VMD_MEMBAR1].start -
> > > > -						readq(membar2 + 0x2008);
> > > > +					readq(membar2 + MB2_SHADOW_OFFSET);
> > > >  			offset[1] = vmd->dev->resource[VMD_MEMBAR2].start -
> > > > -						readq(membar2 + 0x2010);
> > > > +					readq(membar2 + MB2_SHADOW_OFFSET + 8);
> > > >  			pci_iounmap(vmd->dev, membar2);
> > > >  		}
> > > >  	}
> > > > -- 
> > > > 2.20.1
> > > >