linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: lauraa@codeaurora.org (Laura Abbott)
To: linux-arm-kernel@lists.infradead.org
Subject: arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport
Date: Fri, 30 Oct 2015 08:01:35 -0700	[thread overview]
Message-ID: <5633864F.6030203@codeaurora.org> (raw)
In-Reply-To: <563335FF.5020400@huawei.com>

(cc-ing the mailing list. Please always remember to do that)

Hi,

On 10/30/15 2:18 AM, Xishi Qiu wrote:
> On 2015/10/30 16:31, Daniel Borkmann wrote:
>
>> On 10/30/2015 09:17 AM, zhong jiang wrote:
>>> hi,can I ask you a question ? say , you provide the patch is restricted within
>>> the module is used. whether it can be used to other area ofmemory like x86_64.
>>> what is the limit?
>>
>> Sorry, I don't quite understand the question. You mean ...
>>
>> commit e6a2e1b6c24a3993ffbb69a05dda202d2830ad90
>> Author: Daniel Borkmann <daniel@iogearbox.net>
>> Date:   Sun Mar 1 10:14:39 2015 +0000
>>
>>      arm64: mm: unexport set_memory_ro and set_memory_rw
>>
>>      This effectively unexports set_memory_ro and set_memory_rw functions from
>>      commit 11d91a770f1f ("arm64: Add CONFIG_DEBUG_SET_MODULE_RONX support").
>>
>>      No module user of those is in mainline kernel and we explicitly do not want
>>      modules to use these functions, as they i.e. RO-protect eBPF (interpreted and
>>      JIT'ed) images from malicious modifications/bugs.
>>
>>      Outside of eBPF scope, I believe also other set_memory_* functions should
>>      be unexported on arm64 due to non-existant mainline module user. Laura
>>      mentioned that they have some uses for modules doing set_memory_*, but
>>      none that are in mainline and it's unclear if they would ever get there.
>>
>>      Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>>      Acked-by: Alexei Starovoitov <ast@plumgrid.com>
>>      Acked-by: Laura Abbott <lauraa@codeaurora.org>
>>      Signed-off-by: Will Deacon <will.deacon@arm.com>
>>
>> ...? What is your question in relation to this?
>>
>> ( x86_64 also has an implementation of set_memory_ro(). )
>>
>> Cheers,
>> Daniel
>>
>
> Hi Daniel,
>
> Sorry for didn't saying it clearly. I find this interface(set_memory_ro/rw) can
> only be used in module address. So why not extend the function? e.g. like x86,
> it can be used in direct mapping address too.
>
> Is there some limits in arm64 or we will do this later?
>

arm64 maps low mem (all direct mapped memory on arm64) with section
mappings for performance. set_memory_ro/rw works on PAGE_SIZE
granularity so if we wanted to use those functions on direct mapped
memory we would need to break down the section mappings. On arm,
this was a pain due to the TLB maintaince requried. On arm64, less
so but we still lose the benefit of the section mappings.

Do you have a use case in mind for wanting to use set_memory_ro/rw
outside of the module area?

> One more question, in arm64, create_mapping() will create the page table of direct
> mapping area, is the page 2M or 1G? I mean like the flag PAGE_KERNEL_LARGE in x86.
>

It will try to do 1G if it can.

Thanks,
Laura

       reply	other threads:[~2015-10-30 15:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5633279A.7000003@huawei.com>
     [not found] ` <56332ADB.7030306@iogearbox.net>
     [not found]   ` <563335FF.5020400@huawei.com>
2015-10-30 15:01     ` Laura Abbott [this message]
2015-10-30 15:05       ` arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport Laura Abbott
2015-10-31  3:56         ` Xishi Qiu
2015-11-02 17:40           ` Laura Abbott
2015-11-03  1:24             ` Kees Cook
2015-11-03  2:14               ` Xishi Qiu
2015-11-03  9:10                 ` Daniel Borkmann

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=5633864F.6030203@codeaurora.org \
    --to=lauraa@codeaurora.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).