* [kernel-hardening][RFD] Is there any plan to port the RAP feature from PAX/Grsecurity to main line ? @ 2017-08-04 4:23 Li Kun 2017-08-04 5:13 ` Kees Cook 0 siblings, 1 reply; 6+ messages in thread From: Li Kun @ 2017-08-04 4:23 UTC (permalink / raw) To: Kees Cook, kernel-hardening Hi all, Is there any plan to port the RAP feature from PAX/Grsecurity to main line ? I think that will be a realy effective approach to protect against ROP/JOP. -- Best Regards Li Kun ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [kernel-hardening][RFD] Is there any plan to port the RAP feature from PAX/Grsecurity to main line ? 2017-08-04 4:23 [kernel-hardening][RFD] Is there any plan to port the RAP feature from PAX/Grsecurity to main line ? Li Kun @ 2017-08-04 5:13 ` Kees Cook 2017-08-04 10:31 ` Li Kun 0 siblings, 1 reply; 6+ messages in thread From: Kees Cook @ 2017-08-04 5:13 UTC (permalink / raw) To: Li Kun; +Cc: kernel-hardening On Thu, Aug 3, 2017 at 9:23 PM, Li Kun <hw.likun@huawei.com> wrote: > Is there any plan to port the RAP feature from PAX/Grsecurity to main line ? > I think that will be a realy effective approach to protect against ROP/JOP. Yeah, RAP is pretty great! I'm not aware of anyone working on upstreaming the plugin (and its many function declaration fixes and other adjustments) currently, though. I've also been interested to see if kCFI[1] will be published soon, which would be another option (it needs fewer kernel changes, but has limitations like needing to build the kernel twice). While the code isn't released yet, they did provide a comparison[2] to RAP which is an interesting read. -Kees [1] https://github.com/kcfi/docs [2] https://github.com/kcfi/docs/blob/master/kcfi_vs_rap.txt -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [kernel-hardening][RFD] Is there any plan to port the RAP feature from PAX/Grsecurity to main line ? 2017-08-04 5:13 ` Kees Cook @ 2017-08-04 10:31 ` Li Kun 2017-08-05 0:30 ` Joao Moreira 0 siblings, 1 reply; 6+ messages in thread From: Li Kun @ 2017-08-04 10:31 UTC (permalink / raw) To: Kees Cook; +Cc: kernel-hardening 在 2017/8/4 13:13, Kees Cook 写道: > On Thu, Aug 3, 2017 at 9:23 PM, Li Kun <hw.likun@huawei.com> wrote: >> Is there any plan to port the RAP feature from PAX/Grsecurity to main line ? >> I think that will be a realy effective approach to protect against ROP/JOP. > Yeah, RAP is pretty great! I'm not aware of anyone working on > upstreaming the plugin (and its many function declaration fixes and > other adjustments) currently, though. I will try to upstream it. If i have any progress or trouble, i will show it here:) > > I've also been interested to see if kCFI[1] will be published soon, > which would be another option (it needs fewer kernel changes, but has > limitations like needing to build the kernel twice). While the code > isn't released yet, they did provide a comparison[2] to RAP which is > an interesting read. That looks awsome. Does it have any schedule to release the code? > > -Kees > > [1] https://github.com/kcfi/docs > [2] https://github.com/kcfi/docs/blob/master/kcfi_vs_rap.txt > -- Best Regards Li Kun ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [kernel-hardening][RFD] Is there any plan to port the RAP feature from PAX/Grsecurity to main line ? 2017-08-04 10:31 ` Li Kun @ 2017-08-05 0:30 ` Joao Moreira 2017-08-10 0:06 ` Kees Cook 0 siblings, 1 reply; 6+ messages in thread From: Joao Moreira @ 2017-08-05 0:30 UTC (permalink / raw) To: Li Kun, Kees Cook; +Cc: kernel-hardening hi, I'm Joao, I talk for kCFI :) On 08/04/2017 07:31 AM, Li Kun wrote: > > > 在 2017/8/4 13:13, Kees Cook 写道: >> On Thu, Aug 3, 2017 at 9:23 PM, Li Kun <hw.likun@huawei.com> wrote: >>> Is there any plan to port the RAP feature from PAX/Grsecurity to main >>> line ? >>> I think that will be a realy effective approach to protect against >>> ROP/JOP. >> Yeah, RAP is pretty great! I'm not aware of anyone working on >> upstreaming the plugin (and its many function declaration fixes and >> other adjustments) currently, though. > I will try to upstream it. > If i have any progress or trouble, i will show it here:) >> >> I've also been interested to see if kCFI[1] will be published soon, >> which would be another option (it needs fewer kernel changes, but has >> limitations like needing to build the kernel twice). While the code >> isn't released yet, they did provide a comparison[2] to RAP which is >> an interesting read. So, we wanted to have it released some time ago, but life happened and unfortunately, I had to share my time between this and other projects. As you are speaking of "upstreamability", I see kCFI as an interesting start-point, but it is blurry to believe that it would be mergeable into the kernel. kCFI was/is a research project, willing to enable CFI experimentation in the kernel space. It never was understood as a product. Because of that, we took many decisions in the past that would benefit this aspect of the work, instead of making it super maintainable or attachable. Some of these decisions were: 1st, kCFI is implemented on top of LLVM; 2nd, some of the most interesting features of kCFI require two compilation rounds (and we didn't even care about it, because we were just trying to prove a point in making achievable kernel CFI more fine-grained); 3rd, we never ported it to newer kernel versions, instead we preferred to evaluate different approaches and solutions in that very same code-base (Linux kernel 3.19); 4th, kCFI requires many external tools (which perform binary analyses, CFG fixes, etc). Just to illustrate why we took these paths think about, for example, not tagging all functions uniquely based on their prototype. I mean, if you have a function FOO and a function BAR, both with the same prototype, but such prototype never appears in a pointer declaration throughout source code, why do you need them having the same tags? This would allow FOO returning to a BAR's call-site, and BAR returning to a FOO's call-site. Yet, to know that such function pointer does not exist, we had to run a full compilation round before instrumenting, performing a source-code analysis. Given all the above I would say that someone interested in making CFI upstream, should not get demotivated by kCFI. > That looks awsome. Does it have any schedule to release the code? No, we don't have a release schedule. Our current plans are to finish some final tests that we are doing, run some more benchmarks/use-cases so we can extend a bit our false-positive coverage, and then have it out as soon as possible... but well, tbh, it may take some time. If someone wants to make CFI “upstreamable”, I'm in for helping in any way I can. I would suggest that anyone willing to achieve it should first try to implement a coarse-grained scheme, have it booting and running, and only after that, think about the best way of organizing the tags so you minimize/cease the false-positives. If there is anything I can do, I’m lvwr in ##kernel-hardened or, just reach me through mail. Tks, Joao >> >> -Kees >> >> [1] https://github.com/kcfi/docs >> [2] https://github.com/kcfi/docs/blob/master/kcfi_vs_rap.txt >> > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [kernel-hardening][RFD] Is there any plan to port the RAP feature from PAX/Grsecurity to main line ? 2017-08-05 0:30 ` Joao Moreira @ 2017-08-10 0:06 ` Kees Cook 2017-08-14 17:44 ` Joao Moreira 0 siblings, 1 reply; 6+ messages in thread From: Kees Cook @ 2017-08-10 0:06 UTC (permalink / raw) To: Joao Moreira; +Cc: Li Kun, kernel-hardening On Fri, Aug 4, 2017 at 5:30 PM, Joao Moreira <jmoreira@suse.de> wrote: > hi, I'm Joao, I talk for kCFI :) Hi! Thanks for the reply! > > On 08/04/2017 07:31 AM, Li Kun wrote: >> >> >> >> 在 2017/8/4 13:13, Kees Cook 写道: >>> >>> On Thu, Aug 3, 2017 at 9:23 PM, Li Kun <hw.likun@huawei.com> wrote: >>>> >>>> Is there any plan to port the RAP feature from PAX/Grsecurity to main >>>> line ? >>>> I think that will be a realy effective approach to protect against >>>> ROP/JOP. >>> >>> Yeah, RAP is pretty great! I'm not aware of anyone working on >>> upstreaming the plugin (and its many function declaration fixes and >>> other adjustments) currently, though. >> >> I will try to upstream it. >> If i have any progress or trouble, i will show it here:) >>> >>> >>> I've also been interested to see if kCFI[1] will be published soon, >>> which would be another option (it needs fewer kernel changes, but has >>> limitations like needing to build the kernel twice). While the code >>> isn't released yet, they did provide a comparison[2] to RAP which is >>> an interesting read. > > > So, we wanted to have it released some time ago, but life happened and > unfortunately, I had to share my time between this and other projects. Is there anything specifically stopping release? Even getting something that is just "works only kernel version X.Y" would be excellent to have for people to examine. > As you are speaking of "upstreamability", I see kCFI as an interesting > start-point, but it is blurry to believe that it would be mergeable into the > kernel. kCFI was/is a research project, willing to enable CFI > experimentation in the kernel space. It never was understood as a product. > Because of that, we took many decisions in the past that would benefit this > aspect of the work, instead of making it super maintainable or attachable. > Some of these decisions were: 1st, kCFI is implemented on top of LLVM; 2nd, > some of the most interesting features of kCFI require two compilation rounds > (and we didn't even care about it, because we were just trying to prove a > point in making achievable kernel CFI more fine-grained); 3rd, we never > ported it to newer kernel versions, instead we preferred to evaluate > different approaches and solutions in that very same code-base (Linux kernel > 3.19); 4th, kCFI requires many external tools (which perform binary > analyses, CFG fixes, etc). That's fine -- I never expect large changes to the kernel to land in one giant splash. Getting things into upstream in pieces tends to be much saner. Having something to work from means people can help chip away at the final goal. > Just to illustrate why we took these paths think about, for example, not > tagging all functions uniquely based on their prototype. I mean, if you have > a function FOO and a function BAR, both with the same prototype, but such > prototype never appears in a pointer declaration throughout source code, why > do you need them having the same tags? This would allow FOO returning to a > BAR's call-site, and BAR returning to a FOO's call-site. Yet, to know that > such function pointer does not exist, we had to run a full compilation round > before instrumenting, performing a source-code analysis. Yup, exactly. I like this feature. What's the right term for this? "Cluster splitting"? > Given all the above I would say that someone interested in making CFI > upstream, should not get demotivated by kCFI. > >> That looks awsome. Does it have any schedule to release the code? > > > No, we don't have a release schedule. Our current plans are to finish some > final tests that we are doing, run some more benchmarks/use-cases so we can > extend a bit our false-positive coverage, and then have it out as soon as > possible... but well, tbh, it may take some time. > > If someone wants to make CFI “upstreamable”, I'm in for helping in any way I > can. I would suggest that anyone willing to achieve it should first try to > implement a coarse-grained scheme, have it booting and running, and only > after that, think about the best way of organizing the tags so you > minimize/cease the false-positives. I'd love to not have to have people start from scratch (hint hint). :) > If there is anything I can do, I’m lvwr in ##kernel-hardened or, just reach > me through mail. (For anyone following the thread, Joao pointed out to me on IRC that the above was a typo. This should be ##linux-hardened on freenode.) Thanks! -Kees -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [kernel-hardening][RFD] Is there any plan to port the RAP feature from PAX/Grsecurity to main line ? 2017-08-10 0:06 ` Kees Cook @ 2017-08-14 17:44 ` Joao Moreira 0 siblings, 0 replies; 6+ messages in thread From: Joao Moreira @ 2017-08-14 17:44 UTC (permalink / raw) To: Kees Cook; +Cc: Li Kun, kernel-hardening On 08/09/2017 09:06 PM, Kees Cook wrote: > On Fri, Aug 4, 2017 at 5:30 PM, Joao Moreira <jmoreira@suse.de> wrote: >> hi, I'm Joao, I talk for kCFI :) > > Hi! Thanks for the reply! > >> >> On 08/04/2017 07:31 AM, Li Kun wrote: >>> >>> >>> >>> 在 2017/8/4 13:13, Kees Cook 写道: >>>> >>>> On Thu, Aug 3, 2017 at 9:23 PM, Li Kun <hw.likun@huawei.com> wrote: >>>>> >>>>> Is there any plan to port the RAP feature from PAX/Grsecurity to main >>>>> line ? >>>>> I think that will be a realy effective approach to protect against >>>>> ROP/JOP. >>>> >>>> Yeah, RAP is pretty great! I'm not aware of anyone working on >>>> upstreaming the plugin (and its many function declaration fixes and >>>> other adjustments) currently, though. >>> >>> I will try to upstream it. >>> If i have any progress or trouble, i will show it here:) >>>> >>>> >>>> I've also been interested to see if kCFI[1] will be published soon, >>>> which would be another option (it needs fewer kernel changes, but has >>>> limitations like needing to build the kernel twice). While the code >>>> isn't released yet, they did provide a comparison[2] to RAP which is >>>> an interesting read. >> >> >> So, we wanted to have it released some time ago, but life happened and >> unfortunately, I had to share my time between this and other projects. > > Is there anything specifically stopping release? Even getting > something that is just "works only kernel version X.Y" would be > excellent to have for people to examine. > We mostly search for false-positives dynamically. So we started running some different workloads and we spotted some more cases of unmatching prototypes (kCFI is a showed to be a great tool for dynamically hunting these cases, so it might be useful in this sense too). While the false-positives aren't that much complicated to fix, I'm currently in the middle of many different work threads, so I have to find time every now and then to work on these, and pack everything as a proper release. >> As you are speaking of "upstreamability", I see kCFI as an interesting >> start-point, but it is blurry to believe that it would be mergeable into the >> kernel. kCFI was/is a research project, willing to enable CFI >> experimentation in the kernel space. It never was understood as a product. >> Because of that, we took many decisions in the past that would benefit this >> aspect of the work, instead of making it super maintainable or attachable. >> Some of these decisions were: 1st, kCFI is implemented on top of LLVM; 2nd, >> some of the most interesting features of kCFI require two compilation rounds >> (and we didn't even care about it, because we were just trying to prove a >> point in making achievable kernel CFI more fine-grained); 3rd, we never >> ported it to newer kernel versions, instead we preferred to evaluate >> different approaches and solutions in that very same code-base (Linux kernel >> 3.19); 4th, kCFI requires many external tools (which perform binary >> analyses, CFG fixes, etc). > > That's fine -- I never expect large changes to the kernel to land in > one giant splash. Getting things into upstream in pieces tends to be > much saner. Having something to work from means people can help chip > away at the final goal. > >> Just to illustrate why we took these paths think about, for example, not >> tagging all functions uniquely based on their prototype. I mean, if you have >> a function FOO and a function BAR, both with the same prototype, but such >> prototype never appears in a pointer declaration throughout source code, why >> do you need them having the same tags? This would allow FOO returning to a >> BAR's call-site, and BAR returning to a FOO's call-site. Yet, to know that >> such function pointer does not exist, we had to run a full compilation round >> before instrumenting, performing a source-code analysis. > > Yup, exactly. I like this feature. What's the right term for this? > "Cluster splitting"? That one fits :) > >> Given all the above I would say that someone interested in making CFI >> upstream, should not get demotivated by kCFI. >> >>> That looks awsome. Does it have any schedule to release the code? >> >> >> No, we don't have a release schedule. Our current plans are to finish some >> final tests that we are doing, run some more benchmarks/use-cases so we can >> extend a bit our false-positive coverage, and then have it out as soon as >> possible... but well, tbh, it may take some time. >> >> If someone wants to make CFI “upstreamable”, I'm in for helping in any way I >> can. I would suggest that anyone willing to achieve it should first try to >> implement a coarse-grained scheme, have it booting and running, and only >> after that, think about the best way of organizing the tags so you >> minimize/cease the false-positives. > > I'd love to not have to have people start from scratch (hint hint). :) > I'll try to finish whatever is open in my todo list and have it released in the following weeks. Then, hopefully, we can keep up the pass with some community assistance. >> If there is anything I can do, I’m lvwr in ##kernel-hardened or, just reach >> me through mail. > > (For anyone following the thread, Joao pointed out to me on IRC that > the above was a typo. This should be ##linux-hardened on freenode.) > Indeed. ##linux-hardened. Sorry for the typo. Tks, Joao. > Thanks! > > -Kees > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-08-14 17:44 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-04 4:23 [kernel-hardening][RFD] Is there any plan to port the RAP feature from PAX/Grsecurity to main line ? Li Kun 2017-08-04 5:13 ` Kees Cook 2017-08-04 10:31 ` Li Kun 2017-08-05 0:30 ` Joao Moreira 2017-08-10 0:06 ` Kees Cook 2017-08-14 17:44 ` Joao Moreira
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.