All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Djalal Harouni <tixxdz@gmail.com>
Cc: Kees Cook <keescook@chromium.org>,
	Andy Lutomirski <luto@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	James Morris <james.l.morris@oracle.com>,
	Ben Hutchings <ben.hutchings@codethink.co.uk>,
	Solar Designer <solar@openwall.com>,
	Serge Hallyn <serge@hallyn.com>, Jessica Yu <jeyu@kernel.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	kernel-hardening@lists.openwall.com,
	Jonathan Corbet <corbet@lwn.net>, Ingo Molnar <mingo@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()
Date: Tue, 28 Nov 2017 20:14:05 +0100	[thread overview]
Message-ID: <20171128191405.GO729@wotan.suse.de> (raw)
In-Reply-To: <1511803118-2552-2-git-send-email-tixxdz@gmail.com>

On Mon, Nov 27, 2017 at 06:18:34PM +0100, Djalal Harouni wrote:
...

> After a discussion with Rusty Russell [1], the suggestion was to pass
> the capability from request_module() to security_kernel_module_request()
> for 'netdev-%s' modules that need CAP_NET_ADMIN, and after review from
> Kees Cook [2] and experimenting with the code, the patch now does the
> following:
> 
> * Adds the request_module_cap() function.
> * Updates the __request_module() to take the "required_cap" argument
>         with the "prefix".

...

> Signed-off-by: Djalal Harouni <tixxdz@gmail.com>
> ---
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index bc6addd..679d401 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -139,13 +147,22 @@ int __request_module(bool wait, const char *fmt, ...)
>  	if (!modprobe_path[0])
>  		return 0;
>  
> +	/*
> +	 * Lets attach the prefix to the module name
> +	 */
> +	if (prefix != NULL && *prefix != '\0') {
> +		len += snprintf(module_name, MODULE_NAME_LEN, "%s-", prefix);
> +		if (len >= MODULE_NAME_LEN)
> +			return -ENAMETOOLONG;
> +	}
> +
>  	va_start(args, fmt);
> -	ret = vsnprintf(module_name, MODULE_NAME_LEN, fmt, args);
> +	ret = vsnprintf(module_name + len, MODULE_NAME_LEN - len, fmt, args);
>  	va_end(args);
> -	if (ret >= MODULE_NAME_LEN)
> +	if (ret >= MODULE_NAME_LEN - len)
>  		return -ENAMETOOLONG;
>  
> -	ret = security_kernel_module_request(module_name);
> +	ret = security_kernel_module_request(module_name, required_cap, prefix);
>  	if (ret)
>  		return ret;
>  

kmod is just a helper to poke userpsace to load a module, that's it.

The old init_module() and newer finit_module() do the real handy work or
module loading, and both currently only use may_init_module():

static int may_init_module(void)
{
	if (!capable(CAP_SYS_MODULE) || modules_disabled)
		return -EPERM;                                                  

	return 0;
}

This begs the question:

  o If userspace just tries to just use raw finit_module() do we want similar
    checks?

Otherwise, correct me if I'm wrong this all seems pointless.

If we want something similar I think we might need to be processing aliases and
check for the aliases for their desired restrictions on finit_module(),
otherwise userspace can skip through the checks if the module name does not
match the alias prefix.

To be clear, aliases are completely ignored today on load_module(), so loading
'xfs' with finit_module() will just have the kernel know about 'xfs' not
'fs-xfs'.

So we currently do not process aliases in kernel.

I have debugging patches to enable us to process them, but they are just for
debugging and I've been meaning to send them in for review. I designed them
only for debugging given last time someone suggested for aliases processing to
be added, the only use case we found was a pre-optimizations we decided to avoid
pursuing. Debugging is a good reason to have alias processing in-kernel though.

The pre-optimization we decided to stay away from was to check if the requested
module via request_module() was already loaded *and* also check if the name passed
matches any of the existing module aliases for currently loaded modules. Today
request_module() does not even check if a requested module is already loaded,
its a stupid loader, it just goes to userspace, and lets userspace figure it
out. Userspace in turn could check for aliases, but it could lie, or not be up
to date to do that.

The pre-optmization is a theoretical gain only then, and if userspace had
proper alias checking it is arguable that it may perform just as equal.
To help valuate these sorts of things we now have:

tools/testing/selftests/kmod/kmod.sh

So further patches can use and test impact with it.

Anyway -- so aliasing is currently only a debugging consideration, but without
processing aliases, all this work seems pointless to me as the real loader is
in finit_module().
 
kmod is just a stupid loader and uses the kernel usermode helper to do work.

  Luis

WARNING: multiple messages have this Message-ID (diff)
From: mcgrof@kernel.org (Luis R. Rodriguez)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()
Date: Tue, 28 Nov 2017 20:14:05 +0100	[thread overview]
Message-ID: <20171128191405.GO729@wotan.suse.de> (raw)
In-Reply-To: <1511803118-2552-2-git-send-email-tixxdz@gmail.com>

On Mon, Nov 27, 2017 at 06:18:34PM +0100, Djalal Harouni wrote:
...

> After a discussion with Rusty Russell [1], the suggestion was to pass
> the capability from request_module() to security_kernel_module_request()
> for 'netdev-%s' modules that need CAP_NET_ADMIN, and after review from
> Kees Cook [2] and experimenting with the code, the patch now does the
> following:
> 
> * Adds the request_module_cap() function.
> * Updates the __request_module() to take the "required_cap" argument
>         with the "prefix".

...

> Signed-off-by: Djalal Harouni <tixxdz@gmail.com>
> ---
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index bc6addd..679d401 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -139,13 +147,22 @@ int __request_module(bool wait, const char *fmt, ...)
>  	if (!modprobe_path[0])
>  		return 0;
>  
> +	/*
> +	 * Lets attach the prefix to the module name
> +	 */
> +	if (prefix != NULL && *prefix != '\0') {
> +		len += snprintf(module_name, MODULE_NAME_LEN, "%s-", prefix);
> +		if (len >= MODULE_NAME_LEN)
> +			return -ENAMETOOLONG;
> +	}
> +
>  	va_start(args, fmt);
> -	ret = vsnprintf(module_name, MODULE_NAME_LEN, fmt, args);
> +	ret = vsnprintf(module_name + len, MODULE_NAME_LEN - len, fmt, args);
>  	va_end(args);
> -	if (ret >= MODULE_NAME_LEN)
> +	if (ret >= MODULE_NAME_LEN - len)
>  		return -ENAMETOOLONG;
>  
> -	ret = security_kernel_module_request(module_name);
> +	ret = security_kernel_module_request(module_name, required_cap, prefix);
>  	if (ret)
>  		return ret;
>  

kmod is just a helper to poke userpsace to load a module, that's it.

The old init_module() and newer finit_module() do the real handy work or
module loading, and both currently only use may_init_module():

static int may_init_module(void)
{
	if (!capable(CAP_SYS_MODULE) || modules_disabled)
		return -EPERM;                                                  

	return 0;
}

This begs the question:

  o If userspace just tries to just use raw finit_module() do we want similar
    checks?

Otherwise, correct me if I'm wrong this all seems pointless.

If we want something similar I think we might need to be processing aliases and
check for the aliases for their desired restrictions on finit_module(),
otherwise userspace can skip through the checks if the module name does not
match the alias prefix.

To be clear, aliases are completely ignored today on load_module(), so loading
'xfs' with finit_module() will just have the kernel know about 'xfs' not
'fs-xfs'.

So we currently do not process aliases in kernel.

I have debugging patches to enable us to process them, but they are just for
debugging and I've been meaning to send them in for review. I designed them
only for debugging given last time someone suggested for aliases processing to
be added, the only use case we found was a pre-optimizations we decided to avoid
pursuing. Debugging is a good reason to have alias processing in-kernel though.

The pre-optimization we decided to stay away from was to check if the requested
module via request_module() was already loaded *and* also check if the name passed
matches any of the existing module aliases for currently loaded modules. Today
request_module() does not even check if a requested module is already loaded,
its a stupid loader, it just goes to userspace, and lets userspace figure it
out. Userspace in turn could check for aliases, but it could lie, or not be up
to date to do that.

The pre-optmization is a theoretical gain only then, and if userspace had
proper alias checking it is arguable that it may perform just as equal.
To help valuate these sorts of things we now have:

tools/testing/selftests/kmod/kmod.sh

So further patches can use and test impact with it.

Anyway -- so aliasing is currently only a debugging consideration, but without
processing aliases, all this work seems pointless to me as the real loader is
in finit_module().
 
kmod is just a stupid loader and uses the kernel usermode helper to do work.

  Luis
--
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

WARNING: multiple messages have this Message-ID (diff)
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Djalal Harouni <tixxdz@gmail.com>
Cc: Kees Cook <keescook@chromium.org>,
	Andy Lutomirski <luto@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	James Morris <james.l.morris@oracle.com>,
	Ben Hutchings <ben.hutchings@codethink.co.uk>,
	Solar Designer <solar@openwall.com>,
	Serge Hallyn <serge@hallyn.com>, Jessica Yu <jeyu@kernel.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	kernel-hardening@lists.openwall.com,
	Jonathan Corbet <corbet@lwn.net>, Ingo Molnar <mingo@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: [kernel-hardening] Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()
Date: Tue, 28 Nov 2017 20:14:05 +0100	[thread overview]
Message-ID: <20171128191405.GO729@wotan.suse.de> (raw)
In-Reply-To: <1511803118-2552-2-git-send-email-tixxdz@gmail.com>

On Mon, Nov 27, 2017 at 06:18:34PM +0100, Djalal Harouni wrote:
...

> After a discussion with Rusty Russell [1], the suggestion was to pass
> the capability from request_module() to security_kernel_module_request()
> for 'netdev-%s' modules that need CAP_NET_ADMIN, and after review from
> Kees Cook [2] and experimenting with the code, the patch now does the
> following:
> 
> * Adds the request_module_cap() function.
> * Updates the __request_module() to take the "required_cap" argument
>         with the "prefix".

...

> Signed-off-by: Djalal Harouni <tixxdz@gmail.com>
> ---
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index bc6addd..679d401 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -139,13 +147,22 @@ int __request_module(bool wait, const char *fmt, ...)
>  	if (!modprobe_path[0])
>  		return 0;
>  
> +	/*
> +	 * Lets attach the prefix to the module name
> +	 */
> +	if (prefix != NULL && *prefix != '\0') {
> +		len += snprintf(module_name, MODULE_NAME_LEN, "%s-", prefix);
> +		if (len >= MODULE_NAME_LEN)
> +			return -ENAMETOOLONG;
> +	}
> +
>  	va_start(args, fmt);
> -	ret = vsnprintf(module_name, MODULE_NAME_LEN, fmt, args);
> +	ret = vsnprintf(module_name + len, MODULE_NAME_LEN - len, fmt, args);
>  	va_end(args);
> -	if (ret >= MODULE_NAME_LEN)
> +	if (ret >= MODULE_NAME_LEN - len)
>  		return -ENAMETOOLONG;
>  
> -	ret = security_kernel_module_request(module_name);
> +	ret = security_kernel_module_request(module_name, required_cap, prefix);
>  	if (ret)
>  		return ret;
>  

kmod is just a helper to poke userpsace to load a module, that's it.

The old init_module() and newer finit_module() do the real handy work or
module loading, and both currently only use may_init_module():

static int may_init_module(void)
{
	if (!capable(CAP_SYS_MODULE) || modules_disabled)
		return -EPERM;                                                  

	return 0;
}

This begs the question:

  o If userspace just tries to just use raw finit_module() do we want similar
    checks?

Otherwise, correct me if I'm wrong this all seems pointless.

If we want something similar I think we might need to be processing aliases and
check for the aliases for their desired restrictions on finit_module(),
otherwise userspace can skip through the checks if the module name does not
match the alias prefix.

To be clear, aliases are completely ignored today on load_module(), so loading
'xfs' with finit_module() will just have the kernel know about 'xfs' not
'fs-xfs'.

So we currently do not process aliases in kernel.

I have debugging patches to enable us to process them, but they are just for
debugging and I've been meaning to send them in for review. I designed them
only for debugging given last time someone suggested for aliases processing to
be added, the only use case we found was a pre-optimizations we decided to avoid
pursuing. Debugging is a good reason to have alias processing in-kernel though.

The pre-optimization we decided to stay away from was to check if the requested
module via request_module() was already loaded *and* also check if the name passed
matches any of the existing module aliases for currently loaded modules. Today
request_module() does not even check if a requested module is already loaded,
its a stupid loader, it just goes to userspace, and lets userspace figure it
out. Userspace in turn could check for aliases, but it could lie, or not be up
to date to do that.

The pre-optmization is a theoretical gain only then, and if userspace had
proper alias checking it is arguable that it may perform just as equal.
To help valuate these sorts of things we now have:

tools/testing/selftests/kmod/kmod.sh

So further patches can use and test impact with it.

Anyway -- so aliasing is currently only a debugging consideration, but without
processing aliases, all this work seems pointless to me as the real loader is
in finit_module().
 
kmod is just a stupid loader and uses the kernel usermode helper to do work.

  Luis

  parent reply	other threads:[~2017-11-28 19:14 UTC|newest]

Thread overview: 266+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27 17:18 [PATCH v5 next 0/5] Improve Module autoloading infrastructure Djalal Harouni
2017-11-27 17:18 ` [kernel-hardening] " Djalal Harouni
2017-11-27 17:18 ` Djalal Harouni
2017-11-27 17:18 ` [PATCH v5 next 1/5] modules:capabilities: add request_module_cap() Djalal Harouni
2017-11-27 17:18   ` [kernel-hardening] " Djalal Harouni
2017-11-27 17:18   ` Djalal Harouni
2017-11-27 18:48   ` Randy Dunlap
2017-11-27 18:48     ` [kernel-hardening] " Randy Dunlap
2017-11-27 18:48     ` Randy Dunlap
2017-11-27 21:35     ` Djalal Harouni
2017-11-27 21:35       ` [kernel-hardening] " Djalal Harouni
2017-11-27 21:35       ` Djalal Harouni
2017-11-28 19:14   ` Luis R. Rodriguez [this message]
2017-11-28 19:14     ` [kernel-hardening] " Luis R. Rodriguez
2017-11-28 19:14     ` Luis R. Rodriguez
2017-11-28 20:11     ` Kees Cook
2017-11-28 20:11       ` [kernel-hardening] " Kees Cook
2017-11-28 20:11       ` Kees Cook
2017-11-28 21:16       ` Luis R. Rodriguez
2017-11-28 21:16         ` [kernel-hardening] " Luis R. Rodriguez
2017-11-28 21:16         ` Luis R. Rodriguez
2017-11-28 21:33         ` Djalal Harouni
2017-11-28 21:33           ` [kernel-hardening] " Djalal Harouni
2017-11-28 21:33           ` Djalal Harouni
2017-11-28 22:18           ` Luis R. Rodriguez
2017-11-28 22:18             ` [kernel-hardening] " Luis R. Rodriguez
2017-11-28 22:18             ` Luis R. Rodriguez
2017-11-28 22:52             ` Djalal Harouni
2017-11-28 22:52               ` [kernel-hardening] " Djalal Harouni
2017-11-28 22:52               ` Djalal Harouni
2017-11-28 21:39         ` Kees Cook
2017-11-28 21:39           ` [kernel-hardening] " Kees Cook
2017-11-28 21:39           ` Kees Cook
2017-11-28 22:12           ` Luis R. Rodriguez
2017-11-28 22:12             ` [kernel-hardening] " Luis R. Rodriguez
2017-11-28 22:12             ` Luis R. Rodriguez
2017-11-28 22:18             ` Kees Cook
2017-11-28 22:18               ` [kernel-hardening] " Kees Cook
2017-11-28 22:18               ` Kees Cook
2017-11-28 22:48               ` Luis R. Rodriguez
2017-11-28 22:48                 ` [kernel-hardening] " Luis R. Rodriguez
2017-11-28 22:48                 ` Luis R. Rodriguez
2017-11-29  7:49                 ` Michal Kubecek
2017-11-29  7:49                   ` [kernel-hardening] " Michal Kubecek
2017-11-29  7:49                   ` Michal Kubecek
2017-11-29 13:46           ` Alan Cox
2017-11-29 13:46             ` [kernel-hardening] " Alan Cox
2017-11-29 13:46             ` Alan Cox
2017-11-29 14:50             ` David Miller
2017-11-29 14:50               ` [kernel-hardening] " David Miller
2017-11-29 14:50               ` David Miller
2017-11-29 15:54               ` Theodore Ts'o
2017-11-29 15:54                 ` [kernel-hardening] " Theodore Ts'o
2017-11-29 15:54                 ` Theodore Ts'o
2017-11-29 15:58                 ` David Miller
2017-11-29 15:58                   ` [kernel-hardening] " David Miller
2017-11-29 15:58                   ` David Miller
2017-11-29 16:29                   ` Theodore Ts'o
2017-11-29 16:29                     ` [kernel-hardening] " Theodore Ts'o
2017-11-29 16:29                     ` Theodore Ts'o
2017-11-29 22:45                   ` Linus Torvalds
2017-11-29 22:45                     ` [kernel-hardening] " Linus Torvalds
2017-11-29 22:45                     ` Linus Torvalds
2017-11-29 22:45                     ` Linus Torvalds
2017-11-30  0:06                     ` Kees Cook
2017-11-30  0:06                       ` [kernel-hardening] " Kees Cook
2017-11-30  0:06                       ` Kees Cook
2017-11-30  0:06                       ` Kees Cook
2017-11-29 17:28                 ` Serge E. Hallyn
2017-11-29 17:28                   ` [kernel-hardening] " Serge E. Hallyn
2017-11-29 17:28                   ` Serge E. Hallyn
2017-11-30  0:35                   ` Theodore Ts'o
2017-11-30  0:35                     ` [kernel-hardening] " Theodore Ts'o
2017-11-30  0:35                     ` Theodore Ts'o
2017-11-30 17:17                     ` Serge E. Hallyn
2017-11-30 17:17                       ` [kernel-hardening] " Serge E. Hallyn
2017-11-30 17:17                       ` Serge E. Hallyn
2017-11-28 20:18     ` Djalal Harouni
2017-11-28 20:18       ` [kernel-hardening] " Djalal Harouni
2017-11-28 20:18       ` Djalal Harouni
2017-11-27 17:18 ` [PATCH v5 next 2/5] modules:capabilities: add cap_kernel_module_request() permission check Djalal Harouni
2017-11-27 17:18   ` [kernel-hardening] " Djalal Harouni
2017-11-27 17:18   ` Djalal Harouni
2017-11-30  2:05   ` Luis R. Rodriguez
2017-11-30  2:05     ` [kernel-hardening] " Luis R. Rodriguez
2017-11-30  2:05     ` Luis R. Rodriguez
2017-11-27 17:18 ` [PATCH v5 next 3/5] modules:capabilities: automatic module loading restriction Djalal Harouni
2017-11-27 17:18   ` [kernel-hardening] " Djalal Harouni
2017-11-27 17:18   ` Djalal Harouni
2017-11-30  1:23   ` Luis R. Rodriguez
2017-11-30  1:23     ` [kernel-hardening] " Luis R. Rodriguez
2017-11-30  1:23     ` Luis R. Rodriguez
2017-11-30 12:22     ` Djalal Harouni
2017-11-30 12:22       ` [kernel-hardening] " Djalal Harouni
2017-11-30 12:22       ` Djalal Harouni
2017-11-27 17:18 ` [PATCH v5 next 4/5] modules:capabilities: add a per-task modules auto-load mode Djalal Harouni
2017-11-27 17:18   ` [kernel-hardening] " Djalal Harouni
2017-11-27 17:18   ` Djalal Harouni
2017-11-27 17:18 ` [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules Djalal Harouni
2017-11-27 17:18   ` [kernel-hardening] " Djalal Harouni
2017-11-27 17:18   ` Djalal Harouni
2017-11-27 18:44   ` Linus Torvalds
2017-11-27 18:44     ` [kernel-hardening] " Linus Torvalds
2017-11-27 18:44     ` Linus Torvalds
2017-11-27 18:44     ` Linus Torvalds
2017-11-27 21:41     ` Djalal Harouni
2017-11-27 21:41       ` [kernel-hardening] " Djalal Harouni
2017-11-27 21:41       ` Djalal Harouni
2017-11-27 21:41       ` Djalal Harouni
2017-11-27 22:04       ` Linus Torvalds
2017-11-27 22:04         ` [kernel-hardening] " Linus Torvalds
2017-11-27 22:04         ` Linus Torvalds
2017-11-27 22:04         ` Linus Torvalds
2017-11-27 22:59         ` Kees Cook
2017-11-27 22:59           ` [kernel-hardening] " Kees Cook
2017-11-27 22:59           ` Kees Cook
2017-11-27 22:59           ` Kees Cook
2017-11-27 23:14           ` Linus Torvalds
2017-11-27 23:14             ` [kernel-hardening] " Linus Torvalds
2017-11-27 23:14             ` Linus Torvalds
2017-11-27 23:14             ` Linus Torvalds
2017-11-27 23:19             ` Kees Cook
2017-11-27 23:19               ` [kernel-hardening] " Kees Cook
2017-11-27 23:19               ` Kees Cook
2017-11-27 23:19               ` Kees Cook
2017-11-27 23:35               ` Linus Torvalds
2017-11-27 23:35                 ` [kernel-hardening] " Linus Torvalds
2017-11-27 23:35                 ` Linus Torvalds
2017-11-27 23:35                 ` Linus Torvalds
2017-11-28  1:23             ` Kees Cook
2017-11-28  1:23               ` [kernel-hardening] " Kees Cook
2017-11-28  1:23               ` Kees Cook
2017-11-28  1:23               ` Kees Cook
2017-11-28 12:16         ` [kernel-hardening] " Geo Kozey
2017-11-28 12:16           ` Geo Kozey
2017-11-28 12:16           ` Geo Kozey
2017-11-28 19:32           ` Theodore Ts'o
2017-11-28 19:32             ` Theodore Ts'o
2017-11-28 19:32             ` Theodore Ts'o
2017-11-28 20:08             ` Kees Cook
2017-11-28 20:08               ` Kees Cook
2017-11-28 20:08               ` Kees Cook
2017-11-28 20:12               ` Linus Torvalds
2017-11-28 20:12                 ` Linus Torvalds
2017-11-28 20:12                 ` Linus Torvalds
2017-11-28 20:20                 ` Kees Cook
2017-11-28 20:20                   ` Kees Cook
2017-11-28 20:20                   ` Kees Cook
2017-11-28 20:33                   ` Linus Torvalds
2017-11-28 20:33                     ` Linus Torvalds
2017-11-28 20:33                     ` Linus Torvalds
2017-11-28 21:10                     ` Djalal Harouni
2017-11-28 21:10                       ` Djalal Harouni
2017-11-28 21:10                       ` Djalal Harouni
2017-11-28 21:33                     ` Kees Cook
2017-11-28 21:33                       ` Kees Cook
2017-11-28 21:33                       ` Kees Cook
2017-11-28 23:23                       ` Theodore Ts'o
2017-11-28 23:23                         ` Theodore Ts'o
2017-11-28 23:23                         ` Theodore Ts'o
2017-11-28 23:29                         ` Kees Cook
2017-11-28 23:29                           ` Kees Cook
2017-11-28 23:29                           ` Kees Cook
2017-11-28 23:49                           ` Theodore Ts'o
2017-11-28 23:49                             ` Theodore Ts'o
2017-11-28 23:49                             ` Theodore Ts'o
2017-11-29  0:18                             ` Kees Cook
2017-11-29  0:18                               ` Kees Cook
2017-11-29  0:18                               ` Kees Cook
2017-11-29  6:36                               ` Theodore Ts'o
2017-11-29  6:36                                 ` Theodore Ts'o
2017-11-29  6:36                                 ` Theodore Ts'o
2017-11-29 14:46                             ` Geo Kozey
2017-11-29 14:46                               ` Geo Kozey
2017-11-29 14:46                               ` Geo Kozey
2017-12-01 15:22                             ` Marcus Meissner
2017-12-01 15:22                               ` Marcus Meissner
2017-12-01 15:22                               ` Marcus Meissner
2017-11-28 23:53                         ` Djalal Harouni
2017-11-28 23:53                           ` Djalal Harouni
2017-11-28 23:53                           ` Djalal Harouni
2017-11-28 21:51                     ` Geo Kozey
2017-11-28 21:51                       ` Geo Kozey
2017-11-28 21:51                       ` Geo Kozey
2017-11-28 23:51                       ` Linus Torvalds
2017-11-28 23:51                         ` Linus Torvalds
2017-11-28 23:51                         ` Linus Torvalds
2017-11-29  0:17                         ` Linus Torvalds
2017-11-29  0:17                           ` Linus Torvalds
2017-11-29  0:17                           ` Linus Torvalds
2017-11-29  0:26                           ` Kees Cook
2017-11-29  0:26                             ` Kees Cook
2017-11-29  0:26                             ` Kees Cook
2017-11-29  0:50                             ` Linus Torvalds
2017-11-29  0:50                               ` Linus Torvalds
2017-11-29  0:50                               ` Linus Torvalds
2017-11-29  4:26                               ` Eric W. Biederman
2017-11-29  4:26                                 ` Eric W. Biederman
2017-11-29  4:26                                 ` Eric W. Biederman
2017-11-29 18:30                               ` Kees Cook
2017-11-29 18:30                                 ` Kees Cook
2017-11-29 18:30                                 ` Kees Cook
2017-11-29 18:46                                 ` Linus Torvalds
2017-11-29 18:46                                   ` Linus Torvalds
2017-11-29 18:46                                   ` Linus Torvalds
2017-11-29 18:53                                   ` Linus Torvalds
2017-11-29 18:53                                     ` Linus Torvalds
2017-11-29 18:53                                     ` Linus Torvalds
2017-11-29 21:17                                   ` Kees Cook
2017-11-29 21:17                                     ` Kees Cook
2017-11-29 21:17                                     ` Kees Cook
2017-11-29 22:14                                     ` Linus Torvalds
2017-11-29 22:14                                       ` Linus Torvalds
2017-11-29 22:14                                       ` Linus Torvalds
2017-11-30  0:44                                       ` Kees Cook
2017-11-30  0:44                                         ` Kees Cook
2017-11-30  0:44                                         ` Kees Cook
2017-11-30  2:08                                         ` Linus Torvalds
2017-11-30  2:08                                           ` Linus Torvalds
2017-11-30  2:08                                           ` Linus Torvalds
2017-11-30  6:51                                       ` Daniel Micay
2017-11-30  6:51                                         ` Daniel Micay
2017-11-30  6:51                                         ` Daniel Micay
2017-11-30  8:50                                         ` Djalal Harouni
2017-11-30  8:50                                           ` Djalal Harouni
2017-11-30  8:50                                           ` Djalal Harouni
2017-11-30 14:16                                           ` Theodore Ts'o
2017-11-30 14:16                                             ` Theodore Ts'o
2017-11-30 14:16                                             ` Theodore Ts'o
2017-11-30 14:51                                             ` Djalal Harouni
2017-11-30 14:51                                               ` Djalal Harouni
2017-11-30 14:51                                               ` Djalal Harouni
2017-12-01  6:39                                           ` Daniel Micay
2017-12-01  6:39                                             ` Daniel Micay
2017-12-01  6:39                                             ` Daniel Micay
2017-11-29 15:28                           ` Geo Kozey
2017-11-29 15:28                             ` Geo Kozey
2017-11-29 15:28                             ` Geo Kozey
2017-11-27 18:41 ` [PATCH v5 next 0/5] Improve Module autoloading infrastructure Linus Torvalds
2017-11-27 18:41   ` [kernel-hardening] " Linus Torvalds
2017-11-27 18:41   ` Linus Torvalds
2017-11-27 18:41   ` Linus Torvalds
2017-11-27 19:02   ` Linus Torvalds
2017-11-27 19:02     ` [kernel-hardening] " Linus Torvalds
2017-11-27 19:02     ` Linus Torvalds
2017-11-27 19:02     ` Linus Torvalds
2017-11-27 19:12     ` Linus Torvalds
2017-11-27 19:12       ` [kernel-hardening] " Linus Torvalds
2017-11-27 19:12       ` Linus Torvalds
2017-11-27 19:12       ` Linus Torvalds
2017-11-27 21:31       ` Djalal Harouni
2017-11-27 21:31         ` [kernel-hardening] " Djalal Harouni
2017-11-27 21:31         ` Djalal Harouni
2017-11-27 21:31         ` Djalal Harouni
2017-11-27 19:14   ` David Miller
2017-11-27 19:14     ` [kernel-hardening] " David Miller
2017-11-27 19:14     ` David Miller
2017-11-27 22:31     ` James Morris
2017-11-27 22:31       ` [kernel-hardening] " James Morris
2017-11-27 22:31       ` James Morris
2017-11-27 23:04       ` Kees Cook
2017-11-27 23:04         ` [kernel-hardening] " Kees Cook
2017-11-27 23:04         ` Kees Cook
2017-11-27 23:44         ` James Morris
2017-11-27 23:44           ` [kernel-hardening] " James Morris
2017-11-27 23:44           ` James Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171128191405.GO729@wotan.suse.de \
    --to=mcgrof@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=ben.hutchings@codethink.co.uk \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=james.l.morris@oracle.com \
    --cc=jeyu@kernel.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rusty@rustcorp.com.au \
    --cc=serge@hallyn.com \
    --cc=solar@openwall.com \
    --cc=tixxdz@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.