arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport

[daniel@iogearbox.net (Daniel Borkmann)]

On 11/03/2015 03:14 AM, Xishi Qiu wrote:
> On 2015/11/3 9:24, Kees Cook wrote:
>
>> On Mon, Nov 2, 2015 at 9:40 AM, Laura Abbott <laura@labbott.name> wrote:
>>> (adding Kees to see if he has any inputs)
>>>
>>> On 10/30/15 8:56 PM, Xishi Qiu wrote:
>>>>
>>>> On 2015/10/30 23:05, Laura Abbott wrote:
>>>>
>>>>>>>
>>>>>>> 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.
>>>>
>>>
>>> How long would you expected this data to stay around (minutes? hours?)
>
> Maybe forever.
>
>>> and how many instances of this would you expect?
>
>>> It also looks like BPF wants to set its region as ro when in use
>>> (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/filter.h#n370)
>
> Yes, and the memory seems from vmalloc()
...

In BPF, we have bpf_prog_alloc()/bpf_prog_realloc() helper that allocate a normal
struct bpf_prog (where we later on store BPF insns into it for the interpreter,
non executable memory here), and we have bpf_jit_binary_alloc()/bpf_jit_binary_free(),
which is executable module memory where JITs (if enabled/available) can fill their
opcodes into this image. If available, both are being ro-locked right after setup
time as they strictly must not be modified.

...
>> I think we'll start to have a growing need for this kind of thing as
>> we try to make more things RO in the heap. It's unclear to me yet how
>> much granularity we'll need, though.

Thanks,
Daniel