arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport

[Xishi Qiu]

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:
>> (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 at 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 at iogearbox.net>
>>>>      Acked-by: Alexei Starovoitov <ast at plumgrid.com>
>>>>      Acked-by: Laura Abbott <lauraa at codeaurora.org>
>>>>      Signed-off-by: Will Deacon <will.deacon at 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?
>>

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

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