Re: [PATCH 11/12] svcrdma: Add a message log string to indicate if FastReg is being used

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Oct 09, 2008 at 01:37:05AM -0500, Tom Tucker wrote:
> J. Bruce Fields wrote:
>> On Fri, Oct 03, 2008 at 04:33:48PM -0500, Tom Tucker wrote:
>>   
>>> Add a log message that allows the administrator to determine if server memory
>>> is exposed on a particular client connection. This message can be disabled
>>> by writing 0 to the /proc/sys/sunrpc/svc_rdma/show_conn_info file.
>>>     
>>
>> I could grudgingly live with the idea of a log message here as a
>> temporary fix while we figure out something better, but I'm not happy
>> about making it bigger and adding a sysctl.
>>
>>   
> I would happily remove all of this. I believed you thought it important  
> that we actively informed the administrator.
> Maybe I over-reacted.

Well, I was probably unclear and/or confused, apologies.  What I think
would make sense for now would be just be some easy way we an
administrator could answer the question "what kind of security model are
my rdma interfaces using"?

A cautious administrator will want to answer these questions before
turning on nfs over rdma, so a log message on client connect isn't as
useful.  Also, messages to the log are fine for debugging, for notices
about exceptional events, etc., but they aren't reliable for this kind
of use (they get stored in distro-specific locations for varying amounts
of time; wording may change across kernel versions, making them harder
to grep for; etc).

So these log messages might serve as a stopgap, but I'd prefer something
that could be queried reliably at any time.

If in addition we wanted to warn about the riskier case, maybe we could
print a message *just* in that case (and print it only once), but I
don't feel strongly about that.

>> If we just want a hack for now, I'd be inclined to leave this printk a
>> dprintk, add the extra information to the dprintk, and tell people to
>> turn on transport debugging and watch a client connect.  Ugly, but at
>> least it'll be obvious it's not an api that's going to stick around.
>>
>>   
> Id' love to get rid of it...
>> Beyond the short-term: is there some other way of getting this
>> information from userspace?  Since this is a property of the interface
>> device, it'd seem natural to communicate the information in something
>> like a sysfs file for the device, or whatever's used to query properties
>> of network interfaces.
>>
>>   I'm a bit surprised the information isn't already there.  Aren't
>> userspace applications eventually also supposed to be able to use rdma?
>> Don't they need to query network interfaces for their capabilities?
>>
>>   
> All of this information is available from  a full-function user-mode API.

Oh, cool.  So would it be difficult to write a C program that just
printed out some basic information about the rdma-capable interfaces on
the system?  If it didn't have a lot of dependencies, we could even
consider adding it to nfs-utils.

The one drawback is that it wouldn't be able to tell whether the
currently running kernel actually supported fast registration.  Do you
think a guess based on kernel version would be good enough for that?

> This code makes devices more secure than they used to be. So there is no  
> negative security regression here. This patchset simply improves the 
> security for newer devices that support the new features.

Yes, agreed.  Just to be clear, I *have* queued up all but these last
two patches (the printk and documentation patches) for 2.6.28.  

--b.