From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: Have any influence on set_memory_** about below patch ??
Date: Thu, 14 Jan 2016 13:44:49 +0000 [thread overview]
Message-ID: <20160114134448.GB27039@leverpostej> (raw)
In-Reply-To: <56979D40.4060602@huawei.com>
On Thu, Jan 14, 2016 at 09:06:08PM +0800, Xishi Qiu wrote:
> On 2016/1/14 20:35, Xishi Qiu wrote:
>
> > On 2016/1/13 19:18, Mark Rutland wrote:
> >
> >> On Wed, Jan 13, 2016 at 06:30:06PM +0800, Xishi Qiu wrote:
> >>> Hi Mark,
> >>>
> >>> If I create swapper page tables by 4kb, not large page, then I use
> >>> set_memory_ro() to change the pate table flag, does it have the problem
> >>> too?
> >>
> >> The splitting/merging problem would not apply.
> >>
> >> However, you're going to waste a reasonable amount of memory by not
> >> using section mappings in the swapper, and we gain additional complexity
> >> in the page table setup code (which is shared with others things that
> >> want section mappings).
> >>
> >> What are you exactly actually trying to achieve?
> >>
> >
> > If module allocates some pages and save data on them, and the data will
> > not be changed during the module running. So we want to use set_memory_ro()
> > to increase the security. If the data is changed, we can catch someone.
> >
> >> What memory do you want to mark RO, and why?
> >>
> >
> > The key data, and it will not be changed during the running time.
> >
> >> >From a previous discussion [1], we figured out alternative approaches
> >> for common cases. Do none of those work for your case?
> >>
> >
> > I have not read the patchset carefully, could you tell me the general meaning
> > of the approaches?
> >
>
> Hi Mark,
>
> Is the two approaches like following?
> 1. use create_mapping to map the data in read only, then use fixmap to create a
> temp page table, and change the data when necessary.
In your code you'd have to statically place the data in .rodata somehow
(e.g. [2]). Your code would not call create_mapping. The usual init code
would take care of that.
Note that this can only work for a fixed amount of data, whereas it
sounds like you are doing dynamic allocation.
> 2. use vmalloc, then we can use set_memory_ro to change the page table prot.
Something like this should be workable, yes. See [3,4].
> >> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/397320.html
[2] https://lkml.org/lkml/2015/11/24/724
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399015.html
[4] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399252.html
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Xishi Qiu <qiuxishi@huawei.com>
Cc: zhong jiang <zhongjiang@huawei.com>,
Laura Abbott <labbott@fedoraproject.org>,
Hanjun Guo <guohanjun@huawei.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
ard.biesheuvel@linaro.org
Subject: Re: Have any influence on set_memory_** about below patch ??
Date: Thu, 14 Jan 2016 13:44:49 +0000 [thread overview]
Message-ID: <20160114134448.GB27039@leverpostej> (raw)
In-Reply-To: <56979D40.4060602@huawei.com>
On Thu, Jan 14, 2016 at 09:06:08PM +0800, Xishi Qiu wrote:
> On 2016/1/14 20:35, Xishi Qiu wrote:
>
> > On 2016/1/13 19:18, Mark Rutland wrote:
> >
> >> On Wed, Jan 13, 2016 at 06:30:06PM +0800, Xishi Qiu wrote:
> >>> Hi Mark,
> >>>
> >>> If I create swapper page tables by 4kb, not large page, then I use
> >>> set_memory_ro() to change the pate table flag, does it have the problem
> >>> too?
> >>
> >> The splitting/merging problem would not apply.
> >>
> >> However, you're going to waste a reasonable amount of memory by not
> >> using section mappings in the swapper, and we gain additional complexity
> >> in the page table setup code (which is shared with others things that
> >> want section mappings).
> >>
> >> What are you exactly actually trying to achieve?
> >>
> >
> > If module allocates some pages and save data on them, and the data will
> > not be changed during the module running. So we want to use set_memory_ro()
> > to increase the security. If the data is changed, we can catch someone.
> >
> >> What memory do you want to mark RO, and why?
> >>
> >
> > The key data, and it will not be changed during the running time.
> >
> >> >From a previous discussion [1], we figured out alternative approaches
> >> for common cases. Do none of those work for your case?
> >>
> >
> > I have not read the patchset carefully, could you tell me the general meaning
> > of the approaches?
> >
>
> Hi Mark,
>
> Is the two approaches like following?
> 1. use create_mapping to map the data in read only, then use fixmap to create a
> temp page table, and change the data when necessary.
In your code you'd have to statically place the data in .rodata somehow
(e.g. [2]). Your code would not call create_mapping. The usual init code
would take care of that.
Note that this can only work for a fixed amount of data, whereas it
sounds like you are doing dynamic allocation.
> 2. use vmalloc, then we can use set_memory_ro to change the page table prot.
Something like this should be workable, yes. See [3,4].
> >> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/397320.html
[2] https://lkml.org/lkml/2015/11/24/724
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399015.html
[4] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399252.html
Thanks,
Mark.
next prev parent reply other threads:[~2016-01-14 13:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5693A740.7070408@huawei.com>
[not found] ` <20160111133145.GM6499@leverpostej>
2016-01-12 1:20 ` Have any influence on set_memory_** about below patch ?? Xishi Qiu
2016-01-12 1:20 ` Xishi Qiu
2016-01-12 11:15 ` Mark Rutland
2016-01-12 11:15 ` Mark Rutland
2016-01-13 4:10 ` Xishi Qiu
2016-01-13 4:10 ` Xishi Qiu
2016-01-13 11:22 ` Mark Rutland
2016-01-13 11:22 ` Mark Rutland
2016-01-13 5:02 ` Xishi Qiu
2016-01-13 5:02 ` Xishi Qiu
2016-01-13 6:35 ` Xishi Qiu
2016-01-13 6:35 ` Xishi Qiu
2016-01-13 11:28 ` Mark Rutland
2016-01-13 11:28 ` Mark Rutland
2016-01-27 1:18 ` Xishi Qiu
2016-01-27 1:18 ` Xishi Qiu
2016-01-27 11:25 ` Mark Rutland
2016-01-27 11:25 ` Mark Rutland
2016-01-26 14:05 ` zhong jiang
2016-01-26 14:05 ` zhong jiang
2016-01-26 16:07 ` Mark Rutland
2016-01-26 16:07 ` Mark Rutland
2016-01-13 10:30 ` Xishi Qiu
2016-01-13 10:30 ` Xishi Qiu
2016-01-13 11:18 ` Mark Rutland
2016-01-13 11:18 ` Mark Rutland
2016-01-14 12:35 ` Xishi Qiu
2016-01-14 12:35 ` Xishi Qiu
2016-01-14 13:06 ` Xishi Qiu
2016-01-14 13:06 ` Xishi Qiu
2016-01-14 13:44 ` Mark Rutland [this message]
2016-01-14 13:44 ` Mark Rutland
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=20160114134448.GB27039@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.