arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport

Kees Cook keescook at chromium.org
Mon Nov 2 17:24:42 PST 2015


On Mon, Nov 2, 2015 at 9:40 AM, Laura Abbott <laura at 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?)
> 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)
> So it's not completely unheard of.
> I don't think it would be too difficult to take the
> split_{pud,pmd} functions used for the direct mapping and apply them
> for the page_attr if people are willing to make the security/performance
> trade off.

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.

-Kees

-- 
Kees Cook
Chrome OS Security



More information about the linux-arm-kernel mailing list