On Tue, Oct 03, 2017 at 07:52:27PM +0000, Hefty, Sean 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? > > > > For example, overwrite attr->port_nums to be zero if IB_QP_PORT is not > > set. attr->port_nums is not allowed to be set to zero so that will trigger another warning. > > I'm not sure this helps much. The value must still be ignored by the driver, whether it's in range or not. It would help me a lot to know that the value is always within range when we call the function. Smatch is tracking things at the function call level so it says "when we call this we know that the value comes from the user and is not trusted". Which is correct, but not precise. In an ideal world it would say, "This comes from the user and is not trusted unless a flag is set on param 3", but Smatch doesn't break it down that way... This might be solveable in Smatch... But generally the problem is that there is too much data to track the relationships between every variable in the kernel. I just break it down at the function call boundaries. So like, for returns I split them out into success/failure returns and I say "this is true if the function returns zero", and "these things are true if the function returns failure". But for calls I just say "These things are true when the function is called from this call site". regards, dan carpenter -- 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
