* arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport [not found] ` <563335FF.5020400@huawei.com> @ 2015-10-30 15:01 ` Laura Abbott 2015-10-30 15:05 ` Laura Abbott 0 siblings, 1 reply; 7+ messages in thread From: Laura Abbott @ 2015-10-30 15:01 UTC (permalink / raw) To: linux-arm-kernel (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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport 2015-10-30 15:01 ` arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport Laura Abbott @ 2015-10-30 15:05 ` Laura Abbott 2015-10-31 3:56 ` Xishi Qiu 0 siblings, 1 reply; 7+ messages in thread From: Laura Abbott @ 2015-10-30 15:05 UTC (permalink / raw) To: linux-arm-kernel (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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport 2015-10-30 15:05 ` Laura Abbott @ 2015-10-31 3:56 ` Xishi Qiu 2015-11-02 17:40 ` Laura Abbott 0 siblings, 1 reply; 7+ messages in thread From: Xishi Qiu @ 2015-10-31 3:56 UTC (permalink / raw) To: linux-arm-kernel 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 > > . > ^ permalink raw reply [flat|nested] 7+ messages in thread
* arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport 2015-10-31 3:56 ` Xishi Qiu @ 2015-11-02 17:40 ` Laura Abbott 2015-11-03 1:24 ` Kees Cook 0 siblings, 1 reply; 7+ messages in thread From: Laura Abbott @ 2015-11-02 17:40 UTC (permalink / raw) To: linux-arm-kernel (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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport 2015-11-02 17:40 ` Laura Abbott @ 2015-11-03 1:24 ` Kees Cook 2015-11-03 2:14 ` Xishi Qiu 0 siblings, 1 reply; 7+ messages in thread From: Kees Cook @ 2015-11-03 1:24 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport 2015-11-03 1:24 ` Kees Cook @ 2015-11-03 2:14 ` Xishi Qiu 2015-11-03 9:10 ` Daniel Borkmann 0 siblings, 1 reply; 7+ messages in thread From: Xishi Qiu @ 2015-11-03 2:14 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport 2015-11-03 2:14 ` Xishi Qiu @ 2015-11-03 9:10 ` Daniel Borkmann 0 siblings, 0 replies; 7+ messages in thread From: Daniel Borkmann @ 2015-11-03 9:10 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-11-03 9:10 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <5633279A.7000003@huawei.com>
[not found] ` <56332ADB.7030306@iogearbox.net>
[not found] ` <563335FF.5020400@huawei.com>
2015-10-30 15:01 ` arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport Laura Abbott
2015-10-30 15:05 ` Laura Abbott
2015-10-31 3:56 ` Xishi Qiu
2015-11-02 17:40 ` Laura Abbott
2015-11-03 1:24 ` Kees Cook
2015-11-03 2:14 ` Xishi Qiu
2015-11-03 9:10 ` Daniel Borkmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).