I want to help out
Hello everybody,
I'm new in the mailing list.
I've been working on kernel hardening activities during the last three months https://github.com/GustavoARSilva/linux-hardening/blob/master/cii/2017/reports/mayjunjul_detailed
I'd be more than happy to dedicate time and help out with any coding activities you may need help with. In particular related to x86 and ARM architectures (that's the hardware I have at hand).
Thank you
Signature · 2 lines
Gustavo A. R. Silva @embeddedgus
Hey Gustavo, welcome!
That's a lot of changes, thanks for sharing.
You can take a look at this page [1] to get an idea on things to do. You can also look at the difference patches coming and going on the mailing list to see if anything interest you.
Anything in particular you wanted to prototype?
Thanks,
[1] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Work
Quoted 16 lines · Gustavo A. R. Silva
Hello everybody,
I'm new in the mailing list.
I've been working on kernel hardening activities during the last three months
https://github.com/GustavoARSilva/linux-hardening/blob/master/cii/2017/reports/mayjunjul_detailedI'd be more than happy to dedicate time and help out with any coding activities you may need help with. In particular related to x86 and ARM architectures (that's the hardware I have at hand).
Thank you
--
Gustavo A. R. Silva
@embeddedgus
Signature · 1 line
Thomas
Hi Thomas,
Quoted 2 lines · Thomas Garnier
Hey Gustavo, welcome!
Thanks!
Quoted 2 lines
That's a lot of changes, thanks for sharing.
I'm glad to help. :)
Quoted 6 lines
You can take a look at this page [1] to get an idea on things to do. You can also look at the difference patches coming and going on the mailing list to see if anything interest you.
Anything in particular you wanted to prototype?
I'm interested in mitigation efforts towards control flow infection, as function pointer poisoning for both .init_array (I know there is some ongoing work here) and .fini_array.
From the TODO list I think the following tasks are interesting:
* Split thread_info off of kernel stack.
* Move kernel stack to vmap area.
* Implement kernel relocation and KASLR for ARM
If there is already some work in progress and there are some small tasks pending to be completed, I'd like to help.
I might need someone to point me out to the work already in place and, after reading some code and asking some questions I might be able to take it from there.
I have to say that by no means I'm an expert in any of those areas, but I'm willing to learn and become a long term contributor.
Recently, I've been using Coccinelle to constify structures, and fixing a variety of Coverity issues (API usage errors, NULL pointer dereferences, control flow and code maintainability issues, etc..). I'm also using Coccinelle to identify lock/unlock issues.
Thank you!
Signature · 1 line
Gustavo A. R. Silva
Quoted 25 lines
Thanks,
[1] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Work
Quoted 16 lines · Gustavo A. R. Silva
Hello everybody,
I'm new in the mailing list.
I've been working on kernel hardening activities during the last three months
https://github.com/GustavoARSilva/linux-hardening/blob/master/cii/2017/reports/mayjunjul_detailedI'd be more than happy to dedicate time and help out with any coding activities you may need help with. In particular related to x86 and ARM architectures (that's the hardware I have at hand).
Thank you
--
Gustavo A. R. Silva
@embeddedgus
Welcome to the list!
Quoted 11 lines · Gustavo A. R. Silva
Quoted 6 lines · Thomas Garnier
You can take a look at this page [1] to get an idea on things to do. You can also look at the difference patches coming and going on the mailing list to see if anything interest you.
Anything in particular you wanted to prototype?
I'm interested in mitigation efforts towards control flow infection, as function pointer poisoning for both .init_array (I know there is some ongoing work here) and .fini_array.
I'd be curious to hear more about this work.
Quoted 5 lines
From the TODO list I think the following tasks are interesting:
* Split
thread_infooff of kernel stack.
* Move kernel stack to vmap area.
* Implement kernel relocation and KASLR for ARM
All three of these are needed on 32-bit arm. The last is a tricky one, since kernel relocation is needed before KASLR can happen on ARM.
Quoted 2 lines
If there is already some work in progress and there are some small tasks pending to be completed, I'd like to help.
More testing on arm64 VMAP_STACK would be great, if you have hardware available.
Quoted 4 lines
Recently, I've been using Coccinelle to constify structures, and fixing a variety of Coverity issues (API usage errors, NULL pointer dereferences, control flow and code maintainability issues, etc..). I'm also using Coccinelle to identify lock/unlock issues.
This is good work to be getting done too!
-Kees
Signature · 2 lines
Kees Cook Pixel Security
Quoted 2 lines · Kees Cook
Welcome to the list!
Thank you, Kees. :)
Quoted 7 lines
Quoted 5 lines · Gustavo A. R. Silva
Quoted 4 lines · Thomas Garnier
You can take a look at this page [1] to get an idea on things to do. You can also look at the difference patches coming and going on the mailing list to see if anything interest you.
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
Anything in particular you wanted to prototype?
I'm interested in mitigation efforts towards control flow infection, as function pointer poisoning for both .init_array (I know there is some ongoing work here) and .fini_array.
I'd be curious to hear more about this work.
Yeah, this has to do with the use __ro_after_init for the case of .ctors (.init_array) ELF section.
The case of .dtors or .fini_array ELF section is similar. A heap overflow could overwrite a .fini_array function pointer. But I guess this could be detected by guard pages.
Quoted 9 lines
Quoted 5 lines
From the TODO list I think the following tasks are interesting:
* Split
thread_infooff of kernel stack.
* Move kernel stack to vmap area.
* Implement kernel relocation and KASLR for ARMAll three of these are needed on 32-bit arm. The last is a tricky one, since kernel relocation is needed before KASLR can happen on ARM.
After reading this https://lwn.net/Articles/692208/ those first two tasks seem to be very challenging and even more interesting.
So, I guess the idea would be to follow this same approach:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e37e43a497d5a8b7c0cc1736d56986f432c394c9
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13d4ea097d18b419ad2a2b696063d44bf59acec0
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c65eacbe290b8141554c71b2c94489e73ade8c8d
right?
Is this already working for arm64?
What would be a good strategy to start tackling those tasks?
Quoted 5 lines
Quoted 2 lines
If there is already some work in progress and there are some small tasks pending to be completed, I'd like to help.
More testing on arm64
VMAP_STACKwould be great, if you have hardware available.
Oh, I guess this answer one of my questions above...
I'm sorry. I have a Beagle Bone Black, which is 32-bit.
Quoted 7 lines
Quoted 4 lines
Recently, I've been using Coccinelle to constify structures, and fixing a variety of Coverity issues (API usage errors, NULL pointer dereferences, control flow and code maintainability issues, etc..). I'm also using Coccinelle to identify lock/unlock issues.
This is good work to be getting done too!
Yeah, I've been doing this over the last three months and, the plan is to continue fixing similar issues for a whole year. :)
Thanks
Signature · 1 line
Gustavo A. R. Silva
Quoted 6 lines · Gustavo A. R. Silva
Yeah, this has to do with the use
__ro_after_initfor the case of .ctors (.init_array) ELF section.The case of .dtors or .fini_array ELF section is similar. A heap overflow could overwrite a .fini_array function pointer. But I guess this could be detected by guard pages.
Oh, hm, I would have expected all of those to be entirely read-only already. How does the kernel use those dynamically?
Quoted 7 lines
So, I guess the idea would be to follow this same approach:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e37e43a497d5a8b7c0cc1736d56986f432c394c9
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13d4ea097d18b419ad2a2b696063d44bf59acec0
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c65eacbe290b8141554c71b2c94489e73ade8c8dright?
As far as I know, yes.
Quoted 1 line
What would be a good strategy to start tackling those tasks?
I suspect the arm64 folks here may have suggestions about how to do either on arm. I would expect moving addr_limit off the stack to mainly be moving the structure and dealing with the header fallout and syscall entry/exit assembly. For VMAP_STACK, I think there is a lot of other work to handle faults correctly.
-Kees
Signature · 2 lines
Kees Cook Pixel Security