From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH] net: don't unnecessarily load kernel modules in dev_ioctl() Date: Wed, 07 Mar 2018 15:13:32 -0500 (EST) Message-ID: <20180307.151332.565301474495395127.davem@davemloft.net> References: <152037526427.18953.14013300464173153064.stgit@chester> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org, selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org To: paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org Return-path: In-Reply-To: List-Post: List-Help: Errors-To: selinux-bounces-+05T5uksL2qpZYMLLGbcSA@public.gmane.org Sender: "Selinux" List-Id: netdev.vger.kernel.org From: Paul Moore Date: Tue, 6 Mar 2018 17:32:47 -0500 > On Tue, Mar 6, 2018 at 5:27 PM, Paul Moore wrote: >> From: Paul Moore >> >> Starting with v4.16-rc1 we've been seeing a higher than usual number >> of requests for the kernel to load networking modules, even on events >> which shouldn't trigger a module load (e.g. ioctl(TCGETS)). Stephen >> Smalley suggested the problem may lie in commit 44c02a2c3dc5 >> ("dev_ioctl(): move copyin/copyout to callers") which moves changes >> the network dev_ioctl() function to always call dev_load(), >> regardless of the requested ioctl. >> >> This patch moves the dev_load() calls back into the individual ioctls >> while preserving the rest of the original patch. >> >> Reported-by: Dominick Grift >> Suggested-by: Stephen Smalley >> Signed-off-by: Paul Moore >> --- >> net/core/dev_ioctl.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) > > In the interest of full disclosure, I've compiled this code but I > haven't booted it yet (test kernel building now). I just wanted to > post this sooner rather than later in case the networking folks, or > Al, had a different solution they would prefer. This is definitely the right fix, so patch applied. Taking the dev_load() out of that switch statement definitely has side effects. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id w27KE8gB020618 for ; Wed, 7 Mar 2018 15:14:08 -0500 Date: Wed, 07 Mar 2018 15:13:32 -0500 (EST) Message-Id: <20180307.151332.565301474495395127.davem@davemloft.net> To: paul@paul-moore.com Cc: pmoore@redhat.com, netdev@vger.kernel.org, viro@zeniv.linux.org.uk, dac.override@gmail.com, selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org From: David Miller In-Reply-To: References: <152037526427.18953.14013300464173153064.stgit@chester> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Subject: Re: [PATCH] net: don't unnecessarily load kernel modules in dev_ioctl() List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: From: Paul Moore Date: Tue, 6 Mar 2018 17:32:47 -0500 > On Tue, Mar 6, 2018 at 5:27 PM, Paul Moore wrote: >> From: Paul Moore >> >> Starting with v4.16-rc1 we've been seeing a higher than usual number >> of requests for the kernel to load networking modules, even on events >> which shouldn't trigger a module load (e.g. ioctl(TCGETS)). Stephen >> Smalley suggested the problem may lie in commit 44c02a2c3dc5 >> ("dev_ioctl(): move copyin/copyout to callers") which moves changes >> the network dev_ioctl() function to always call dev_load(), >> regardless of the requested ioctl. >> >> This patch moves the dev_load() calls back into the individual ioctls >> while preserving the rest of the original patch. >> >> Reported-by: Dominick Grift >> Suggested-by: Stephen Smalley >> Signed-off-by: Paul Moore >> --- >> net/core/dev_ioctl.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) > > In the interest of full disclosure, I've compiled this code but I > haven't booted it yet (test kernel building now). I just wanted to > post this sooner rather than later in case the networking folks, or > Al, had a different solution they would prefer. This is definitely the right fix, so patch applied. Taking the dev_load() out of that switch statement definitely has side effects. From mboxrd@z Thu Jan 1 00:00:00 1970 From: davem@davemloft.net (David Miller) Date: Wed, 07 Mar 2018 15:13:32 -0500 (EST) Subject: [PATCH] net: don't unnecessarily load kernel modules in dev_ioctl() In-Reply-To: References: <152037526427.18953.14013300464173153064.stgit@chester> Message-ID: <20180307.151332.565301474495395127.davem@davemloft.net> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org From: Paul Moore Date: Tue, 6 Mar 2018 17:32:47 -0500 > On Tue, Mar 6, 2018 at 5:27 PM, Paul Moore wrote: >> From: Paul Moore >> >> Starting with v4.16-rc1 we've been seeing a higher than usual number >> of requests for the kernel to load networking modules, even on events >> which shouldn't trigger a module load (e.g. ioctl(TCGETS)). Stephen >> Smalley suggested the problem may lie in commit 44c02a2c3dc5 >> ("dev_ioctl(): move copyin/copyout to callers") which moves changes >> the network dev_ioctl() function to always call dev_load(), >> regardless of the requested ioctl. >> >> This patch moves the dev_load() calls back into the individual ioctls >> while preserving the rest of the original patch. >> >> Reported-by: Dominick Grift >> Suggested-by: Stephen Smalley >> Signed-off-by: Paul Moore >> --- >> net/core/dev_ioctl.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) > > In the interest of full disclosure, I've compiled this code but I > haven't booted it yet (test kernel building now). I just wanted to > post this sooner rather than later in case the networking folks, or > Al, had a different solution they would prefer. This is definitely the right fix, so patch applied. Taking the dev_load() out of that switch statement definitely has side effects. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html