On Tue, Oct 03, 2017 at 07:50:25PM +0300, Leon Romanovsky wrote:
> On Tue, Oct 03, 2017 at 10:56:06AM -0500, Chien Tin Tung wrote:
> > On Tue, Oct 03, 2017 at 08:21:59AM +0300, Leon Romanovsky wrote:
> > > On Mon, Oct 02, 2017 at 09:20:33AM -0600, Jason Gunthorpe wrote:
> > > > On Mon, Oct 02, 2017 at 02:34:31PM +0300, Dan Carpenter wrote:
> > > >
> > > > > We deliberately allow invalid attr->port_nums if IB_QP_PORT is not set.
> > > > > Why must we do that? From a kernel hardening perspective it would be
> > > > > better to ban invalid values all together...
> > > >
> > > > It is part of the user ABI, so it has to stay that way...
> > >
> > > Can we pre-process all invalid parameters at the kernel entry points to
> > > ensure that drivers receive clean input?
> >
> > Which side? I hope you meant the kernel side. I certainly wouldn't want
> > kernel to trust user input...
>
> Yes, Chien, kernel side ("kernel entry points"), it goes without saying.
Sorry, I had to ask given your past history of confusing user and kernel.
So back to your suggestion, can you give an example of how you would
take care of the check for this particular API, qp_modify? And how would
you account for differences between protocols IB/iWARP at this level?
Chien
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
