Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1647361
| From | Casey Schaufler <casey@schaufler-ca.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] LSM: Make security_hook_heads a local variable. |
| Date | 2017-05-22 22:40 +0200 |
| Message-ID | <tK2hs-1Tl-29@gated-at.bofh.it> (permalink) |
| References | <tJ8oW-7k0-17@gated-at.bofh.it> <tJx3X-75V-1@gated-at.bofh.it> <tJWc2-6Hl-29@gated-at.bofh.it> <tJX86-7gH-23@gated-at.bofh.it> <tK1EK-1rk-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 5/22/2017 12:50 PM, Igor Stoppa wrote: > 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). I still don't like the assumption that a structure of N elements can be assumed to be the same as an array of N elements. Putting on my hardening hat, however, I like the smalloc() solution to keeping the hook lists safe, so I am willing to swallow the objection to using offsets to address the existing exposure. > > 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC v3]mm: ro protection for data allocated dynamically Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-19 12:40 +0200
[PATCH 1/1] Sealable memory support Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-19 12:50 +0200
Re: [kernel-hardening] [PATCH 1/1] Sealable memory support Greg KH <gregkh@linuxfoundation.org> - 2017-05-20 11:00 +0200
[PATCH] LSM: Make security_hook_heads a local variable. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-05-21 13:20 +0200
Re: [PATCH] LSM: Make security_hook_heads a local variable. Christoph Hellwig <hch@infradead.org> - 2017-05-22 16:10 +0200
Re: [PATCH] LSM: Make security_hook_heads a local variable. Casey Schaufler <casey@schaufler-ca.com> - 2017-05-22 17:10 +0200
Re: [PATCH] LSM: Make security_hook_heads a local variable. Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-22 22:00 +0200
Re: [PATCH] LSM: Make security_hook_heads a local variable. Casey Schaufler <casey@schaufler-ca.com> - 2017-05-22 22:40 +0200
Re: [PATCH] LSM: Make security_hook_heads a local variable. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-05-22 22:50 +0200
Re: [kernel-hardening] [PATCH 1/1] Sealable memory support Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-22 21:50 +0200
Re: [PATCH 1/1] Sealable memory support Kees Cook <keescook@chromium.org> - 2017-05-22 23:40 +0200
Re: [PATCH 1/1] Sealable memory support Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-23 11:50 +0200
Re: [PATCH 1/1] Sealable memory support Kees Cook <keescook@google.com> - 2017-05-24 00:40 +0200
Re: [PATCH 1/1] Sealable memory support Igor Stoppa <igor.stoppa@huawei.com> - 2017-05-24 19:50 +0200
csiph-web