On 2015/10/30 23:05, Laura Abbott wrote:

(Argh sent that from old e-mail address. I didn't even realize
I could send anymore. Please disregard the source of that old
e-mail if it ends up going through)

On 10/30/15 8:01 AM, Laura Abbott wrote:

quoted

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

Hi,

On 10/30/15 2:18 AM, Xishi Qiu wrote:

quoted

On 2015/10/30 16:31, Daniel Borkmann wrote:

quoted

On 10/30/2015 09:17 AM, zhong jiang wrote:

quoted

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 [off-list ref]
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 [off-list ref]
     Acked-by: Alexei Starovoitov [off-list ref]
     Acked-by: Laura Abbott [off-list ref]
     Signed-off-by: Will Deacon [off-list ref]

...? 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?

Hi Laura,

How about this case?

module alloc some pages which from direct mapping area, and we write
important data(e.g. password) on the pages, the data will not be changed
during the runtime. If someone unfriendly try to rewrite the memory,
something is going to get worse. So we can use set_memory_ro() to protect
the date. 

Thanks,
Xishi Qiu

quoted

quoted

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

.