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: <20161009164905.GA12551@obsidianresearch.com>
Date:   Sun, 9 Oct 2016 10:49:05 -0600
From:   Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     Peter Huewe <peterhuewe@....de>,
        Marcel Selhorst <tpmdd@...horst.net>,
        "moderated list:TPM DEVICE DRIVER" 
        <tpmdd-devel@...ts.sourceforge.net>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC 1/3] tpm_crb: expand struct crb_control_area to
 struct crb_regs

On Sun, Oct 09, 2016 at 12:38:18PM +0300, Jarkko Sakkinen wrote:
> On Sat, Oct 08, 2016 at 07:42:56PM -0600, Jason Gunthorpe wrote:
> > On Sun, Oct 09, 2016 at 03:15:09AM +0300, Jarkko Sakkinen wrote:
> > > +	ctrl = crb_map_res(dev, priv, &io_res, buf->control_address,
> > > +			   sizeof(struct crb_regs) -
> > > +			   offsetof(struct crb_regs, ctrl_req));
> > > +	if (IS_ERR(ctrl))
> > > +		return PTR_ERR(ctrl);
> > > +
> > > +	/* The control area always overrlaps IO memory mapped from the ACPI
> > > +	 * object with CRB start only devices. Thus, this is perfectly safe.
> > > +	 */
> > > +	priv->regs = (void *)((unsigned long)ctrl -
> > > +		offsetof(struct crb_regs, ctrl_req));
> > 
> > Hum. No, this makes bad assumptions about the structure of iomapping.
> > 
> > The map itself needs to be done with the adjustment:
> > 
> > 	ctrl = crb_map_res(dev, priv, &io_res, buf->control_address -
> > 		offsetof(struct crb_regs, ctrl_req),
> > 	   	sizeof(struct crb_regs));
> 
> That would be wrong address for the control area as it does not start
> from the beginning of CRB registers.

Of course, I just pointed out what the map call should look like

Something like this

 	priv->regs = crb_map_res(dev, priv, &io_res, buf->control_address -
 		offsetof(struct crb_regs, ctrl_req),
 	   	sizeof(struct crb_regs));
        ctrl = &priv->regs.ctrl_req;

> I think the crb_map_io and crb_map_res are too generic. Better way to do
> things would be to validate that assumptions for these two cases hold.

If the driver is going to be using a negative offset like this, then
it very much should validate the assumptions before doing it.

and not even map these regsiters if they are not supported by
hardware.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ