From: Jerome Glisse <jglisse@redhat.com>
To: Igor Stoppa <igor.stoppa@huawei.com>
Cc: keescook@chromium.org, mhocko@kernel.org, jmorris@namei.org,
labbott@redhat.com, hch@infradead.org,
penguin-kernel@I-love.SAKURA.ne.jp, paul@paul-moore.com,
sds@tycho.nsa.gov, casey@schaufler-ca.com,
linux-security-module@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: [kernel-hardening] Re: [PATCH 1/3] Protectable memory support
Date: Fri, 7 Jul 2017 14:48:44 -0400 [thread overview]
Message-ID: <20170707184843.GA3113@redhat.com> (raw)
In-Reply-To: <1665fd00-5908-2399-577d-1972c7d1c63b@huawei.com>
On Fri, Jul 07, 2017 at 11:42:09AM +0300, Igor Stoppa wrote:
> On 06/07/17 19:27, Jerome Glisse wrote:
> > On Wed, Jul 05, 2017 at 04:46:26PM +0300, Igor Stoppa wrote:
[...]
> > Yet another way is to use some of the free struct page fields ie
> > when a page is allocated for vmalloc i think most of struct page
> > fields are unuse (mapping, index, lru, ...). It would be better
> > to use those rather than adding a page flag.
>
> Like introducing an unnamed union? Some sort of vmalloc_page_subtype?
> If that is what you are proposing, I agree that it would work in a
> similar fashion as what I have now, but without introducing the overhead
> of the extra page flag.
No need to introduce unamed union or anything. Just use one of the
existing field for install you can make page->mapping point to the
pmalloc pool structure. Or you can store a unique key value.
I believe there is enough unuse field that for vmalloc pages that
you should find one you can use. Just add some documentation in
mm_types.h so people are aware of alternate use for the field you
are using.
Jérôme
WARNING: multiple messages have this Message-ID (diff)
From: jglisse@redhat.com (Jerome Glisse)
To: linux-security-module@vger.kernel.org
Subject: [PATCH 1/3] Protectable memory support
Date: Fri, 7 Jul 2017 14:48:44 -0400 [thread overview]
Message-ID: <20170707184843.GA3113@redhat.com> (raw)
In-Reply-To: <1665fd00-5908-2399-577d-1972c7d1c63b@huawei.com>
On Fri, Jul 07, 2017 at 11:42:09AM +0300, Igor Stoppa wrote:
> On 06/07/17 19:27, Jerome Glisse wrote:
> > On Wed, Jul 05, 2017 at 04:46:26PM +0300, Igor Stoppa wrote:
[...]
> > Yet another way is to use some of the free struct page fields ie
> > when a page is allocated for vmalloc i think most of struct page
> > fields are unuse (mapping, index, lru, ...). It would be better
> > to use those rather than adding a page flag.
>
> Like introducing an unnamed union? Some sort of vmalloc_page_subtype?
> If that is what you are proposing, I agree that it would work in a
> similar fashion as what I have now, but without introducing the overhead
> of the extra page flag.
No need to introduce unamed union or anything. Just use one of the
existing field for install you can make page->mapping point to the
pmalloc pool structure. Or you can store a unique key value.
I believe there is enough unuse field that for vmalloc pages that
you should find one you can use. Just add some documentation in
mm_types.h so people are aware of alternate use for the field you
are using.
J?r?me
--
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: Jerome Glisse <jglisse@redhat.com>
To: Igor Stoppa <igor.stoppa@huawei.com>
Cc: keescook@chromium.org, mhocko@kernel.org, jmorris@namei.org,
labbott@redhat.com, hch@infradead.org,
penguin-kernel@I-love.SAKURA.ne.jp, paul@paul-moore.com,
sds@tycho.nsa.gov, casey@schaufler-ca.com,
linux-security-module@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 1/3] Protectable memory support
Date: Fri, 7 Jul 2017 14:48:44 -0400 [thread overview]
Message-ID: <20170707184843.GA3113@redhat.com> (raw)
In-Reply-To: <1665fd00-5908-2399-577d-1972c7d1c63b@huawei.com>
On Fri, Jul 07, 2017 at 11:42:09AM +0300, Igor Stoppa wrote:
> On 06/07/17 19:27, Jerome Glisse wrote:
> > On Wed, Jul 05, 2017 at 04:46:26PM +0300, Igor Stoppa wrote:
[...]
> > Yet another way is to use some of the free struct page fields ie
> > when a page is allocated for vmalloc i think most of struct page
> > fields are unuse (mapping, index, lru, ...). It would be better
> > to use those rather than adding a page flag.
>
> Like introducing an unnamed union? Some sort of vmalloc_page_subtype?
> If that is what you are proposing, I agree that it would work in a
> similar fashion as what I have now, but without introducing the overhead
> of the extra page flag.
No need to introduce unamed union or anything. Just use one of the
existing field for install you can make page->mapping point to the
pmalloc pool structure. Or you can store a unique key value.
I believe there is enough unuse field that for vmalloc pages that
you should find one you can use. Just add some documentation in
mm_types.h so people are aware of alternate use for the field you
are using.
Jerome
--
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: Jerome Glisse <jglisse@redhat.com>
To: Igor Stoppa <igor.stoppa@huawei.com>
Cc: keescook@chromium.org, mhocko@kernel.org, jmorris@namei.org,
labbott@redhat.com, hch@infradead.org,
penguin-kernel@I-love.SAKURA.ne.jp, paul@paul-moore.com,
sds@tycho.nsa.gov, casey@schaufler-ca.com,
linux-security-module@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 1/3] Protectable memory support
Date: Fri, 7 Jul 2017 14:48:44 -0400 [thread overview]
Message-ID: <20170707184843.GA3113@redhat.com> (raw)
In-Reply-To: <1665fd00-5908-2399-577d-1972c7d1c63b@huawei.com>
On Fri, Jul 07, 2017 at 11:42:09AM +0300, Igor Stoppa wrote:
> On 06/07/17 19:27, Jerome Glisse wrote:
> > On Wed, Jul 05, 2017 at 04:46:26PM +0300, Igor Stoppa wrote:
[...]
> > Yet another way is to use some of the free struct page fields ie
> > when a page is allocated for vmalloc i think most of struct page
> > fields are unuse (mapping, index, lru, ...). It would be better
> > to use those rather than adding a page flag.
>
> Like introducing an unnamed union? Some sort of vmalloc_page_subtype?
> If that is what you are proposing, I agree that it would work in a
> similar fashion as what I have now, but without introducing the overhead
> of the extra page flag.
No need to introduce unamed union or anything. Just use one of the
existing field for install you can make page->mapping point to the
pmalloc pool structure. Or you can store a unique key value.
I believe there is enough unuse field that for vmalloc pages that
you should find one you can use. Just add some documentation in
mm_types.h so people are aware of alternate use for the field you
are using.
Jérôme
next prev parent reply other threads:[~2017-07-07 18:48 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-05 13:46 [kernel-hardening] [PATCH v9 0/3] mm: security: ro protection for dynamic data Igor Stoppa
2017-07-05 13:46 ` Igor Stoppa
2017-07-05 13:46 ` Igor Stoppa
2017-07-05 13:46 ` Igor Stoppa
2017-07-05 13:46 ` [kernel-hardening] [PATCH 1/3] Protectable memory support Igor Stoppa
2017-07-05 13:46 ` Igor Stoppa
2017-07-05 13:46 ` Igor Stoppa
2017-07-05 13:46 ` Igor Stoppa
2017-07-06 16:27 ` [kernel-hardening] " Jerome Glisse
2017-07-06 16:27 ` Jerome Glisse
2017-07-06 16:27 ` Jerome Glisse
2017-07-06 16:27 ` Jerome Glisse
2017-07-07 8:42 ` [kernel-hardening] " Igor Stoppa
2017-07-07 8:42 ` Igor Stoppa
2017-07-07 8:42 ` Igor Stoppa
2017-07-07 8:42 ` Igor Stoppa
2017-07-07 18:48 ` Jerome Glisse [this message]
2017-07-07 18:48 ` Jerome Glisse
2017-07-07 18:48 ` Jerome Glisse
2017-07-07 18:48 ` Jerome Glisse
2017-07-10 15:15 ` [kernel-hardening] " Igor Stoppa
2017-07-10 15:15 ` Igor Stoppa
2017-07-10 15:15 ` Igor Stoppa
2017-07-10 15:15 ` Igor Stoppa
2017-07-05 13:46 ` [kernel-hardening] [PATCH 2/3] LSM: Convert security_hook_heads into explicit array of struct list_head Igor Stoppa
2017-07-05 13:46 ` Igor Stoppa
2017-07-05 13:46 ` Igor Stoppa
2017-07-05 13:46 ` Igor Stoppa
2017-07-05 13:46 ` [kernel-hardening] [PATCH 3/3] Make LSM Writable Hooks a command line option Igor Stoppa
2017-07-05 13:46 ` Igor Stoppa
2017-07-05 13:46 ` Igor Stoppa
2017-07-05 13:46 ` Igor Stoppa
-- strict thread matches above, loose matches on Subject: below --
2017-07-10 15:06 [kernel-hardening] [PATCH 1/3] Protectable memory support Igor Stoppa
2017-07-11 2:05 ` [kernel-hardening] " kbuild test robot
2017-06-26 14:41 [kernel-hardening] " Igor Stoppa
2017-06-27 3:17 ` [kernel-hardening] " kbuild test robot
2017-06-27 3:55 ` 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=20170707184843.GA3113@redhat.com \
--to=jglisse@redhat.com \
--cc=casey@schaufler-ca.com \
--cc=hch@infradead.org \
--cc=igor.stoppa@huawei.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mhocko@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.