RE: Re: [PATCH] RDMA/siw: fix pointer cast warning

[David Laight <David.Laight@ACULAB.COM>]

From: Bernard Metzler
> Sent: 16 December 2022 10:01
> 
> > -----Original Message-----
> > From: Linus Walleij <linus.walleij@linaro.org>
> > Sent: Friday, 16 December 2022 08:47
> > To: David Laight <David.Laight@aculab.com>
> > Cc: Arnd Bergmann <arnd@kernel.org>; Bernard Metzler <BMT@zurich.ibm.com>;
> > Jason Gunthorpe <jgg@ziepe.ca>; Leon Romanovsky <leon@kernel.org>; Arnd
> > Bergmann <arnd@arndb.de>; linux-rdma@vger.kernel.org; linux-
> > kernel@vger.kernel.org
> > Subject: [EXTERNAL] Re: [PATCH] RDMA/siw: fix pointer cast warning
> >
> > On Thu, Dec 15, 2022 at 11:20 PM David Laight <David.Laight@aculab.com>
> > wrote:
> >
> > > From: Arnd Bergmann
> > > > Sent: 15 December 2022 17:04
> > > >
> > > > From: Arnd Bergmann <arnd@arndb.de>
> > > >
> > > > The previous build fix left a remaining issue in configurations
> > > > with 64-bit dma_addr_t on 32-bit architectures:
> > > >
> > > > drivers/infiniband/sw/siw/siw_qp_tx.c: In function 'siw_get_pblpage':
> > > > drivers/infiniband/sw/siw/siw_qp_tx.c:32:37: error: cast to pointer
> > from integer of different size [-
> > > > Werror=int-to-pointer-cast]
> > > >    32 |                 return virt_to_page((void *)paddr);
> > > >       |                                     ^
> > > >
> > > > Use the same double cast here that the driver uses elsewhere
> > > > to convert between dma_addr_t and void*.
> > > >
> > > > It took me a while to figure out why this driver does it
> > > > like this, as there is no hardware access and it just stores
> > > > kernel pointers in place of device addresses when communicating
> > > > with the rdma core and with user space.
> > >
> > > I hope that doesn't mean it is relying on user space only
> > > giving it back valid values?
> >
> > It looks to me like this driver totally trusts userspace.
> >
> 
> Shame on me. Yes, somehow, an access_ok((void __user *)start, len)
> is missing! Let me fix that when I am back at my desk. Seems it needs
> immediate action.

That wasn't the sort of issue I was thinking about.
I was worried that it was putting the addresses of kernel memory
into buffers written to userspace and then later reading the
addresses back from userspace and accessing them.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)