From: Igor Stoppa <igor.stoppa@huawei.com>
To: Casey Schaufler <casey@schaufler-ca.com>,
Christoph Hellwig <hch@infradead.org>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: <linux-security-module@vger.kernel.org>, <linux-mm@kvack.org>,
<kernel-hardening@lists.openwall.com>,
<linux-kernel@vger.kernel.org>,
"Greg KH" <gregkh@linuxfoundation.org>,
James Morris <james.l.morris@oracle.com>,
Kees Cook <keescook@chromium.org>,
Paul Moore <paul@paul-moore.com>,
"Stephen Smalley" <sds@tycho.nsa.gov>
Subject: Re: [PATCH] LSM: Make security_hook_heads a local variable.
Date: Mon, 22 May 2017 22:50:09 +0300 [thread overview]
Message-ID: <d25e2fd3-da11-4ec0-8edc-f1327c04fa6e@huawei.com> (raw)
In-Reply-To: <d98f4cd5-3f21-3f7b-2842-12b9a009e453@schaufler-ca.com>
On 22/05/17 18:09, Casey Schaufler wrote:
> On 5/22/2017 7:03 AM, Christoph Hellwig wrote:
[...]
>> But even with those we can still chain
>> them together with a list with external linkage.
>
> I gave up that approach in 2012. Too many unnecessary calls to
> null functions, and massive function vectors with a tiny number
> of non-null entries. From a data structure standpoint, it was
> just wrong. The list scheme is exactly right for the task at
> hand.
I understand this as a green light, for me to continue with the plan of
using LSM Hooks as example for making dynamically allocated data become
read-only, using also Tetsuo's patch (thanks, btw).
Is that correct?
---
thanks, igor
WARNING: multiple messages have this Message-ID (diff)
From: igor.stoppa@huawei.com (Igor Stoppa)
To: linux-security-module@vger.kernel.org
Subject: [PATCH] LSM: Make security_hook_heads a local variable.
Date: Mon, 22 May 2017 22:50:09 +0300 [thread overview]
Message-ID: <d25e2fd3-da11-4ec0-8edc-f1327c04fa6e@huawei.com> (raw)
In-Reply-To: <d98f4cd5-3f21-3f7b-2842-12b9a009e453@schaufler-ca.com>
On 22/05/17 18:09, Casey Schaufler wrote:
> On 5/22/2017 7:03 AM, Christoph Hellwig wrote:
[...]
>> But even with those we can still chain
>> them together with a list with external linkage.
>
> I gave up that approach in 2012. Too many unnecessary calls to
> null functions, and massive function vectors with a tiny number
> of non-null entries. From a data structure standpoint, it was
> just wrong. The list scheme is exactly right for the task at
> hand.
I understand this as a green light, for me to continue with the plan of
using LSM Hooks as example for making dynamically allocated data become
read-only, using also Tetsuo's patch (thanks, btw).
Is that correct?
---
thanks, igor
--
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: Igor Stoppa <igor.stoppa@huawei.com>
To: Casey Schaufler <casey@schaufler-ca.com>,
Christoph Hellwig <hch@infradead.org>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: linux-security-module@vger.kernel.org, linux-mm@kvack.org,
kernel-hardening@lists.openwall.com,
linux-kernel@vger.kernel.org,
Greg KH <gregkh@linuxfoundation.org>,
James Morris <james.l.morris@oracle.com>,
Kees Cook <keescook@chromium.org>,
Paul Moore <paul@paul-moore.com>,
Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [PATCH] LSM: Make security_hook_heads a local variable.
Date: Mon, 22 May 2017 22:50:09 +0300 [thread overview]
Message-ID: <d25e2fd3-da11-4ec0-8edc-f1327c04fa6e@huawei.com> (raw)
In-Reply-To: <d98f4cd5-3f21-3f7b-2842-12b9a009e453@schaufler-ca.com>
On 22/05/17 18:09, Casey Schaufler wrote:
> On 5/22/2017 7:03 AM, Christoph Hellwig wrote:
[...]
>> But even with those we can still chain
>> them together with a list with external linkage.
>
> I gave up that approach in 2012. Too many unnecessary calls to
> null functions, and massive function vectors with a tiny number
> of non-null entries. From a data structure standpoint, it was
> just wrong. The list scheme is exactly right for the task at
> hand.
I understand this as a green light, for me to continue with the plan of
using LSM Hooks as example for making dynamically allocated data become
read-only, using also Tetsuo's patch (thanks, btw).
Is that correct?
---
thanks, igor
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Igor Stoppa <igor.stoppa@huawei.com>
To: Casey Schaufler <casey@schaufler-ca.com>,
Christoph Hellwig <hch@infradead.org>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: linux-security-module@vger.kernel.org, linux-mm@kvack.org,
kernel-hardening@lists.openwall.com,
linux-kernel@vger.kernel.org,
Greg KH <gregkh@linuxfoundation.org>,
James Morris <james.l.morris@oracle.com>,
Kees Cook <keescook@chromium.org>,
Paul Moore <paul@paul-moore.com>,
Stephen Smalley <sds@tycho.nsa.gov>
Subject: [kernel-hardening] Re: [PATCH] LSM: Make security_hook_heads a local variable.
Date: Mon, 22 May 2017 22:50:09 +0300 [thread overview]
Message-ID: <d25e2fd3-da11-4ec0-8edc-f1327c04fa6e@huawei.com> (raw)
In-Reply-To: <d98f4cd5-3f21-3f7b-2842-12b9a009e453@schaufler-ca.com>
On 22/05/17 18:09, Casey Schaufler wrote:
> On 5/22/2017 7:03 AM, Christoph Hellwig wrote:
[...]
>> But even with those we can still chain
>> them together with a list with external linkage.
>
> I gave up that approach in 2012. Too many unnecessary calls to
> null functions, and massive function vectors with a tiny number
> of non-null entries. From a data structure standpoint, it was
> just wrong. The list scheme is exactly right for the task at
> hand.
I understand this as a green light, for me to continue with the plan of
using LSM Hooks as example for making dynamically allocated data become
read-only, using also Tetsuo's patch (thanks, btw).
Is that correct?
---
thanks, igor
next prev parent reply other threads:[~2017-05-22 19:51 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-19 10:38 [RFC v3]mm: ro protection for data allocated dynamically Igor Stoppa
2017-05-19 10:38 ` [kernel-hardening] " Igor Stoppa
2017-05-19 10:38 ` Igor Stoppa
2017-05-19 10:38 ` [PATCH 1/1] Sealable memory support Igor Stoppa
2017-05-19 10:38 ` [kernel-hardening] " Igor Stoppa
2017-05-19 10:38 ` Igor Stoppa
2017-05-20 8:51 ` [kernel-hardening] " Greg KH
2017-05-20 8:51 ` Greg KH
2017-05-21 11:14 ` [PATCH] LSM: Make security_hook_heads a local variable Tetsuo Handa
2017-05-21 11:14 ` [kernel-hardening] " Tetsuo Handa
2017-05-21 11:14 ` Tetsuo Handa
2017-05-21 11:14 ` Tetsuo Handa
2017-05-22 14:03 ` Christoph Hellwig
2017-05-22 14:03 ` [kernel-hardening] " Christoph Hellwig
2017-05-22 14:03 ` Christoph Hellwig
2017-05-22 14:03 ` Christoph Hellwig
2017-05-22 15:09 ` Casey Schaufler
2017-05-22 15:09 ` [kernel-hardening] " Casey Schaufler
2017-05-22 15:09 ` Casey Schaufler
2017-05-22 15:09 ` Casey Schaufler
2017-05-22 19:50 ` Igor Stoppa [this message]
2017-05-22 19:50 ` [kernel-hardening] " Igor Stoppa
2017-05-22 19:50 ` Igor Stoppa
2017-05-22 19:50 ` Igor Stoppa
2017-05-22 20:32 ` Casey Schaufler
2017-05-22 20:32 ` [kernel-hardening] " Casey Schaufler
2017-05-22 20:32 ` Casey Schaufler
2017-05-22 20:32 ` Casey Schaufler
2017-05-22 20:43 ` Tetsuo Handa
2017-05-22 20:43 ` [kernel-hardening] " Tetsuo Handa
2017-05-22 20:43 ` Tetsuo Handa
2017-05-22 20:43 ` Tetsuo Handa
2017-05-22 19:45 ` [kernel-hardening] [PATCH 1/1] Sealable memory support Igor Stoppa
2017-05-22 19:45 ` Igor Stoppa
2017-05-22 19:45 ` Igor Stoppa
2017-05-22 21:38 ` Kees Cook
2017-05-22 21:38 ` [kernel-hardening] " Kees Cook
2017-05-22 21:38 ` Kees Cook
2017-05-23 9:43 ` Igor Stoppa
2017-05-23 9:43 ` [kernel-hardening] " Igor Stoppa
2017-05-23 9:43 ` Igor Stoppa
2017-05-23 20:11 ` Kees Cook
2017-05-23 20:11 ` [kernel-hardening] " Kees Cook
2017-05-23 20:11 ` Kees Cook
2017-05-24 17:45 ` Igor Stoppa
2017-05-24 17:45 ` [kernel-hardening] " Igor Stoppa
2017-05-24 17:45 ` Igor Stoppa
2017-05-28 18:23 ` Kees Cook
2017-05-28 18:23 ` [kernel-hardening] " Kees Cook
2017-05-28 18:23 ` Kees Cook
2017-05-28 18:56 ` [kernel-hardening] " Boris Lukashev
2017-05-28 18:56 ` Boris Lukashev
2017-05-28 18:56 ` Boris Lukashev
2017-05-28 21:32 ` Kees Cook
2017-05-28 21:32 ` Kees Cook
2017-05-28 21:32 ` Kees Cook
2017-05-29 6:04 ` Boris Lukashev
2017-05-29 6:04 ` Boris Lukashev
2017-05-29 6:04 ` Boris Lukashev
2017-05-31 21:22 ` Igor Stoppa
2017-05-31 21:22 ` [kernel-hardening] " Igor Stoppa
2017-05-31 21:22 ` Igor Stoppa
2017-05-31 13:55 ` kbuild test robot
2017-05-31 13:55 ` [kernel-hardening] " kbuild test robot
2017-05-31 13:55 ` kbuild test robot
2017-06-04 2:18 ` kbuild test robot
2017-06-04 2:18 ` [kernel-hardening] " kbuild test robot
2017-06-04 2:18 ` kbuild test robot
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=d25e2fd3-da11-4ec0-8edc-f1327c04fa6e@huawei.com \
--to=igor.stoppa@huawei.com \
--cc=casey@schaufler-ca.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=james.l.morris@oracle.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=sds@tycho.nsa.gov \
/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.