arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport

arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport

[Laura Abbott]

(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

arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport

[Laura Abbott]

(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@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

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

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

arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport

[Laura Abbott]

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

Thanks,
Laura

arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport

[Kees Cook]

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

arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport

[Xishi Qiu]

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()
bpf_prog_realloc()
	...
	fp = __vmalloc(size, gfp_flags, PAGE_KERNEL);
	...
	fp->pages = size / PAGE_SIZE;
	...

So we'd better to support the whole kernel space(module/vmalloc/direct mapping, 
any others?).

Thanks,
Xishi Qiu

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

arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport

[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