arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport

DISCUSSION Laura Abbott 5 participants 7 messages Oct 30, 2015 – Nov 3, 2015 3 messages not in the archive

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Laura Abbott

author

2015-10-30 15:01 UTC #3 lore raw

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

Hi,

Quoted 40 lines · Xishi Qiu

Quoted 30 lines · Daniel Borkmann
Quoted 3 lines · zhong jiang
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 <[email protected]>
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 <[email protected]>
Acked-by Alexei Starovoitov <[email protected]>
Acked-by Laura Abbott <[email protected]>
Signed-off-by Will Deacon <[email protected]>
Quoted 7 lines
...? What is your question in relation to this?
( x86_64 also has an implementation of set_memory_ro(). )
Cheers,
Daniel

Quoted 8 lines

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?

Quoted 3 lines

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

Laura Abbott

2015-10-30 15:05 UTC #4 lore raw

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

Quoted 86 lines · Laura Abbott

(cc-ing the mailing list. Please always remember to do that)
Hi,
Quoted 52 lines · Xishi Qiu
Quoted 40 lines · Daniel Borkmann
Quoted 5 lines · zhong jiang
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 <[email protected]>
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 <[email protected]>
Acked-by Alexei Starovoitov <[email protected]>
Acked-by Laura Abbott <[email protected]>
Signed-off-by Will Deacon <[email protected]>
Quoted 7 lines
...? What is your question in relation to this?
( x86_64 also has an implementation of set_memory_ro(). )
Cheers,
Daniel
Hi Daniel,
Quoted 8 lines
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?
Quoted 5 lines
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

Xishi Qiu

2015-10-31 03:56 UTC #5 lore raw

Quoted 4 lines · 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)

Quoted 77 lines

Quoted 76 lines · Laura Abbott
(cc-ing the mailing list. Please always remember to do that)
Hi,
Quoted 52 lines · Xishi Qiu
Quoted 40 lines · Daniel Borkmann
Quoted 5 lines · zhong jiang
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 <[email protected]>
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 <[email protected]>
Acked-by Alexei Starovoitov <[email protected]>
Acked-by Laura Abbott <[email protected]>
Signed-off-by Will Deacon <[email protected]>
Quoted 7 lines
...? What is your question in relation to this?
( x86_64 also has an implementation of set_memory_ro(). )
Cheers,
Daniel
Hi Daniel,
Quoted 8 lines
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 13 lines

Quoted 10 lines
Quoted 5 lines
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
.

Laura Abbott

2015-11-02 17:40 UTC #6 lore raw

(adding Kees to see if he has any inputs)

Quoted 27 lines · Xishi Qiu

Quoted 19 lines · Laura Abbott
Quoted 19 lines
Quoted 11 lines
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.
Quoted 3 lines
Quoted 3 lines
Do you have a use case in mind for wanting to use set_memory_ro/rw outside of the module area?
Hi Laura,

Quoted 8 lines

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

Kees Cook

2015-11-03 01:24 UTC #7 lore raw

Quoted 43 lines · Laura Abbott

(adding Kees to see if he has any inputs)
Quoted 28 lines · Xishi Qiu
Quoted 19 lines · Laura Abbott
Quoted 19 lines
Quoted 11 lines
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.
Quoted 3 lines
Quoted 3 lines
Do you have a use case in mind for wanting to use set_memory_ro/rw outside of the module area?
Hi Laura,
Quoted 8 lines
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?

Quoted 7 lines

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

Signature · 2 lines

Kees Cook
Chrome OS Security

Xishi Qiu

2015-11-03 02:14 UTC #8 lore raw

Quoted 34 lines · Kees Cook

Quoted 33 lines · Laura Abbott
(adding Kees to see if he has any inputs)
Quoted 30 lines · Xishi Qiu
Quoted 19 lines · Laura Abbott
Quoted 19 lines
Quoted 11 lines
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.
Quoted 3 lines
Quoted 3 lines
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?

Quoted 8 lines

Quoted 8 lines
Quoted 6 lines
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.

Quoted 5 lines

Quoted 5 lines
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

Quoted 12 lines

Quoted 5 lines
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

Daniel Borkmann

2015-11-03 09:10 UTC #9 lore raw

Quoted 45 lines · Xishi Qiu

Quoted 34 lines · Kees Cook
Quoted 33 lines · Laura Abbott
(adding Kees to see if he has any inputs)
Quoted 30 lines · Xishi Qiu
Quoted 19 lines · Laura Abbott
Quoted 19 lines
Quoted 11 lines
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.
Quoted 3 lines
Quoted 3 lines
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?
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
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?)

Quoted 8 lines

Maybe forever.
Quoted 4 lines
Quoted 4 lines
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.

...

Quoted 3 lines

Quoted 3 lines
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