On Tue, May 20, 2008 at 09:27:13AM -0400, Talpey, Thomas wrote:
> At 09:07 PM 5/19/2008, Tom Tucker wrote:
> >No we don't and a Byzantine client could crash us.
>
> That can be arranged... :-)
>
> >This kind of check along with a bunch of others should go in
> >svc_rdma_xdr_decode_req. I have these things planned for the 2.6.27
> >time-frame (along with Fast NSMR support).
> >
> >Do you think it's more urgent?
>
> MHO is that it's important but not urgent, and it should be part of a later
> change. At Connectathon, no clients were sending any problematic requests,
> so I think it's unlikely this will affect us in the wild, for now.
Somewhere in the documentation, a really clear warning about the
security assumptions would be useful. It could also help if the howto
(on the web and in Documentation/filesystems/nfs-rdma.txt) included any
instructions on necessary firewalling, etc.
By the way, the Kconfig help text for SUNRPC_XPRT_RDMA looks like it
needs an update to mention the server?
--b.
At 09:56 AM 5/20/2008, J. Bruce Fields wrote:
>> MHO is that it's important but not urgent, and it should be part of a later
>> change. At Connectathon, no clients were sending any problematic requests,
>> so I think it's unlikely this will affect us in the wild, for now.
>
>Somewhere in the documentation, a really clear warning about the
>security assumptions would be useful. It could also help if the howto
>(on the web and in Documentation/filesystems/nfs-rdma.txt) included any
>instructions on necessary firewalling, etc.
Agreed. The kernel (/proc) parameters are part of this, and it's time to
spell them all out as well.
The protocol hardening we're talking about above isn't a security issue,
of course. It's just basic and part of the implementation. The client, btw,
has some fairly strict checking.
>By the way, the Kconfig help text for SUNRPC_XPRT_RDMA looks like it
>needs an update to mention the server?
You're right - it only mentions the client. I thought we added that text when
we simplified/collapsed the config.
Tom.