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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
