All of lore.kernel.org
 help / color / mirror / Atom feed
From: qiuxishi@huawei.com (Xishi Qiu)
To: linux-arm-kernel@lists.infradead.org
Subject: Have any influence on set_memory_** about below patch ??
Date: Thu, 14 Jan 2016 20:35:45 +0800	[thread overview]
Message-ID: <56979621.1060102@huawei.com> (raw)
In-Reply-To: <20160113111806.GC23370@leverpostej>

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?

Thanks,
Xishi Qiu

> Thanks,
> Mark.
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/397320.html
> 
> .
> 

WARNING: multiple messages have this Message-ID (diff)
From: Xishi Qiu <qiuxishi@huawei.com>
To: Mark Rutland <mark.rutland@arm.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>
Subject: Re: Have any influence on set_memory_** about below patch ??
Date: Thu, 14 Jan 2016 20:35:45 +0800	[thread overview]
Message-ID: <56979621.1060102@huawei.com> (raw)
In-Reply-To: <20160113111806.GC23370@leverpostej>

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?

Thanks,
Xishi Qiu

> Thanks,
> Mark.
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/397320.html
> 
> .
> 

  reply	other threads:[~2016-01-14 12:35 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 [this message]
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
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=56979621.1060102@huawei.com \
    --to=qiuxishi@huawei.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.