* [kernel-hardening] self introduction @ 2016-10-09 12:34 Colin Vidal 2016-10-09 14:04 ` David Windsor 2016-10-10 20:57 ` Kees Cook 0 siblings, 2 replies; 54+ messages in thread From: Colin Vidal @ 2016-10-09 12:34 UTC (permalink / raw) To: kernel-hardening Hi all, My name is Colin Vidal. I am currently a PhD student in computer science. My researches consist on building a dedicated specific language on top of JavaScript in order to handle asynchronous events in a synchronous style. Hence, with a direct relation between the control flow and the instruction flow. Beside my researches, I am taking up the Eudyptula Challenge (task 15 submitted). It helps me to have a global view of the kernel (organization, tree, some features), but it is not enough to get involved in serious development. Therefore, I am looking for task I can accomplish to be involved into real kernel development! I still don't have yet a narrow idea about where I can begin. I like though the idea of kernel self protection. For instance, I find the VM- mapped stack to be really interesting, but I think it is an overkill as a beginning, and a lot of work have already been done on it. On the architecture point-of-view, I have a preference of x86 since I only have this hardware for now, but I can work on ARM and others with QEMU too. Thanks, Colin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-09 12:34 [kernel-hardening] self introduction Colin Vidal @ 2016-10-09 14:04 ` David Windsor 2016-10-09 19:09 ` Colin Vidal 2016-10-10 20:57 ` Kees Cook 1 sibling, 1 reply; 54+ messages in thread From: David Windsor @ 2016-10-09 14:04 UTC (permalink / raw) To: kernel-hardening Hi Colin, If you're interested, the HARDENED_ATOMIC team is looking for people to help porting the feature to other architectures. ARM is a reasonable candidate for someone new to the project. I have begun this effort myself, but if you'd like to collaborate I'd be grateful. It essentially involves porting the original arch-specific features from PAX_REFCOUNT into Elena Reshetova's official HARDENED_ATOMIC tree, which can be found at https://github.com/esreshetova/linux-stable Please contact me if you have any questions; I'd be glad to help! Thanks, David > On Oct 9, 2016, at 8:34 AM, Colin Vidal <colin@cvidal.org> wrote: > > Hi all, > > My name is Colin Vidal. I am currently a PhD student in computer > science. My researches consist on building a dedicated specific > language on top of JavaScript in order to handle asynchronous events in > a synchronous style. Hence, with a direct relation between the control > flow and the instruction flow. > > Beside my researches, I am taking up the Eudyptula Challenge (task 15 > submitted). It helps me to have a global view of the kernel > (organization, tree, some features), but it is not enough to get > involved in serious development. Therefore, I am looking for task I can > accomplish to be involved into real kernel development! > > I still don't have yet a narrow idea about where I can begin. I like > though the idea of kernel self protection. For instance, I find the VM- > mapped stack to be really interesting, but I think it is an overkill as > a beginning, and a lot of work have already been done on it. On the > architecture point-of-view, I have a preference of x86 since I only > have this hardware for now, but I can work on ARM and others with QEMU > too. > > Thanks, > > Colin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-09 14:04 ` David Windsor @ 2016-10-09 19:09 ` Colin Vidal 2016-10-09 19:37 ` Jann Horn 0 siblings, 1 reply; 54+ messages in thread From: Colin Vidal @ 2016-10-09 19:09 UTC (permalink / raw) To: kernel-hardening Hi David, > If you're interested, the HARDENED_ATOMIC team is looking for people > to help porting the feature to other architectures. ARM is a > reasonable candidate for someone new to the project. I have begun > this effort myself, but if you'd like to collaborate I'd be > grateful. Sounds good! > It essentially involves porting the original arch-specific features > from PAX_REFCOUNT into Elena Reshetova's official HARDENED_ATOMIC > tree, which can be found at > https://github.com/esreshetova/linux-stable The link seems broken (https://github.com/esreshetova too). I found https://github.com/dwindsor/hardened-atomic but it is empty. Did I miss something/Github filter? > Please contact me if you have any questions; I'd be glad to help! I actually have question. :-) As far as I understand, PAX_REFCOUNT [1] is mainly a x86-only port from PaX project in order to avoid overflow on atomic_t variable (and avoid use-after-free exploits). I am a little bit confused about the Elena patch-set HARDENED_ATOMIC [2]. It is a more mature/recent version of the port, isn't it ? Thanks! Colin [1] https://lwn.net/Articles/668724/ [2] https://lwn.net/Articles/702640/ ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-09 19:09 ` Colin Vidal @ 2016-10-09 19:37 ` Jann Horn 2016-10-10 6:02 ` Reshetova, Elena 0 siblings, 1 reply; 54+ messages in thread From: Jann Horn @ 2016-10-09 19:37 UTC (permalink / raw) To: Colin Vidal; +Cc: kernel-hardening [-- Attachment #1: Type: text/plain, Size: 1675 bytes --] On Sun, Oct 09, 2016 at 09:09:42PM +0200, Colin Vidal wrote: > Hi David, > > > If you're interested, the HARDENED_ATOMIC team is looking for people > > to help porting the feature to other architectures. ARM is a > > reasonable candidate for someone new to the project. I have begun > > this effort myself, but if you'd like to collaborate I'd be > > grateful. > > Sounds good! > > > It essentially involves porting the original arch-specific features > > from PAX_REFCOUNT into Elena Reshetova's official HARDENED_ATOMIC > > tree, which can be found at > > https://github.com/esreshetova/linux-stable > > The link seems broken (https://github.com/esreshetova too). I found > https://github.com/dwindsor/hardened-atomic but it is empty. Did I > miss something/Github filter? Typo in the link, I think? https://github.com/ereshetova/linux-stable > > Please contact me if you have any questions; I'd be glad to help! > > I actually have question. :-) As far as I understand, PAX_REFCOUNT [1] > is mainly a x86-only No, PAX_REFCOUNT also supports a bunch of other architectures. As far as I can tell from a quick look: ARM, MIPS, PowerPC and SPARC. > port from PaX project It is part of the PaX patch. > in order to avoid overflow > on atomic_t variable (and avoid use-after-free exploits) Yes - overflow (beyond INT_MAX) and underflow (beyond INT_MIN). . I am a > little bit confused about the Elena patch-set HARDENED_ATOMIC [2]. It > is a more mature/recent version of the port, isn't it ? HARDENED_ATOMIC is a patch based on PAX_REFCOUNT that is developed with the intent to merge it into the upstream kernel. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: [kernel-hardening] self introduction 2016-10-09 19:37 ` Jann Horn @ 2016-10-10 6:02 ` Reshetova, Elena 2016-10-10 16:01 ` Colin Vidal 2016-10-13 18:53 ` Kees Cook 0 siblings, 2 replies; 54+ messages in thread From: Reshetova, Elena @ 2016-10-10 6:02 UTC (permalink / raw) To: kernel-hardening, Colin Vidal On Sun, Oct 09, 2016 at 09:09:42PM +0200, Colin Vidal wrote: > Hi David, > > > If you're interested, the HARDENED_ATOMIC team is looking for people > > to help porting the feature to other architectures. ARM is a > > reasonable candidate for someone new to the project. I have begun > > this effort myself, but if you'd like to collaborate I'd be > > grateful. > > Sounds good! > > > It essentially involves porting the original arch-specific features > > from PAX_REFCOUNT into Elena Reshetova's official HARDENED_ATOMIC > > tree, which can be found at > > https://github.com/esreshetova/linux-stable > > The link seems broken (https://github.com/esreshetova too). I found > https://github.com/dwindsor/hardened-atomic but it is empty. Did I > miss something/Github filter? >Typo in the link, I think? >https://github.com/ereshetova/linux-stable This branch to be precise: https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next This is where the latest code for linux-next is hosted now and where we work with David and Hans. > > Please contact me if you have any questions; I'd be glad to help! > > I actually have question. :-) As far as I understand, PAX_REFCOUNT [1] > is mainly a x86-only >No, PAX_REFCOUNT also supports a bunch of other architectures. As far as I can tell from a quick look: ARM, MIPS, PowerPC and SPARC. Yes, just in our patch series we only made implementation for x86. But if you look into Grsecurity/PaX patches, it has support for others implemented. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-10 6:02 ` Reshetova, Elena @ 2016-10-10 16:01 ` Colin Vidal 2016-10-10 17:01 ` Reshetova, Elena 2016-10-10 21:05 ` Kees Cook 2016-10-13 18:53 ` Kees Cook 1 sibling, 2 replies; 54+ messages in thread From: Colin Vidal @ 2016-10-10 16:01 UTC (permalink / raw) To: kernel-hardening; +Cc: Reshetova, Elena > This branch to be precise: > https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next > > This is where the latest code for linux-next is hosted now and where > we work with David and Hans. > > > > > > > > Please contact me if you have any questions; I'd be glad to help! > > > > I actually have question. :-) As far as I understand, PAX_REFCOUNT > > [1] is mainly a x86-only > > > > > No, PAX_REFCOUNT also supports a bunch of other architectures. As > > far as I can tell from a quick look: ARM, MIPS, PowerPC and SPARC. > > Yes, just in our patch series we only made implementation for x86. > But if you look into Grsecurity/PaX patches, it has support for > others implemented. OK, got it! Thanks for this clarification. So, I will try to start to port PAX_REFCOUNT arm-specific features to hardened_atomic_on_next, and keep you in touch. Is there a deadline? (4.10 / 5.0 merge window?) Just to be sure, the patch [1] and documentation [2] of PaX are still up-to-date, or there is another references I missed? Thanks Colin [1] https://pax.grsecurity.net/pax-linux-3.6-201210022100.patch [2] https://forums.grsecurity.net/viewtopic.php?f=7&t=4173 ^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: [kernel-hardening] self introduction 2016-10-10 16:01 ` Colin Vidal @ 2016-10-10 17:01 ` Reshetova, Elena 2016-10-10 21:05 ` Kees Cook 1 sibling, 0 replies; 54+ messages in thread From: Reshetova, Elena @ 2016-10-10 17:01 UTC (permalink / raw) To: Colin Vidal, kernel-hardening > Yes, just in our patch series we only made implementation for x86. > But if you look into Grsecurity/PaX patches, it has support for others > implemented. >OK, got it! Thanks for this clarification. >So, I will try to start to port PAX_REFCOUNT arm-specific features to hardened_atomic_on_next, and keep you in touch. Is there a deadline? >(4.10 / 5.0 merge window?) I don't think we have any particular deadline in mind: getting it in the upstream and making it behaving correctly is more of a priority. >Just to be sure, the patch [1] and documentation [2] of PaX are still up-to-date, or there is another references I missed? I don't think there are any other significant references. Where we functionaly deviate from PaX/Grsecurity, we documented it in commit messages (so far only on percpu refcount thing) . Best Regards, Elena. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-10 16:01 ` Colin Vidal 2016-10-10 17:01 ` Reshetova, Elena @ 2016-10-10 21:05 ` Kees Cook 2016-10-12 3:19 ` Gengjia Chen 2016-10-12 8:25 ` Colin Vidal 1 sibling, 2 replies; 54+ messages in thread From: Kees Cook @ 2016-10-10 21:05 UTC (permalink / raw) To: kernel-hardening, AKASHI Takahiro; +Cc: Reshetova, Elena On Mon, Oct 10, 2016 at 9:01 AM, Colin Vidal <colin@cvidal.org> wrote: >> This branch to be precise: >> https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next >> >> This is where the latest code for linux-next is hosted now and where >> we work with David and Hans. >> > >> > > >> > > Please contact me if you have any questions; I'd be glad to help! >> > >> > I actually have question. :-) As far as I understand, PAX_REFCOUNT >> > [1] is mainly a x86-only >> >> > >> > No, PAX_REFCOUNT also supports a bunch of other architectures. As >> > far as I can tell from a quick look: ARM, MIPS, PowerPC and SPARC. >> >> Yes, just in our patch series we only made implementation for x86. >> But if you look into Grsecurity/PaX patches, it has support for >> others implemented. > > OK, got it! Thanks for this clarification. > > So, I will try to start to port PAX_REFCOUNT arm-specific features to > hardened_atomic_on_next, and keep you in touch. Is there a deadline? > (4.10 / 5.0 merge window?) You may want to compare notes with Takahiro (CCed) who may have started to look at arm64 (and maybe arm too). As for a deadline, as Elena says, we have no specific target. ("As soon as possible.") The only thing around timing that I like to see is persistent progress: if a patch series goes up for review, getting people to take a look at it, ask questions, make comments, and then hopefully within a week or so, the next version comes up. Momentum is easier to maintain than to build. ;) > Just to be sure, the patch [1] and documentation [2] of PaX are still > up-to-date, or there is another references I missed? > > Thanks > > Colin > > [1] https://pax.grsecurity.net/pax-linux-3.6-201210022100.patch This is a quite old version of PaX. (Note the date.) If you want to examine PaX separately from Grsecurity (noting differences can be enlightening), check here: https://www.grsecurity.net/~paxguy1/?C=M;O=D > [2] https://forums.grsecurity.net/viewtopic.php?f=7&t=4173 Yes, outside of reading the code itself, I believe this to be the most comprehensive piece of documentation about PAX_REFCOUNT. -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-10 21:05 ` Kees Cook @ 2016-10-12 3:19 ` Gengjia Chen 2016-10-12 22:31 ` Kees Cook 2016-10-12 8:25 ` Colin Vidal 1 sibling, 1 reply; 54+ messages in thread From: Gengjia Chen @ 2016-10-12 3:19 UTC (permalink / raw) To: kernel-hardening [-- Attachment #1: Type: text/plain, Size: 3507 bytes --] Hi all, My name is Jiayy (@chengjia4574 <https://twitter.com/chengjia4574>). I am currently a security researcher in android and linux kernel. My researches consist on hunting vulnerabilities in kernel code (most of them within drivers) and doing exploits using those vulns. I had found more than 40 vulnerabilities <http://www.linkedin.com/in/chen-gengjia-a4411855?trk=nav_responsive_tab_profile> which were confirmed by Android Security Team in the past year. I also figured out some way to attack mitigation solutions of kernel (such as Bypass PXN <http://en.mosec.org/#speech_bg>). Those works help me get familiar with the kernel(device tree, memory management, network , some features especially those associated with security such as pxn, selinux, seccomp) and ARM instruction. However, it is not enough to get involved in real security development in kernel. Therefore, I am looking for task I can accomplish to be involved into real kernel development! Recently I found this project (kernel self protection) and I thought it is so interesting. I don't know whether I can involve and where I can begin, I am looking forward to your response. Thanks, Jiayy 2016-10-11 5:05 GMT+08:00 Kees Cook <keescook@chromium.org>: > On Mon, Oct 10, 2016 at 9:01 AM, Colin Vidal <colin@cvidal.org> wrote: > >> This branch to be precise: > >> https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next > >> > >> This is where the latest code for linux-next is hosted now and where > >> we work with David and Hans. > >> > > >> > > > >> > > Please contact me if you have any questions; I'd be glad to help! > >> > > >> > I actually have question. :-) As far as I understand, PAX_REFCOUNT > >> > [1] is mainly a x86-only > >> > >> > > >> > No, PAX_REFCOUNT also supports a bunch of other architectures. As > >> > far as I can tell from a quick look: ARM, MIPS, PowerPC and SPARC. > >> > >> Yes, just in our patch series we only made implementation for x86. > >> But if you look into Grsecurity/PaX patches, it has support for > >> others implemented. > > > > OK, got it! Thanks for this clarification. > > > > So, I will try to start to port PAX_REFCOUNT arm-specific features to > > hardened_atomic_on_next, and keep you in touch. Is there a deadline? > > (4.10 / 5.0 merge window?) > > You may want to compare notes with Takahiro (CCed) who may have > started to look at arm64 (and maybe arm too). > > As for a deadline, as Elena says, we have no specific target. ("As > soon as possible.") The only thing around timing that I like to see is > persistent progress: if a patch series goes up for review, getting > people to take a look at it, ask questions, make comments, and then > hopefully within a week or so, the next version comes up. Momentum is > easier to maintain than to build. ;) > > > Just to be sure, the patch [1] and documentation [2] of PaX are still > > up-to-date, or there is another references I missed? > > > > Thanks > > > > Colin > > > > [1] https://pax.grsecurity.net/pax-linux-3.6-201210022100.patch > > This is a quite old version of PaX. (Note the date.) If you want to > examine PaX separately from Grsecurity (noting differences can be > enlightening), check here: > > https://www.grsecurity.net/~paxguy1/?C=M;O=D > > > [2] https://forums.grsecurity.net/viewtopic.php?f=7&t=4173 > > Yes, outside of reading the code itself, I believe this to be the most > comprehensive piece of documentation about PAX_REFCOUNT. > > -Kees > > -- > Kees Cook > Nexus Security > [-- Attachment #2: Type: text/html, Size: 6708 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-12 3:19 ` Gengjia Chen @ 2016-10-12 22:31 ` Kees Cook 2016-10-13 11:14 ` Gengjia Chen 0 siblings, 1 reply; 54+ messages in thread From: Kees Cook @ 2016-10-12 22:31 UTC (permalink / raw) To: kernel-hardening On Tue, Oct 11, 2016 at 8:19 PM, Gengjia Chen <chengjia4574@gmail.com> wrote: > Hi all, Hi, welcome! > My name is Jiayy (@chengjia4574). I am currently a security researcher in > android and linux kernel. My researches consist on hunting vulnerabilities > in kernel code (most of them within drivers) and doing exploits using those > vulns. > I had found more than 40 vulnerabilities which were confirmed by Android > Security Team > in the past year. I also figured out some way to attack mitigation solutions > of kernel > (such as Bypass PXN). In your research have you seen a common kind of bug that results in the vulnerabilities you find? Is there anything that would have significantly made exploitation more difficult in the things you worked on? > Those works help me get familiar with the kernel(device tree, memory > management, > network , some features especially those associated with security such as > pxn, selinux, seccomp) and ARM instruction. However, it is not enough to get > involved in real security development in kernel. Therefore, I am looking for > task > I can accomplish to be involved into real kernel development! Recently I > found > this project (kernel self protection) and I thought it is so interesting. > > I don't know whether I can involve and where I can begin, I am looking > forward to > your response. Are you interested mostly in ARM-specific things? Are you interested in kernel-assisted userspace defenses too? -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-12 22:31 ` Kees Cook @ 2016-10-13 11:14 ` Gengjia Chen 2016-10-13 18:50 ` Kees Cook 0 siblings, 1 reply; 54+ messages in thread From: Gengjia Chen @ 2016-10-13 11:14 UTC (permalink / raw) To: keescook; +Cc: kernel-hardening [-- Attachment #1: Type: text/plain, Size: 3162 bytes --] > In your research have you seen a common kind of bug that results in > the vulnerabilities you find? No, Most of those issues are caused by the lack of checking of user input length in copy_xx_user functions or afterwards in memcpy functions, however, looking into the details, they vary among different functions in different files. > Is there anything that would have > significantly made exploitation more difficult in the things you > worked on? Yes! I mostly exploit buffer overflow vulns by overwrite function pointers (such as pointers in file_operations) of a global object or a heap object to redirect execution (and if PXN is enable, we simply use rop gadgets). Therefore mitigation solutions of Function_pointer_overwrite <https://kernsec.org/wiki/index.php/Exploit_Methods/Function_pointer_overwrite> would make such kind of exploitation much more diffcult. But I don't know if you have let all the pointers "const". Becsides, ret2dir is a common way to exploit UAF vulns so I think solutions like XPFO is a way to make those kind of exploitation more diffcult. Right now KALSR is still disable in most android devices, so it is easy to get kernel symbol address, however if KALSR is enable, it may make exploitation more diffcult. > Are you interested mostly in ARM-specific things? I am famillar with ARM-specific things mostly, but I can also accept x86/x64 tasks. > Are you interested in kernel-assisted userspace defenses too? What dose that mean ? something like seccomp ? 2016-10-13 6:31 GMT+08:00 Kees Cook <keescook@chromium.org>: > On Tue, Oct 11, 2016 at 8:19 PM, Gengjia Chen <chengjia4574@gmail.com> > wrote: > > Hi all, > > Hi, welcome! > > > My name is Jiayy (@chengjia4574). I am currently a security researcher in > > android and linux kernel. My researches consist on hunting > vulnerabilities > > in kernel code (most of them within drivers) and doing exploits using > those > > vulns. > > I had found more than 40 vulnerabilities which were confirmed by Android > > Security Team > > in the past year. I also figured out some way to attack mitigation > solutions > > of kernel > > (such as Bypass PXN). > > In your research have you seen a common kind of bug that results in > the vulnerabilities you find? Is there anything that would have > significantly made exploitation more difficult in the things you > worked on? > > > Those works help me get familiar with the kernel(device tree, memory > > management, > > network , some features especially those associated with security such as > > pxn, selinux, seccomp) and ARM instruction. However, it is not enough to > get > > involved in real security development in kernel. Therefore, I am looking > for > > task > > I can accomplish to be involved into real kernel development! Recently I > > found > > this project (kernel self protection) and I thought it is so interesting. > > > > I don't know whether I can involve and where I can begin, I am looking > > forward to > > your response. > > Are you interested mostly in ARM-specific things? Are you interested > in kernel-assisted userspace defenses too? > > -Kees > > -- > Kees Cook > Nexus Security > [-- Attachment #2: Type: text/html, Size: 25790 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-13 11:14 ` Gengjia Chen @ 2016-10-13 18:50 ` Kees Cook 2016-10-17 11:57 ` Gengjia Chen 0 siblings, 1 reply; 54+ messages in thread From: Kees Cook @ 2016-10-13 18:50 UTC (permalink / raw) To: Gengjia Chen, Juerg Haefliger; +Cc: kernel-hardening On Thu, Oct 13, 2016 at 4:14 AM, Gengjia Chen <chengjia4574@gmail.com> wrote: >> In your research have you seen a common kind of bug that results in >> the vulnerabilities you find? > > No, > Most of those issues are caused by the lack of checking of user input > length > in copy_xx_user functions or afterwards in memcpy functions, > however, looking into the details, > they vary among different functions in different files. Cool, I hope the recent hardened usercopy stuff will improve that situation, though there is plenty left to do. >> Is there anything that would have >> significantly made exploitation more difficult in the things you >> worked on? > > Yes! > > I mostly exploit buffer overflow vulns by overwrite function pointers (such > as > pointers in file_operations) of a global object or a heap object > to redirect execution (and if PXN is enable, we simply use rop gadgets). > Therefore mitigation solutions of Function_pointer_overwrite would > make such kind of exploitation much more diffcult. > But I don't know if you have let all the pointers "const". Creating a mechanism like PaX's pax_open_kernel()/pax_close_kernel() combined with the constify plugin would vastly improve the function tables that could be const in the kernel. Perhaps that's something you could look at: porting the pax_open_kernel()/pax_close_kernel() infrastructure on ARM to upstream? > Becsides, ret2dir is a common way to exploit UAF vulns > so I think solutions like XPFO is a way to make > those kind of exploitation more diffcult. That's also good to hear. XPFO is making some progress; I'm looking forward to it's next patch version (though IIUC, we'll need arch-specific support for it on ARM -- the current patches are x86 only). > Right now KALSR is still disable in most android devices, > so it is easy to get kernel symbol address, > however if KALSR is enable, it may make exploitation more diffcult. Eliminating the various address exposures for KASLR is going to be a long process, I suspect. If you find any that look easily fixable, let's get them in. :) >> Are you interested mostly in ARM-specific things? > > I am famillar with ARM-specific things mostly, but I can also accept x86/x64 > tasks. > >> Are you interested in kernel-assisted userspace defenses too? > > What dose that mean ? something like seccomp ? Sure, though I meant things like the brute-force detection, or W^X memory enforcement for mmap/mprotect, etc. The defenses that the kernel provides, but are for userspace hardening rather than kernel hardening. -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-13 18:50 ` Kees Cook @ 2016-10-17 11:57 ` Gengjia Chen 2016-10-17 20:15 ` Kees Cook 0 siblings, 1 reply; 54+ messages in thread From: Gengjia Chen @ 2016-10-17 11:57 UTC (permalink / raw) To: Kees Cook; +Cc: kernel-hardening [-- Attachment #1: Type: text/plain, Size: 6639 bytes --] >>> In your research have you seen a common kind of bug that results in >>> the vulnerabilities you find? >> >> No, >> Most of those issues are caused by the lack of checking of user input >> length >> in copy_xx_user functions or afterwards in memcpy functions, >> however, looking into the details, >> they vary among different functions in different files. > >Cool, I hope the recent hardened usercopy stuff will improve that >situation, though there is plenty left to do. > >>> Is there anything that would have >>> significantly made exploitation more difficult in the things you >>> worked on? >> >> Yes! >> >> I mostly exploit buffer overflow vulns by overwrite function pointers (such >> as >> pointers in file_operations) of a global object or a heap object >> to redirect execution (and if PXN is enable, we simply use rop gadgets). >> Therefore mitigation solutions of Function_pointer_overwrite would >> make such kind of exploitation much more diffcult. >> But I don't know if you have let all the pointers "const". > >Creating a mechanism like PaX's pax_open_kernel()/pax_close_kernel() >combined with the constify plugin would vastly improve the function >tables that could be const in the kernel. Perhaps that's something you >could look at: porting the pax_open_kernel()/pax_close_kernel() >infrastructure on ARM to upstream? > I found that pax_open_kernel()/pax_close_kernel() infrastructure had been ported on ARM in patch grsecurity-3.1-4.7.8-201610161720.patch, as follow: file: arch/arm/include/asm/pgtable.h #ifdef CONFIG_PAX_KERNEXEC static inline unsigned long pax_open_kernel(void) { #ifdef CONFIG_ARM_LPAE /* TODO */ #else preempt_disable(); BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC)); modify_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC); #endif return 0; } static inline unsigned long pax_close_kernel(void) { #ifdef CONFIG_ARM_LPAE /* TODO */ #else BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_MANAGER)); /* DOMAIN_MANAGER = "client" under KERNEXEC */ modify_domain(DOMAIN_KERNEL, DOMAIN_MANAGER); preempt_enable_no_resched(); #endif return 0; } #else static inline unsigned long pax_open_kernel(void) { return 0; } static inline unsigned long pax_close_kernel(void) { return 0; } #endif Is there anything else I can do to help about this (mitigation solutions of Function_pointer_overwrite )? >> Becsides, ret2dir is a common way to exploit UAF vulns >> so I think solutions like XPFO is a way to make >> those kind of exploitation more diffcult. > >That's also good to hear. XPFO is making some progress; I'm looking >forward to it's next patch version (though IIUC, we'll need >arch-specific support for it on ARM -- the current patches are x86 >only). > I think I can also start with porting XPFO on ARM if you need. >> Right now KALSR is still disable in most android devices, >> so it is easy to get kernel symbol address, >> however if KALSR is enable, it may make exploitation more diffcult. > >Eliminating the various address exposures for KASLR is going to be a >long process, I suspect. If you find any that look easily fixable, >let's get them in. :) > >>> Are you interested mostly in ARM-specific things? >> >> I am famillar with ARM-specific things mostly, but I can also accept x86/x64 >> tasks. >> >>> Are you interested in kernel-assisted userspace defenses too? >> >> What dose that mean ? something like seccomp ? > >Sure, though I meant things like the brute-force detection, or W^X >memory enforcement for mmap/mprotect, etc. The defenses that the >kernel provides, but are for userspace hardening rather than kernel >hardening. Right now, I am rather more interested in kernel hardening, however, if there are people in charge of all areas, I can also get involve in userspace hardening 2016-10-14 2:50 GMT+08:00 Kees Cook <keescook@chromium.org>: > On Thu, Oct 13, 2016 at 4:14 AM, Gengjia Chen <chengjia4574@gmail.com> > wrote: > >> In your research have you seen a common kind of bug that results in > >> the vulnerabilities you find? > > > > No, > > Most of those issues are caused by the lack of checking of user input > > length > > in copy_xx_user functions or afterwards in memcpy functions, > > however, looking into the details, > > they vary among different functions in different files. > > Cool, I hope the recent hardened usercopy stuff will improve that > situation, though there is plenty left to do. > > >> Is there anything that would have > >> significantly made exploitation more difficult in the things you > >> worked on? > > > > Yes! > > > > I mostly exploit buffer overflow vulns by overwrite function pointers > (such > > as > > pointers in file_operations) of a global object or a heap object > > to redirect execution (and if PXN is enable, we simply use rop gadgets). > > Therefore mitigation solutions of Function_pointer_overwrite would > > make such kind of exploitation much more diffcult. > > But I don't know if you have let all the pointers "const". > > Creating a mechanism like PaX's pax_open_kernel()/pax_close_kernel() > combined with the constify plugin would vastly improve the function > tables that could be const in the kernel. Perhaps that's something you > could look at: porting the pax_open_kernel()/pax_close_kernel() > infrastructure on ARM to upstream? > > > Becsides, ret2dir is a common way to exploit UAF vulns > > so I think solutions like XPFO is a way to make > > those kind of exploitation more diffcult. > > That's also good to hear. XPFO is making some progress; I'm looking > forward to it's next patch version (though IIUC, we'll need > arch-specific support for it on ARM -- the current patches are x86 > only). > > > Right now KALSR is still disable in most android devices, > > so it is easy to get kernel symbol address, > > however if KALSR is enable, it may make exploitation more diffcult. > > Eliminating the various address exposures for KASLR is going to be a > long process, I suspect. If you find any that look easily fixable, > let's get them in. :) > > >> Are you interested mostly in ARM-specific things? > > > > I am famillar with ARM-specific things mostly, but I can also accept > x86/x64 > > tasks. > > > >> Are you interested in kernel-assisted userspace defenses too? > > > > What dose that mean ? something like seccomp ? > > Sure, though I meant things like the brute-force detection, or W^X > memory enforcement for mmap/mprotect, etc. The defenses that the > kernel provides, but are for userspace hardening rather than kernel > hardening. > > -Kees > > -- > Kees Cook > Nexus Security > [-- Attachment #2: Type: text/html, Size: 9147 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-17 11:57 ` Gengjia Chen @ 2016-10-17 20:15 ` Kees Cook 2016-10-18 11:52 ` Gengjia Chen 0 siblings, 1 reply; 54+ messages in thread From: Kees Cook @ 2016-10-17 20:15 UTC (permalink / raw) To: Gengjia Chen; +Cc: kernel-hardening, Juerg Haefliger On Mon, Oct 17, 2016 at 4:57 AM, Gengjia Chen <chengjia4574@gmail.com> wrote: >>>> In your research have you seen a common kind of bug that results in >>>> the vulnerabilities you find? >>> >>> No, >>> Most of those issues are caused by the lack of checking of user input >>> length >>> in copy_xx_user functions or afterwards in memcpy functions, >>> however, looking into the details, >>> they vary among different functions in different files. >> >>Cool, I hope the recent hardened usercopy stuff will improve that >>situation, though there is plenty left to do. >> >>>> Is there anything that would have >>>> significantly made exploitation more difficult in the things you >>>> worked on? >>> >>> Yes! >>> >>> I mostly exploit buffer overflow vulns by overwrite function pointers >>> (such >>> as >>> pointers in file_operations) of a global object or a heap object >>> to redirect execution (and if PXN is enable, we simply use rop gadgets). >>> Therefore mitigation solutions of Function_pointer_overwrite would >>> make such kind of exploitation much more diffcult. >>> But I don't know if you have let all the pointers "const". >> >>Creating a mechanism like PaX's pax_open_kernel()/pax_close_kernel() >>combined with the constify plugin would vastly improve the function >>tables that could be const in the kernel. Perhaps that's something you >>could look at: porting the pax_open_kernel()/pax_close_kernel() >>infrastructure on ARM to upstream? >> > > I found that pax_open_kernel()/pax_close_kernel() infrastructure > had been ported on ARM in patch > grsecurity-3.1-4.7.8-201610161720.patch, as follow: > > file: arch/arm/include/asm/pgtable.h > > #ifdef CONFIG_PAX_KERNEXEC > static inline unsigned long pax_open_kernel(void) { > #ifdef CONFIG_ARM_LPAE > /* TODO */ > #else > preempt_disable(); > BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC)); > modify_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC); > #endif > return 0; > } > > static inline unsigned long pax_close_kernel(void) { > #ifdef CONFIG_ARM_LPAE > /* TODO */ > #else > BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_MANAGER)); > /* DOMAIN_MANAGER = "client" under KERNEXEC */ > modify_domain(DOMAIN_KERNEL, DOMAIN_MANAGER); > preempt_enable_no_resched(); > #endif > return 0; > } > #else > static inline unsigned long pax_open_kernel(void) { return 0; } > static inline unsigned long pax_close_kernel(void) { return 0; } > #endif > > Is there anything else I can do to help about this (mitigation solutions of > Function_pointer_overwrite )? The ARM open/close depends on their use of Domains. For upstream, you'd have to examine how Domains are being used (which seems different to me). The other work is building the in-kernel infrastructure to support write-rarely memory (likely a new section, like ro_after_init, etc). >>> Becsides, ret2dir is a common way to exploit UAF vulns >>> so I think solutions like XPFO is a way to make >>> those kind of exploitation more diffcult. >> >>That's also good to hear. XPFO is making some progress; I'm looking >>forward to it's next patch version (though IIUC, we'll need >>arch-specific support for it on ARM -- the current patches are x86 >>only). > > I think I can also start with porting XPFO on ARM if you need. Sure, I'd be very curious to see this! Hopefully Juerg has some ideas for helping there (he's been working on the x86 XPFO). >>> Right now KALSR is still disable in most android devices, >>> so it is easy to get kernel symbol address, >>> however if KALSR is enable, it may make exploitation more diffcult. >> >>Eliminating the various address exposures for KASLR is going to be a >>long process, I suspect. If you find any that look easily fixable, >>let's get them in. :) >> >>>> Are you interested mostly in ARM-specific things? >>> >>> I am famillar with ARM-specific things mostly, but I can also accept >>> x86/x64 >>> tasks. >>> >>>> Are you interested in kernel-assisted userspace defenses too? >>> >>> What dose that mean ? something like seccomp ? >> >>Sure, though I meant things like the brute-force detection, or W^X >>memory enforcement for mmap/mprotect, etc. The defenses that the >>kernel provides, but are for userspace hardening rather than kernel >>hardening. > > Right now, I am rather more interested in kernel hardening, > however, if there are people in charge of all areas, I can also > get involve in userspace hardening Yeah, it's fine to stick with kernel; no worries. :) Thanks! -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-17 20:15 ` Kees Cook @ 2016-10-18 11:52 ` Gengjia Chen 2016-10-18 21:21 ` Kees Cook 0 siblings, 1 reply; 54+ messages in thread From: Gengjia Chen @ 2016-10-18 11:52 UTC (permalink / raw) To: Kees Cook; +Cc: kernel-hardening, Juerg Haefliger [-- Attachment #1: Type: text/plain, Size: 5465 bytes --] > > > > >2016-10-18 4:15 GMT+08:00 Kees Cook <keescook@chromium.org>: > >On Mon, Oct 17, 2016 at 4:57 AM, Gengjia Chen <chengjia4574@gmail.com> > wrote: > >>>>> In your research have you seen a common kind of bug that results in > >>>>> the vulnerabilities you find? > >>>> > >>>> No, > >>>> Most of those issues are caused by the lack of checking of user input > >>>> length > >>>> in copy_xx_user functions or afterwards in memcpy functions, > >>>> however, looking into the details, > >>>> they vary among different functions in different files. > >>> > >>>Cool, I hope the recent hardened usercopy stuff will improve that > >>>situation, though there is plenty left to do. > >>> > >>>>> Is there anything that would have > >>>>> significantly made exploitation more difficult in the things you > >>>>> worked on? > >>>> > >>>> Yes! > >>>> > >>>> I mostly exploit buffer overflow vulns by overwrite function pointers > >>>> (such > >>>> as > >>>> pointers in file_operations) of a global object or a heap object > >>>> to redirect execution (and if PXN is enable, we simply use rop > gadgets). > >>>> Therefore mitigation solutions of Function_pointer_overwrite would > >>>> make such kind of exploitation much more diffcult. > >>>> But I don't know if you have let all the pointers "const". > >>> > >>>Creating a mechanism like PaX's pax_open_kernel()/pax_close_kernel() > >>>combined with the constify plugin would vastly improve the function > >>>tables that could be const in the kernel. Perhaps that's something you > >>>could look at: porting the pax_open_kernel()/pax_close_kernel() > >>>infrastructure on ARM to upstream? > >>> > >> > >> I found that pax_open_kernel()/pax_close_kernel() infrastructure > >> had been ported on ARM in patch > >> grsecurity-3.1-4.7.8-201610161720.patch, as follow: > >> > >> file: arch/arm/include/asm/pgtable.h > >> > >> #ifdef CONFIG_PAX_KERNEXEC > >> static inline unsigned long pax_open_kernel(void) { > >> #ifdef CONFIG_ARM_LPAE > >> /* TODO */ > >> #else > >> preempt_disable(); > >> BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC)); > >> modify_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC); > >> #endif > >> return 0; > >> } > >> > >> static inline unsigned long pax_close_kernel(void) { > >> #ifdef CONFIG_ARM_LPAE > >> /* TODO */ > >> #else > >> BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_MANAGER)); > >> /* DOMAIN_MANAGER = "client" under KERNEXEC */ > >> modify_domain(DOMAIN_KERNEL, DOMAIN_MANAGER); > >> preempt_enable_no_resched(); > >> #endif > >> return 0; > >> } > >> #else > >> static inline unsigned long pax_open_kernel(void) { return 0; } > >> static inline unsigned long pax_close_kernel(void) { return 0; } > >> #endif > >> > >> Is there anything else I can do to help about this (mitigation > solutions of > >> Function_pointer_overwrite )? > > > >The ARM open/close depends on their use of Domains. For upstream, > >you'd have to examine how Domains are being used (which seems > >different to me). > > So, I will try to start to port pax_open_kernel/pax_close_kernel > arm-specific features to upstream, and keep you in touch. > > >The other work is building the in-kernel > >infrastructure to support write-rarely memory (likely a new section, > >like ro_after_init, etc). > > > > It seems that the constify plugin still not been ported to the lastest > code (v4.9-rc1), > If I understand, you means that a new section should be added > to the upstream , and cooperate with the future constify plugin (the > plugin automatically put those objects to that section ) ? > > > >>>> Becsides, ret2dir is a common way to exploit UAF vulns > >>>> so I think solutions like XPFO is a way to make > >>>> those kind of exploitation more diffcult. > >>> > >>>That's also good to hear. XPFO is making some progress; I'm looking > >>>forward to it's next patch version (though IIUC, we'll need > >>>arch-specific support for it on ARM -- the current patches are x86 > >>>only). > >> > >> I think I can also start with porting XPFO on ARM if you need. > > > >Sure, I'd be very curious to see this! Hopefully Juerg has some ideas > >for helping there (he's been working on the x86 XPFO). > > > >>>> Right now KALSR is still disable in most android devices, > >>>> so it is easy to get kernel symbol address, > >>>> however if KALSR is enable, it may make exploitation more diffcult. > >>> > >>>Eliminating the various address exposures for KASLR is going to be a > >>>long process, I suspect. If you find any that look easily fixable, > >>>let's get them in. :) > >>> > >>>>> Are you interested mostly in ARM-specific things? > >>>> > >>>> I am famillar with ARM-specific things mostly, but I can also accept > >>>> x86/x64 > >>>> tasks. > >>>> > >>>>> Are you interested in kernel-assisted userspace defenses too? > >>>> > >>>> What dose that mean ? something like seccomp ? > >>> > >>>Sure, though I meant things like the brute-force detection, or W^X > >>>memory enforcement for mmap/mprotect, etc. The defenses that the > >>>kernel provides, but are for userspace hardening rather than kernel > >>>hardening. > >> > >> Right now, I am rather more interested in kernel hardening, > >> however, if there are people in charge of all areas, I can also > >> get involve in userspace hardening > > > >Yeah, it's fine to stick with kernel; no worries. :) Thanks! > > > >-Kees > > > > > >-- > >Kees Cook > >Nexus Security > [-- Attachment #2: Type: text/html, Size: 10861 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-18 11:52 ` Gengjia Chen @ 2016-10-18 21:21 ` Kees Cook 0 siblings, 0 replies; 54+ messages in thread From: Kees Cook @ 2016-10-18 21:21 UTC (permalink / raw) To: Gengjia Chen; +Cc: kernel-hardening, Juerg Haefliger On Tue, Oct 18, 2016 at 4:52 AM, Gengjia Chen <chengjia4574@gmail.com> wrote: >> >2016-10-18 4:15 GMT+08:00 Kees Cook <keescook@chromium.org>: >> >The ARM open/close depends on their use of Domains. For upstream, >> >you'd have to examine how Domains are being used (which seems >> >different to me). >> >> So, I will try to start to port pax_open_kernel/pax_close_kernel >> arm-specific features to upstream, and keep you in touch. Cool, feel free to post RFC patches even if they're not totally finished. :) >> >The other work is building the in-kernel >> >infrastructure to support write-rarely memory (likely a new section, >> >like ro_after_init, etc). >> > >> >> It seems that the constify plugin still not been ported to the lastest >> code (v4.9-rc1), >> If I understand, you means that a new section should be added >> to the upstream , and cooperate with the future constify plugin (the >> plugin automatically put those objects to that section ) ? It hasn't been forward-ported, no, but building out the infrastructure to support it in upstream will be needed regardless. In PaX, the section is called .data..read_only, but I suspect that will turn out to be a confusing name, since it's actually "write-rarely", but lives in the .rodata section, and the open/close implementation will be used to write to it. The constify plugin actually moves variables into the .rodata section, so not only does any code writing to such things need to be wrapped in open/close calls, but the C compiler needs to be tricked into generating sensible code (see PaX's const_cast() macro). -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-10 21:05 ` Kees Cook 2016-10-12 3:19 ` Gengjia Chen @ 2016-10-12 8:25 ` Colin Vidal 2016-10-12 22:35 ` Kees Cook 1 sibling, 1 reply; 54+ messages in thread From: Colin Vidal @ 2016-10-12 8:25 UTC (permalink / raw) To: kernel-hardening, AKASHI Takahiro, Kees Cook; +Cc: Reshetova, Elena > > So, I will try to start to port PAX_REFCOUNT arm-specific features > > to hardened_atomic_on_next, and keep you in touch. Is there a > > deadline? (4.10 / 5.0 merge window?) > > You may want to compare notes with Takahiro (CCed) who may have > started to look at arm64 (and maybe arm too). Thanks, I would be grateful! > As for a deadline, as Elena says, we have no specific target. ("As > soon as possible.") The only thing around timing that I like to see > is persistent progress: if a patch series goes up for review, > getting people to take a look at it, ask questions, make comments, > and then hopefully within a week or so, the next version comes > up. Momentum is easier to maintain than to build. ;) OK, good! I will have more time to work on it this WE, still I began to familiarize myself with atomic_t internals (and PaX patch). I noticed the build is broken for non-x86 architecture (at least arm/arm64), since basically each arch needs to provide atomic_*_wrap() functions. Is there plans to have (probably dummies) functions in case the architecture does not implements this functionality? I noticed the list of define atomic_*_wrap at the end of atomic-long.h, but it does not seems to works (they are defined after the call sites in the expansion of previous macros). Apart from that, in case of over-/underflow, hardened_atomic_overflow() is called to hang the system if CONFIG_HARDENED_ATOMIC is set. I don't get why the test in arch/x86/include/kernel/traps.c if (trapnr == X86_TRAP_OF) hardened_atomic_overflow(regs); is not guarded by CONFIG_HARDENED_ATOMIC: the trap cannot occurs if CONFIG_HARDENED_ATOMIC is unset (since "int" instructions in arch/x86/include/asm/atomic.h are guarded by it), and it would avoid the other implementation of hardened_atomic_overflow in include/asm-generic/bug.h. > > [1] https://pax.grsecurity.net/pax-linux-3.6-201210022100.patch > > This is a quite old version of PaX. (Note the date.) If you want to > examine PaX separately from Grsecurity (noting differences can be > enlightening), check here: > > https://www.grsecurity.net/~paxguy1/?C=M;O=D Thanks! Colin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-12 8:25 ` Colin Vidal @ 2016-10-12 22:35 ` Kees Cook 2016-10-13 13:54 ` Reshetova, Elena 0 siblings, 1 reply; 54+ messages in thread From: Kees Cook @ 2016-10-12 22:35 UTC (permalink / raw) To: Colin Vidal; +Cc: kernel-hardening, AKASHI Takahiro, Reshetova, Elena On Wed, Oct 12, 2016 at 1:25 AM, Colin Vidal <colin@cvidal.org> wrote: >> > So, I will try to start to port PAX_REFCOUNT arm-specific features >> > to hardened_atomic_on_next, and keep you in touch. Is there a >> > deadline? (4.10 / 5.0 merge window?) >> >> You may want to compare notes with Takahiro (CCed) who may have >> started to look at arm64 (and maybe arm too). > > Thanks, I would be grateful! Here's a thread Takahiro replied to: http://www.openwall.com/lists/kernel-hardening/2016/10/12/2 >> As for a deadline, as Elena says, we have no specific target. ("As >> soon as possible.") The only thing around timing that I like to see >> is persistent progress: if a patch series goes up for review, >> getting people to take a look at it, ask questions, make comments, >> and then hopefully within a week or so, the next version comes >> up. Momentum is easier to maintain than to build. ;) > > OK, good! I will have more time to work on it this WE, still I began to > familiarize myself with atomic_t internals (and PaX patch). > > I noticed the build is broken for non-x86 architecture (at least > arm/arm64), since basically each arch needs to provide atomic_*_wrap() > functions. Is there plans to have (probably dummies) functions in case > the architecture does not implements this functionality? I noticed the > list of define atomic_*_wrap at the end of atomic-long.h, but it does > not seems to works (they are defined after the call sites in the > expansion of previous macros). Yeah, I think this has already come up in the other thread and folks are fixing (have fixed?) it. I expect to see a v2 RFC soon. > Apart from that, in case of over-/underflow, hardened_atomic_overflow() > is called to hang the system if CONFIG_HARDENED_ATOMIC is set. I don't No, not hang the system, but rather stop further kernel execution and kill the userspace process. > get why the test in arch/x86/include/kernel/traps.c > > if (trapnr == X86_TRAP_OF) > hardened_atomic_overflow(regs); > > is not guarded by CONFIG_HARDENED_ATOMIC: the trap cannot occurs if > CONFIG_HARDENED_ATOMIC is unset (since "int" instructions in > arch/x86/include/asm/atomic.h are guarded by it), and it would avoid > the other implementation of hardened_atomic_overflow in > include/asm-generic/bug.h. The implementation is a static inline with no body, so the compiler will automatically eliminate the entire "if" statement, since it's a no-op. This is standard kernel coding style, to make the .c code as readable as possible. Having it littered with #ifdefs makes things harder to read. >> > [1] https://pax.grsecurity.net/pax-linux-3.6-201210022100.patch >> >> This is a quite old version of PaX. (Note the date.) If you want to >> examine PaX separately from Grsecurity (noting differences can be >> enlightening), check here: >> >> https://www.grsecurity.net/~paxguy1/?C=M;O=D > > Thanks! Sure thing! I'm glad to have another set of eyes on this -- it's a pretty big set of changes. :) -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: [kernel-hardening] self introduction 2016-10-12 22:35 ` Kees Cook @ 2016-10-13 13:54 ` Reshetova, Elena 0 siblings, 0 replies; 54+ messages in thread From: Reshetova, Elena @ 2016-10-13 13:54 UTC (permalink / raw) To: Kees Cook, Colin Vidal; +Cc: kernel-hardening, AKASHI Takahiro > get why the test in arch/x86/include/kernel/traps.c > > if (trapnr == X86_TRAP_OF) > hardened_atomic_overflow(regs); > > is not guarded by CONFIG_HARDENED_ATOMIC: the trap cannot occurs if > CONFIG_HARDENED_ATOMIC is unset (since "int" instructions in > arch/x86/include/asm/atomic.h are guarded by it), and it would avoid > the other implementation of hardened_atomic_overflow in > include/asm-generic/bug.h. >The implementation is a static inline with no body, so the compiler will automatically eliminate the entire "if" statement, since it's a no-op. Ups, my mistake here, this static inline function currently is not empty, see: https://github.com/ereshetova/linux-stable/commit/3591430c0c7560de88b4721021f461e816d6cf38#diff-94d0be26498109f234666923aaafc7d9R221 I didn't understood this part properly, will fix it to be a real empty function. Thank you for noticing this! Best Regards, Elena. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-10 6:02 ` Reshetova, Elena 2016-10-10 16:01 ` Colin Vidal @ 2016-10-13 18:53 ` Kees Cook 2016-10-13 19:26 ` Hans Liljestrand 1 sibling, 1 reply; 54+ messages in thread From: Kees Cook @ 2016-10-13 18:53 UTC (permalink / raw) To: kernel-hardening; +Cc: Colin Vidal On Sun, Oct 9, 2016 at 11:02 PM, Reshetova, Elena <elena.reshetova@intel.com> wrote: > This branch to be precise: > https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next Github seems to think this hasn't been touched in 2 weeks and shows an error of "Failed to load latest commit information." in its web UI. Is there some place to find the last version? (Or rather, is there an RFC v2 coming soon?) I'd like to get it added to my kernel.org account so that the 0-day builder can poke at it. It regularly finds corner cases, etc... Thanks! -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-13 18:53 ` Kees Cook @ 2016-10-13 19:26 ` Hans Liljestrand 0 siblings, 0 replies; 54+ messages in thread From: Hans Liljestrand @ 2016-10-13 19:26 UTC (permalink / raw) To: kernel-hardening; +Cc: Colin Vidal On Thu, Oct 13, 2016 at 11:53:29AM -0700, Kees Cook wrote: > On Sun, Oct 9, 2016 at 11:02 PM, Reshetova, Elena > <elena.reshetova@intel.com> wrote: > > This branch to be precise: > > https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next > > Github seems to think this hasn't been touched in 2 weeks and shows an > error of "Failed to load latest commit information." in its web UI. Is > there some place to find the last version? (Or rather, is there an RFC > v2 coming soon?) Not sure what's up with the github repository, I've been getting the same error since we started. The most recent change was two days ago, which shows up on the commit page: https://github.com/ereshetova/linux-stable/commits/hardened_atomic_on_next ..although it seems the individual dates haven't been updated, so maybe it's some issue with how we've been doing the updates. Anyays, the most recent code should be available there. I'm working under the assumption we're trying to get the RFC v2 out next week, so hopefully soon. Best Regards, -hans ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-09 12:34 [kernel-hardening] self introduction Colin Vidal 2016-10-09 14:04 ` David Windsor @ 2016-10-10 20:57 ` Kees Cook 2016-10-12 8:27 ` Colin Vidal 2016-10-14 18:32 ` Andy Lutomirski 1 sibling, 2 replies; 54+ messages in thread From: Kees Cook @ 2016-10-10 20:57 UTC (permalink / raw) To: Colin Vidal, Andy Lutomirski; +Cc: kernel-hardening On Sun, Oct 9, 2016 at 5:34 AM, Colin Vidal <colin@cvidal.org> wrote: > My name is Colin Vidal. I am currently a PhD student in computer > science. My researches consist on building a dedicated specific > language on top of JavaScript in order to handle asynchronous events in > a synchronous style. Hence, with a direct relation between the control > flow and the instruction flow. > > Beside my researches, I am taking up the Eudyptula Challenge (task 15 > submitted). It helps me to have a global view of the kernel > (organization, tree, some features), but it is not enough to get > involved in serious development. Therefore, I am looking for task I can > accomplish to be involved into real kernel development! Hi! Welcome to the fun! :) I see there's already a thread getting into the HARDENED_ATOMIC effort, though I thought I might bring up some other areas too, in case they entice you as well. You've got some background in control flow -- have you spent much time in compiler internals? The recent addition of the gcc plugin infrastructure means there's a much wider ability for the kernel to do compiler tricks now. Two things that come to mind for CFI when looking at the existing PaX/Grsecurity gcc plugins are the kernexec plugin (which, AIUI, is mainly a weak form of SMEP emulation on x86, using simple CFI to keep the high bit set on all kernel function calls) which I think would be easy to extract as a stand-alone plugin: https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/scripts/gcc-plugins/kernexec_plugin.c And at the other end of the spectrum is the RAP plugin (which does a portion of PaX's full RAP, though there appear to be some non-trivial kernel changes need to support it, e.g. per-cpu PGD): https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf > I still don't have yet a narrow idea about where I can begin. I like > though the idea of kernel self protection. For instance, I find the VM- > mapped stack to be really interesting, but I think it is an overkill as > a beginning, and a lot of work have already been done on it. On the > architecture point-of-view, I have a preference of x86 since I only > have this hardware for now, but I can work on ARM and others with QEMU > too. A piece missing from vmap-stack (I think) is having guard pages at _both_ ends of the kernel stack. Andy Lutomirski surely knows better than I do, but I'm hoping he's working on looking at PCID-based SMAP emulation. (Hi Andy!) :) -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-10 20:57 ` Kees Cook @ 2016-10-12 8:27 ` Colin Vidal 2016-10-12 22:40 ` Kees Cook 2016-10-14 18:32 ` Andy Lutomirski 1 sibling, 1 reply; 54+ messages in thread From: Colin Vidal @ 2016-10-12 8:27 UTC (permalink / raw) To: kernel-hardening; +Cc: Kees Cook > > Beside my researches, I am taking up the Eudyptula Challenge (task > > 15 submitted). It helps me to have a global view of the kernel > > (organization, tree, some features), but it is not enough to get > > involved in serious development. Therefore, I am looking for task > > I can accomplish to be involved into real kernel development! > > Hi! Welcome to the fun! :) Cheers :) > I see there's already a thread getting into the HARDENED_ATOMIC > effort, though I thought I might bring up some other areas too, in > case they entice you as well. You've got some background in control > flow -- have you spent much time in compiler internals? The recent Not really on mainstream compilers. I've done some static inter/intra procedural analysis on previous projects (in order to optimize object call site), and the compiler of the DSL I'm working on is based on a completely different theories (it uses Esterel synchronous language semantic) and does not uses static CFG. Hence, I am quite far of CFI analysis :( > addition of the gcc plugin infrastructure means there's a much wider > ability for the kernel to do compiler tricks now. Two things that > come to mind for CFI when looking at the existing PaX/Grsecurity gcc > plugins are the kernexec plugin (which, AIUI, is mainly a weak form > of SMEP emulation on x86, using simple CFI to keep the high bit set > on all kernel function calls) which I think would be easy to extract > as a stand-alone plugin: > > https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/sc > ripts/gcc-plugins/kernexec_plugin.c If I understand, this plugin protects against running user-space code in supervisor mode (SMEP emulation, so avoid ROP class exploit), but since this analysis is purely static, it does not protects again out-of-tree dynamically loaded modules, right? > And at the other end of the spectrum is the RAP plugin (which does a > portion of PaX's full RAP, though there appear to be some non-trivial > kernel changes need to support it, e.g. per-cpu PGD): > > https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf Seems really interesting, though! I have plenty of food for thought with HARDENED_ATOMIC port for now, but I keep that in the back of my mind! > > I still don't have yet a narrow idea about where I can begin. I > > like though the idea of kernel self protection. For instance, I > > find the VM- mapped stack to be really interesting, but I think it > > is an overkill as a beginning, and a lot of work have already been > > done on it. On the architecture point-of-view, I have a preference > > of x86 since I only have this hardware for now, but I can work on > > ARM and others with QEMU too. > > A piece missing from vmap-stack (I think) is having guard pages at > _both_ ends of the kernel stack. Andy Lutomirski surely knows better > than I do, but I'm hoping he's working on looking at PCID-based SMAP > emulation. (Hi Andy!) :) > > -Kees Thanks! Colin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-12 8:27 ` Colin Vidal @ 2016-10-12 22:40 ` Kees Cook 0 siblings, 0 replies; 54+ messages in thread From: Kees Cook @ 2016-10-12 22:40 UTC (permalink / raw) To: Colin Vidal; +Cc: kernel-hardening On Wed, Oct 12, 2016 at 1:27 AM, Colin Vidal <colin@cvidal.org> wrote: >> I see there's already a thread getting into the HARDENED_ATOMIC >> effort, though I thought I might bring up some other areas too, in >> case they entice you as well. You've got some background in control >> flow -- have you spent much time in compiler internals? The recent > > Not really on mainstream compilers. I've done some static inter/intra > procedural analysis on previous projects (in order to optimize object > call site), and the compiler of the DSL I'm working on is based on a > completely different theories (it uses Esterel synchronous language > semantic) and does not uses static CFG. Hence, I am quite far of CFI > analysis :( Heh, okay, no worries. I just thought I'd ask. I saw some key words in your introduction. ;) >> addition of the gcc plugin infrastructure means there's a much wider >> ability for the kernel to do compiler tricks now. Two things that >> come to mind for CFI when looking at the existing PaX/Grsecurity gcc >> plugins are the kernexec plugin (which, AIUI, is mainly a weak form >> of SMEP emulation on x86, using simple CFI to keep the high bit set >> on all kernel function calls) which I think would be easy to extract >> as a stand-alone plugin: >> >> https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/sc >> ripts/gcc-plugins/kernexec_plugin.c > > If I understand, this plugin protects against running user-space code > in supervisor mode (SMEP emulation, so avoid ROP class exploit), but > since this analysis is purely static, it does not protects again > out-of-tree dynamically loaded modules, right? I can't tell which of two questions you're asking, so I'll answer both. :) The gcc plugin infrastructure in the kernel is designed so that any kernel modules built for the kernel will get the plugin run on it. The kernexec plugin in particular, however, has logic to handle totally out-of-tree builds that lack the instrumentation (see the Kconfig for it). In that case, that module would not be protected, but the rest of the kernel would be. And, allowing arbitrary module loading on a system would nullify virtually all kernel self-protection efforts when defending against the root user, so it's an assumed that systems that are serious about system security are either built monolithic (without modules) or perform some kind of module verification (module signing, or LoadPin with dm-verity). -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] self introduction 2016-10-10 20:57 ` Kees Cook 2016-10-12 8:27 ` Colin Vidal @ 2016-10-14 18:32 ` Andy Lutomirski 1 sibling, 0 replies; 54+ messages in thread From: Andy Lutomirski @ 2016-10-14 18:32 UTC (permalink / raw) To: Kees Cook; +Cc: Colin Vidal, Andy Lutomirski, kernel-hardening On Mon, Oct 10, 2016 at 1:57 PM, Kees Cook <keescook@chromium.org> wrote: > On Sun, Oct 9, 2016 at 5:34 AM, Colin Vidal <colin@cvidal.org> wrote: >> My name is Colin Vidal. I am currently a PhD student in computer >> science. My researches consist on building a dedicated specific >> language on top of JavaScript in order to handle asynchronous events in >> a synchronous style. Hence, with a direct relation between the control >> flow and the instruction flow. >> >> Beside my researches, I am taking up the Eudyptula Challenge (task 15 >> submitted). It helps me to have a global view of the kernel >> (organization, tree, some features), but it is not enough to get >> involved in serious development. Therefore, I am looking for task I can >> accomplish to be involved into real kernel development! > > Hi! Welcome to the fun! :) > > I see there's already a thread getting into the HARDENED_ATOMIC > effort, though I thought I might bring up some other areas too, in > case they entice you as well. You've got some background in control > flow -- have you spent much time in compiler internals? The recent > addition of the gcc plugin infrastructure means there's a much wider > ability for the kernel to do compiler tricks now. Two things that come > to mind for CFI when looking at the existing PaX/Grsecurity gcc > plugins are the kernexec plugin (which, AIUI, is mainly a weak form of > SMEP emulation on x86, using simple CFI to keep the high bit set on > all kernel function calls) which I think would be easy to extract as a > stand-alone plugin: > > https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/scripts/gcc-plugins/kernexec_plugin.c > > And at the other end of the spectrum is the RAP plugin (which does a > portion of PaX's full RAP, though there appear to be some non-trivial > kernel changes need to support it, e.g. per-cpu PGD): > > https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf Linus has loudly poo-pooed per-cpu PGD, and I'm not sure I disagree. It would be *really* nice to find a clean way to do RAP without it. > >> I still don't have yet a narrow idea about where I can begin. I like >> though the idea of kernel self protection. For instance, I find the VM- >> mapped stack to be really interesting, but I think it is an overkill as >> a beginning, and a lot of work have already been done on it. On the >> architecture point-of-view, I have a preference of x86 since I only >> have this hardware for now, but I can work on ARM and others with QEMU >> too. > > A piece missing from vmap-stack (I think) is having guard pages at > _both_ ends of the kernel stack. Andy Lutomirski surely knows better > than I do, but I'm hoping he's working on looking at PCID-based SMAP > emulation. (Hi Andy!) :) > Hi! I'm not presently working on it, and I'm a bit swamped, but maybe soon. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [kernel-hardening] Self Introduction @ 2015-12-09 17:21 David Brown 2015-12-09 22:19 ` Kees Cook 0 siblings, 1 reply; 54+ messages in thread From: David Brown @ 2015-12-09 17:21 UTC (permalink / raw) To: kernel-hardening Per "Get Involved" on the Kernel Self Protection Project wiki, I'm introducing myself. I have recently joined Linaro on the Security Working Group. As such, I expect to seen be getting involved with the various kernel hardening and related projects. David Brown ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-09 17:21 [kernel-hardening] Self Introduction David Brown @ 2015-12-09 22:19 ` Kees Cook 2015-12-10 0:00 ` David Brown 0 siblings, 1 reply; 54+ messages in thread From: Kees Cook @ 2015-12-09 22:19 UTC (permalink / raw) To: kernel-hardening On Wed, Dec 9, 2015 at 9:21 AM, David Brown <david.brown@linaro.org> wrote: > Per "Get Involved" on the Kernel Self Protection Project wiki, I'm > introducing myself. > > I have recently joined Linaro on the Security Working Group. As such, > I expect to seen be getting involved with the various kernel hardening > and related projects. Hi David! Welcome to the mailing list. :) What sorts of things are you interested in working on? -Kees -- Kees Cook Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-09 22:19 ` Kees Cook @ 2015-12-10 0:00 ` David Brown 2015-12-10 0:14 ` Kees Cook 0 siblings, 1 reply; 54+ messages in thread From: David Brown @ 2015-12-10 0:00 UTC (permalink / raw) To: kernel-hardening On Wed, Dec 09, 2015 at 02:19:24PM -0800, Kees Cook wrote: >On Wed, Dec 9, 2015 at 9:21 AM, David Brown <david.brown@linaro.org> wrote: >> Per "Get Involved" on the Kernel Self Protection Project wiki, I'm >> introducing myself. >> >> I have recently joined Linaro on the Security Working Group. As such, >> I expect to seen be getting involved with the various kernel hardening >> and related projects. > >Welcome to the mailing list. :) > >What sorts of things are you interested in working on? A while back, I'd gone through each of the features in grsecurity and PAX. There were a number that seemed good from a security point of view, but difficult in terms of culture within the kernel. I've just started up going through these again, as well as reading the kernel hardening wiki, and I should soon have a better idea of what would be good to work on. My scope is broad enough that I want to get a good idea of where others want to go as well, as well as what brings good benefit. I suspect part of the challenge is going to be clearly describing the various features along with specific examples of already-discovered exploits that the feature would have mitigated. Most recently, I backported ARM PAN support to the Linaro stable kernels (3.18 and 4.1). David ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 0:00 ` David Brown @ 2015-12-10 0:14 ` Kees Cook 2015-12-10 0:26 ` David Brown 0 siblings, 1 reply; 54+ messages in thread From: Kees Cook @ 2015-12-10 0:14 UTC (permalink / raw) To: kernel-hardening On Wed, Dec 9, 2015 at 4:00 PM, David Brown <david.brown@linaro.org> wrote: > On Wed, Dec 09, 2015 at 02:19:24PM -0800, Kees Cook wrote: >> >> On Wed, Dec 9, 2015 at 9:21 AM, David Brown <david.brown@linaro.org> >> wrote: >>> >>> Per "Get Involved" on the Kernel Self Protection Project wiki, I'm >>> introducing myself. >>> >>> I have recently joined Linaro on the Security Working Group. As such, >>> I expect to seen be getting involved with the various kernel hardening >>> and related projects. >> >> >> Welcome to the mailing list. :) >> >> What sorts of things are you interested in working on? > > > A while back, I'd gone through each of the features in grsecurity and > PAX. There were a number that seemed good from a security point of > view, but difficult in terms of culture within the kernel. I've just > started up going through these again, as well as reading the kernel > hardening wiki, and I should soon have a better idea of what would be > good to work on. My scope is broad enough that I want to get a good > idea of where others want to go as well, as well as what brings good > benefit. Great! It might be valuable to read through this mailing lists's threads over the last month. We discuss a few of the features and some work has been started. > I suspect part of the challenge is going to be clearly describing the > various features along with specific examples of already-discovered > exploits that the feature would have mitigated. Yes indeed. :) That's why I've arranged the wiki the way I did: classes and methods first, with potential solutions listed under them. We want to start with problem descriptions and work from actual exploits when possible. This is why the recent x86 VDSO attack was very timely: it demonstrates cleanly why we want __ro_after_init (née __read_only) in upstream. (As well as the constification plugin.) > Most recently, I backported ARM PAN support to the Linaro stable > kernels (3.18 and 4.1). Excellent! Yes, I did a port to Brillo's v4.1 tree as well. It's very nice to have a UDEREF-like feature on arm. It's too bad this doesn't exist for Intel yet, but I'm hoping they'll step up. For 3.18, is this the right place to be looking? https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=shortlog;h=refs/heads/linux-linaro-lsk-v3.18 I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel too. -Kees -- Kees Cook Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 0:14 ` Kees Cook @ 2015-12-10 0:26 ` David Brown 2015-12-10 0:41 ` Kees Cook 0 siblings, 1 reply; 54+ messages in thread From: David Brown @ 2015-12-10 0:26 UTC (permalink / raw) To: kernel-hardening On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote: >Great! It might be valuable to read through this mailing lists's >threads over the last month. We discuss a few of the features and some >work has been started. Reading through stuff now. Looks like the list got quite a boost in November. >> I suspect part of the challenge is going to be clearly describing the >> various features along with specific examples of already-discovered >> exploits that the feature would have mitigated. > >Yes indeed. :) That's why I've arranged the wiki the way I did: >classes and methods first, with potential solutions listed under them. >We want to start with problem descriptions and work from actual >exploits when possible. > >This is why the recent x86 VDSO attack was very timely: it >demonstrates cleanly why we want __ro_after_init (née __read_only) in >upstream. (As well as the constification plugin.) Which also seems like this will be quite useful on ARM as well. Do you know any efforts to do this? >> Most recently, I backported ARM PAN support to the Linaro stable >> kernels (3.18 and 4.1). > >Excellent! Yes, I did a port to Brillo's v4.1 tree as well. It's very >nice to have a UDEREF-like feature on arm. It's too bad this doesn't >exist for Intel yet, but I'm hoping they'll step up. > >For 3.18, is this the right place to be looking? >https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=shortlog;h=refs/heads/linux-linaro-lsk-v3.18 It will be once it gets through testing. https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v3.18/topic/PAN to peek before then. There's also https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v4.1/topic/PAN for the 4.1 tree. Should I CC kernel-hardening when sending patches for the Linaro stable kernels? >I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel too. I'll put this on my list to investigate. Sadly, it looks like there is a bit of a window of ARM CPUs where neither solution will work; Basically the pre V8.1 64-bit. In fact, I don't have any hardware yet that supports PAN. I've done all of the testing in emulation. David ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 0:26 ` David Brown @ 2015-12-10 0:41 ` Kees Cook 2015-12-10 17:14 ` Stephen Smalley 0 siblings, 1 reply; 54+ messages in thread From: Kees Cook @ 2015-12-10 0:41 UTC (permalink / raw) To: kernel-hardening On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@linaro.org> wrote: > On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote: > >> Great! It might be valuable to read through this mailing lists's >> threads over the last month. We discuss a few of the features and some >> work has been started. > > > Reading through stuff now. Looks like the list got quite a boost in > November. > >>> I suspect part of the challenge is going to be clearly describing the >>> various features along with specific examples of already-discovered >>> exploits that the feature would have mitigated. >> >> >> Yes indeed. :) That's why I've arranged the wiki the way I did: >> classes and methods first, with potential solutions listed under them. >> We want to start with problem descriptions and work from actual >> exploits when possible. >> >> This is why the recent x86 VDSO attack was very timely: it >> demonstrates cleanly why we want __ro_after_init (née __read_only) in >> upstream. (As well as the constification plugin.) > > > Which also seems like this will be quite useful on ARM as well. Do > you know any efforts to do this? I've not seen any yet. If you get it written, I can include it in my __ro_after_init series on the next revision. >>> Most recently, I backported ARM PAN support to the Linaro stable >>> kernels (3.18 and 4.1). >> >> >> Excellent! Yes, I did a port to Brillo's v4.1 tree as well. It's very >> nice to have a UDEREF-like feature on arm. It's too bad this doesn't >> exist for Intel yet, but I'm hoping they'll step up. >> >> For 3.18, is this the right place to be looking? >> >> https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=shortlog;h=refs/heads/linux-linaro-lsk-v3.18 > > > It will be once it gets through testing. > https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v3.18/topic/PAN > to peek before then. There's also > https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v4.1/topic/PAN > for the 4.1 tree. Oh! I see now. You meant hardware PAN support. Yes, also good to get in for the arm64 devices. I meant the CONFIG_CPU_SW_DOMAIN_PAN support. I've backported that from 4.3 to 4.1 since then all arm devices would gain PAN-like support too. > Should I CC kernel-hardening when sending patches for the Linaro > stable kernels? Probably not for stable backports. I think upstream development things probably should be, and we can certainly discuss stuff that looks like it'd be good to backport, but I wouldn't want to bore people with patch for old kernels. :) >> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel >> too. > > I'll put this on my list to investigate. Sadly, it looks like there > is a bit of a window of ARM CPUs where neither solution will work; > Basically the pre V8.1 64-bit. The LPAE support for PAN emulation exists in grsecurity, if someone wanted to look at how to extract it and add it to CONFIG_CPU_SW_DOMAIN_PAN (or similar). > In fact, I don't have any hardware yet that supports PAN. I've done > all of the testing in emulation. Heh, yeah, that's how the x86 SMAP stuff is too. ;) -Kees -- Kees Cook Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 0:41 ` Kees Cook @ 2015-12-10 17:14 ` Stephen Smalley 2015-12-10 17:49 ` Kees Cook 0 siblings, 1 reply; 54+ messages in thread From: Stephen Smalley @ 2015-12-10 17:14 UTC (permalink / raw) To: kernel-hardening On Wed, Dec 9, 2015 at 7:41 PM, Kees Cook <keescook@chromium.org> wrote: > On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@linaro.org> wrote: >> On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote: >>> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel >>> too. >> >> I'll put this on my list to investigate. Sadly, it looks like there >> is a bit of a window of ARM CPUs where neither solution will work; >> Basically the pre V8.1 64-bit. > > The LPAE support for PAN emulation exists in grsecurity, if someone > wanted to look at how to extract it and add it to > CONFIG_CPU_SW_DOMAIN_PAN (or similar). Are you looking for this: http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2 Haven't seen any follow up on it though... ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 17:14 ` Stephen Smalley @ 2015-12-10 17:49 ` Kees Cook 2015-12-10 17:55 ` Daniel Micay 2015-12-10 18:42 ` Catalin Marinas 0 siblings, 2 replies; 54+ messages in thread From: Kees Cook @ 2015-12-10 17:49 UTC (permalink / raw) To: kernel-hardening; +Cc: Catalin Marinas On Thu, Dec 10, 2015 at 9:14 AM, Stephen Smalley <stephen.smalley@gmail.com> wrote: > On Wed, Dec 9, 2015 at 7:41 PM, Kees Cook <keescook@chromium.org> wrote: >> On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@linaro.org> wrote: >>> On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote: >>>> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel >>>> too. >>> >>> I'll put this on my list to investigate. Sadly, it looks like there >>> is a bit of a window of ARM CPUs where neither solution will work; >>> Basically the pre V8.1 64-bit. >> >> The LPAE support for PAN emulation exists in grsecurity, if someone >> wanted to look at how to extract it and add it to >> CONFIG_CPU_SW_DOMAIN_PAN (or similar). > > Are you looking for this: > http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2 > > Haven't seen any follow up on it though... Ah yes! Thank you! https://patchwork.kernel.org/patch/7250401/ https://patchwork.kernel.org/patch/7250391/ https://patchwork.kernel.org/patch/7250421/ https://patchwork.kernel.org/patch/7250441/ Catalin, where does this stand? Also, what options do ARMv8 (not ARMv8.1) devices have for PAN if they're running 64-bit? The matrix for PAN seems to be: ARMv7 32-bit non-LPAE: CONFIG_CPU_SW_DOMAIN_PAN ARMv7 32-bit LPAE: Catalin's series (CPU_TTBR0_PAN) ARMv8 32-bit: Catalin's series? ARMv8 64-bit: ?? ARMv8.1: hardware PAN x86 pre-late-Broadwell: nothing upstream (though UDEREF in PaX exists) x86 Broadwell+: hardware PAN (SMAP) powerpc: ?? MIPS: ?? Corrections appreciated. :) -Kees -- Kees Cook Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 17:49 ` Kees Cook @ 2015-12-10 17:55 ` Daniel Micay 2015-12-10 18:42 ` Kees Cook 2015-12-10 18:42 ` Catalin Marinas 1 sibling, 1 reply; 54+ messages in thread From: Daniel Micay @ 2015-12-10 17:55 UTC (permalink / raw) To: kernel-hardening; +Cc: Catalin Marinas [-- Attachment #1: Type: text/plain, Size: 408 bytes --] > ARMv8 64-bit: ?? The worst case scenario would be doing something like the x86_64 UDEREF. > x86 pre-late-Broadwell: nothing upstream (though UDEREF in PaX exists) It's worth noting that there's the pre-PCID implementation (slow and vulnerable to races) and then two choices of better implementations when PCID is available. You probably know that already, but it's not obvious to everyone else. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 17:55 ` Daniel Micay @ 2015-12-10 18:42 ` Kees Cook 2015-12-10 19:07 ` Daniel Micay 2015-12-10 22:38 ` PaX Team 0 siblings, 2 replies; 54+ messages in thread From: Kees Cook @ 2015-12-10 18:42 UTC (permalink / raw) To: kernel-hardening; +Cc: Catalin Marinas, PaX Team I've put the matrix up on the wiki here: http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage On Thu, Dec 10, 2015 at 9:55 AM, Daniel Micay <danielmicay@gmail.com> wrote: >> ARMv8 64-bit: ?? > > The worst case scenario would be doing something like the x86_64 UDEREF. > >> x86 pre-late-Broadwell: nothing upstream (though UDEREF in PaX exists) > > It's worth noting that there's the pre-PCID implementation (slow and > vulnerable to races) and then two choices of better implementations when > PCID is available. You probably know that already, but it's not obvious > to everyone else. Yeah. PCID was Sandybridge and later? -Kees -- Kees Cook Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 18:42 ` Kees Cook @ 2015-12-10 19:07 ` Daniel Micay 2015-12-10 19:23 ` Kees Cook 2015-12-10 22:38 ` PaX Team 1 sibling, 1 reply; 54+ messages in thread From: Daniel Micay @ 2015-12-10 19:07 UTC (permalink / raw) To: kernel-hardening; +Cc: Catalin Marinas, PaX Team [-- Attachment #1: Type: text/plain, Size: 181 bytes --] > Yeah. PCID was Sandybridge and later? Yeah, that's right. And it defaults to the strong PCID implementation, but there's also a weaker but significantly faster PCID-based one. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 19:07 ` Daniel Micay @ 2015-12-10 19:23 ` Kees Cook 2015-12-10 19:38 ` Schaufler, Casey 2015-12-12 11:40 ` Heiko Carstens 0 siblings, 2 replies; 54+ messages in thread From: Kees Cook @ 2015-12-10 19:23 UTC (permalink / raw) To: kernel-hardening Cc: Catalin Marinas, PaX Team, Michael Ellerman, Heiko Carstens, Ralf Baechle On Thu, Dec 10, 2015 at 11:07 AM, Daniel Micay <danielmicay@gmail.com> wrote: >> Yeah. PCID was Sandybridge and later? > > Yeah, that's right. And it defaults to the strong PCID implementation, > but there's also a weaker but significantly faster PCID-based one. Is there anyone from Intel on the list? I would love to see UDEREF ported to upstream on x86 (and the non PCID version too). No one has stepped up to work on it yet. As for non-ARM and non-x86, IIRC s/390 has always had PAN, and I'd love to update the matrix for powerpc and MIPS. http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage -Kees -- Kees Cook Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: [kernel-hardening] Self Introduction 2015-12-10 19:23 ` Kees Cook @ 2015-12-10 19:38 ` Schaufler, Casey 2015-12-10 19:45 ` Kees Cook 2015-12-12 11:40 ` Heiko Carstens 1 sibling, 1 reply; 54+ messages in thread From: Schaufler, Casey @ 2015-12-10 19:38 UTC (permalink / raw) To: Kees Cook, kernel-hardening Cc: Catalin Marinas, PaX Team, Michael Ellerman, Heiko Carstens, Ralf Baechle > -----Original Message----- > From: keescook@google.com [mailto:keescook@google.com] On Behalf Of > Kees Cook > Sent: Thursday, December 10, 2015 11:24 AM > To: kernel-hardening@lists.openwall.com > Cc: Catalin Marinas <catalin.marinas@arm.com>; PaX Team > <pageexec@freemail.hu>; Michael Ellerman <mpe@ellerman.id.au>; Heiko > Carstens <heiko.carstens@de.ibm.com>; Ralf Baechle <ralf@linux-mips.org> > Subject: Re: [kernel-hardening] Self Introduction > > On Thu, Dec 10, 2015 at 11:07 AM, Daniel Micay <danielmicay@gmail.com> > wrote: > >> Yeah. PCID was Sandybridge and later? > > > > Yeah, that's right. And it defaults to the strong PCID implementation, > > but there's also a weaker but significantly faster PCID-based one. > > Is there anyone from Intel on the list? I would love to see UDEREF > ported to upstream on x86 (and the non PCID version too). No one has > stepped up to work on it yet. Yes, we're here. There are a couple things we need to do before making commitments on things, including deciding which are the most urgent from our perspective. We will be looking at what we want to do with UDEREF. > As for non-ARM and non-x86, IIRC s/390 has always had PAN, and I'd > love to update the matrix for powerpc and MIPS. > > http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage > > -Kees > > -- > Kees Cook > Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 19:38 ` Schaufler, Casey @ 2015-12-10 19:45 ` Kees Cook 2015-12-11 17:54 ` Valdis.Kletnieks 0 siblings, 1 reply; 54+ messages in thread From: Kees Cook @ 2015-12-10 19:45 UTC (permalink / raw) To: Schaufler, Casey Cc: kernel-hardening, Catalin Marinas, PaX Team, Michael Ellerman, Heiko Carstens, Ralf Baechle On Thu, Dec 10, 2015 at 11:38 AM, Schaufler, Casey <casey.schaufler@intel.com> wrote: >> -----Original Message----- >> From: keescook@google.com [mailto:keescook@google.com] On Behalf Of >> Kees Cook >> Sent: Thursday, December 10, 2015 11:24 AM >> To: kernel-hardening@lists.openwall.com >> Cc: Catalin Marinas <catalin.marinas@arm.com>; PaX Team >> <pageexec@freemail.hu>; Michael Ellerman <mpe@ellerman.id.au>; Heiko >> Carstens <heiko.carstens@de.ibm.com>; Ralf Baechle <ralf@linux-mips.org> >> Subject: Re: [kernel-hardening] Self Introduction >> >> On Thu, Dec 10, 2015 at 11:07 AM, Daniel Micay <danielmicay@gmail.com> >> wrote: >> >> Yeah. PCID was Sandybridge and later? >> > >> > Yeah, that's right. And it defaults to the strong PCID implementation, >> > but there's also a weaker but significantly faster PCID-based one. >> >> Is there anyone from Intel on the list? I would love to see UDEREF >> ported to upstream on x86 (and the non PCID version too). No one has >> stepped up to work on it yet. > > Yes, we're here. There are a couple things we need to do before making > commitments on things, including deciding which are the most urgent > from our perspective. We will be looking at what we want to do with > UDEREF. That's great! Thanks for speaking up. Another area that hasn't seen any traction yet is PAX_USERCOPY. Valdis seems to be MIA, so I'd love to see someone else take on that chunk of work. -Kees -- Kees Cook Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 19:45 ` Kees Cook @ 2015-12-11 17:54 ` Valdis.Kletnieks 2015-12-11 18:44 ` Kees Cook 0 siblings, 1 reply; 54+ messages in thread From: Valdis.Kletnieks @ 2015-12-11 17:54 UTC (permalink / raw) To: kernel-hardening Cc: Schaufler, Casey, Catalin Marinas, PaX Team, Michael Ellerman, Heiko Carstens, Ralf Baechle [-- Attachment #1: Type: text/plain, Size: 762 bytes --] On Thu, 10 Dec 2015 11:45:35 -0800, Kees Cook said: > On Thu, Dec 10, 2015 at 11:38 AM, Schaufler, Casey > That's great! Thanks for speaking up. Another area that hasn't seen > any traction yet is PAX_USERCOPY. Valdis seems to be MIA, so I'd love > to see someone else take on that chunk of work. Whoops. sorry.. I just didn't have anything in a state ready to share, and I got sidetracked by a week in the hospital (am all OK now, thankfully). Biggest problem is just taking one big 7M patch and teasing out just the USERCOPY parts, and then re-arranging it into something that upstream will be willing to take. Just lots and lots of grunt work. I don't suppose the grsecurity guys have a git repo where a lot of the heavy duty lifting is already done? :) [-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-11 17:54 ` Valdis.Kletnieks @ 2015-12-11 18:44 ` Kees Cook 0 siblings, 0 replies; 54+ messages in thread From: Kees Cook @ 2015-12-11 18:44 UTC (permalink / raw) To: kernel-hardening Cc: Schaufler, Casey, Catalin Marinas, PaX Team, Michael Ellerman, Heiko Carstens, Ralf Baechle On Fri, Dec 11, 2015 at 9:54 AM, <Valdis.Kletnieks@vt.edu> wrote: > On Thu, 10 Dec 2015 11:45:35 -0800, Kees Cook said: >> On Thu, Dec 10, 2015 at 11:38 AM, Schaufler, Casey > >> That's great! Thanks for speaking up. Another area that hasn't seen >> any traction yet is PAX_USERCOPY. Valdis seems to be MIA, so I'd love >> to see someone else take on that chunk of work. > > Whoops. sorry.. I just didn't have anything in a state ready to share, > and I got sidetracked by a week in the hospital (am all OK now, thankfully). Yikes! Glad you're okay. If other people have more time to dedicate to PAX_USERCOPY extraction, maybe you could help with testing? Or what do you think? > Biggest problem is just taking one big 7M patch and teasing out just the > USERCOPY parts, and then re-arranging it into something that upstream will > be willing to take. Just lots and lots of grunt work. Yup, that's the first step in the work. Well, first is extraction, then figuring out the best way to upstream. > I don't suppose the grsecurity guys have a git repo where a lot of the > heavy duty lifting is already done? :) AIUI, no such thing exists. :) -Kees -- Kees Cook Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 19:23 ` Kees Cook 2015-12-10 19:38 ` Schaufler, Casey @ 2015-12-12 11:40 ` Heiko Carstens 1 sibling, 0 replies; 54+ messages in thread From: Heiko Carstens @ 2015-12-12 11:40 UTC (permalink / raw) To: Kees Cook Cc: kernel-hardening, Catalin Marinas, PaX Team, Michael Ellerman, Ralf Baechle On Thu, Dec 10, 2015 at 11:23:34AM -0800, Kees Cook wrote: > On Thu, Dec 10, 2015 at 11:07 AM, Daniel Micay <danielmicay@gmail.com> wrote: > >> Yeah. PCID was Sandybridge and later? > > > > Yeah, that's right. And it defaults to the strong PCID implementation, > > but there's also a weaker but significantly faster PCID-based one. > > Is there anyone from Intel on the list? I would love to see UDEREF > ported to upstream on x86 (and the non PCID version too). No one has > stepped up to work on it yet. > > As for non-ARM and non-x86, IIRC s/390 has always had PAN, and I'd > love to update the matrix for powerpc and MIPS. > > http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage The statement for s390 is correct: we always had PAN in use. It's a hardware feature simply called "Address Spaces". The way we use it in Linux on s390 makes is impossible to access user space contents from kernel space without special instructions. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 18:42 ` Kees Cook 2015-12-10 19:07 ` Daniel Micay @ 2015-12-10 22:38 ` PaX Team 2015-12-10 23:04 ` Daniel Micay 1 sibling, 1 reply; 54+ messages in thread From: PaX Team @ 2015-12-10 22:38 UTC (permalink / raw) To: kernel-hardening, Kees Cook; +Cc: Catalin Marinas On 10 Dec 2015 at 10:42, Kees Cook wrote: > http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage > > On Thu, Dec 10, 2015 at 9:55 AM, Daniel Micay <danielmicay@gmail.com> wrote: > >> ARMv8 64-bit: ?? > > > > The worst case scenario would be doing something like the x86_64 UDEREF. > > > >> x86 pre-late-Broadwell: nothing upstream (though UDEREF in PaX exists) > > > > It's worth noting that there's the pre-PCID implementation (slow and > > vulnerable to races) uhm, what races? the per-cpu PGD exists for that reason, regardless of PCID. > > and then two choices of better implementations when > > PCID is available. You probably know that already, but it's not obvious > > to everyone else. > > Yeah. PCID was Sandybridge and later? IIRC, it is more like Westmere and later. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 22:38 ` PaX Team @ 2015-12-10 23:04 ` Daniel Micay 0 siblings, 0 replies; 54+ messages in thread From: Daniel Micay @ 2015-12-10 23:04 UTC (permalink / raw) To: kernel-hardening, Kees Cook; +Cc: Catalin Marinas [-- Attachment #1: Type: text/plain, Size: 214 bytes --] > uhm, what races? the per-cpu PGD exists for that reason, regardless of > PCID. Ah, that makes sense. So the non-strong PCID UDEREF is really just hardware acceleration for what you were already doing before. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 17:49 ` Kees Cook 2015-12-10 17:55 ` Daniel Micay @ 2015-12-10 18:42 ` Catalin Marinas 2015-12-10 18:47 ` Kees Cook 2015-12-10 23:52 ` Kees Cook 1 sibling, 2 replies; 54+ messages in thread From: Catalin Marinas @ 2015-12-10 18:42 UTC (permalink / raw) To: Kees Cook; +Cc: kernel-hardening On Thu, Dec 10, 2015 at 09:49:13AM -0800, Kees Cook wrote: > On Thu, Dec 10, 2015 at 9:14 AM, Stephen Smalley > <stephen.smalley@gmail.com> wrote: > > On Wed, Dec 9, 2015 at 7:41 PM, Kees Cook <keescook@chromium.org> wrote: > >> On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@linaro.org> wrote: > >>> On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote: > >>>> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel > >>>> too. > >>> > >>> I'll put this on my list to investigate. Sadly, it looks like there > >>> is a bit of a window of ARM CPUs where neither solution will work; > >>> Basically the pre V8.1 64-bit. > >> > >> The LPAE support for PAN emulation exists in grsecurity, if someone > >> wanted to look at how to extract it and add it to > >> CONFIG_CPU_SW_DOMAIN_PAN (or similar). > > > > Are you looking for this: > > http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2 > > > > Haven't seen any follow up on it though... > > Ah yes! Thank you! > > https://patchwork.kernel.org/patch/7250401/ > https://patchwork.kernel.org/patch/7250391/ > https://patchwork.kernel.org/patch/7250421/ > https://patchwork.kernel.org/patch/7250441/ > > Catalin, where does this stand? I haven't done any further improvements to them, nor have I received any feedback. I'll rebase them against latest kernel if anyone else is willing to test. I had a plan to run some benchmarks and see how performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing again for upstreaming but I haven't had the time. > Also, what options do ARMv8 (not ARMv8.1) devices have for PAN if > they're running 64-bit? No PAN support for ARMv8.0. It could be done similarly to the 32-bit LPAE support. > The matrix for PAN seems to be: > > ARMv7 32-bit non-LPAE: CONFIG_CPU_SW_DOMAIN_PAN > ARMv7 32-bit LPAE: Catalin's series (CPU_TTBR0_PAN) Correct. > ARMv8 32-bit: Catalin's series? ARMv8 32-bit is backwards compatible with ARMv7, so the same arm32 kernel. > ARMv8 64-bit: ?? None. > ARMv8.1: hardware PAN Correct. -- Catalin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 18:42 ` Catalin Marinas @ 2015-12-10 18:47 ` Kees Cook 2015-12-10 23:52 ` Kees Cook 1 sibling, 0 replies; 54+ messages in thread From: Kees Cook @ 2015-12-10 18:47 UTC (permalink / raw) To: Catalin Marinas; +Cc: kernel-hardening On Thu, Dec 10, 2015 at 10:42 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Thu, Dec 10, 2015 at 09:49:13AM -0800, Kees Cook wrote: >> On Thu, Dec 10, 2015 at 9:14 AM, Stephen Smalley >> <stephen.smalley@gmail.com> wrote: >> > On Wed, Dec 9, 2015 at 7:41 PM, Kees Cook <keescook@chromium.org> wrote: >> >> On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@linaro.org> wrote: >> >>> On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote: >> >>>> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel >> >>>> too. >> >>> >> >>> I'll put this on my list to investigate. Sadly, it looks like there >> >>> is a bit of a window of ARM CPUs where neither solution will work; >> >>> Basically the pre V8.1 64-bit. >> >> >> >> The LPAE support for PAN emulation exists in grsecurity, if someone >> >> wanted to look at how to extract it and add it to >> >> CONFIG_CPU_SW_DOMAIN_PAN (or similar). >> > >> > Are you looking for this: >> > http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2 >> > >> > Haven't seen any follow up on it though... >> >> Ah yes! Thank you! >> >> https://patchwork.kernel.org/patch/7250401/ >> https://patchwork.kernel.org/patch/7250391/ >> https://patchwork.kernel.org/patch/7250421/ >> https://patchwork.kernel.org/patch/7250441/ >> >> Catalin, where does this stand? > > I haven't done any further improvements to them, nor have I received any > feedback. I'll rebase them against latest kernel if anyone else is > willing to test. I had a plan to run some benchmarks and see how > performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing > again for upstreaming but I haven't had the time. Please CC this mailing list when you do. I'd like to give it a spin (and maybe other folks will too). >> Also, what options do ARMv8 (not ARMv8.1) devices have for PAN if >> they're running 64-bit? > > No PAN support for ARMv8.0. It could be done similarly to the 32-bit > LPAE support. > >> The matrix for PAN seems to be: >> >> ARMv7 32-bit non-LPAE: CONFIG_CPU_SW_DOMAIN_PAN >> ARMv7 32-bit LPAE: Catalin's series (CPU_TTBR0_PAN) > > Correct. > >> ARMv8 32-bit: Catalin's series? > > ARMv8 32-bit is backwards compatible with ARMv7, so the same arm32 > kernel. > >> ARMv8 64-bit: ?? > > None. > >> ARMv8.1: hardware PAN > > Correct. Excellent, thanks! -Kees -- Kees Cook Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 18:42 ` Catalin Marinas 2015-12-10 18:47 ` Kees Cook @ 2015-12-10 23:52 ` Kees Cook 2015-12-11 1:04 ` David Brown 2016-01-11 18:33 ` David Brown 1 sibling, 2 replies; 54+ messages in thread From: Kees Cook @ 2015-12-10 23:52 UTC (permalink / raw) To: David Brown; +Cc: kernel-hardening, Catalin Marinas On Thu, Dec 10, 2015 at 10:42 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Thu, Dec 10, 2015 at 09:49:13AM -0800, Kees Cook wrote: >> On Thu, Dec 10, 2015 at 9:14 AM, Stephen Smalley >> <stephen.smalley@gmail.com> wrote: >> > On Wed, Dec 9, 2015 at 7:41 PM, Kees Cook <keescook@chromium.org> wrote: >> >> On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@linaro.org> wrote: >> >>> On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote: >> >>>> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel >> >>>> too. >> >>> >> >>> I'll put this on my list to investigate. Sadly, it looks like there >> >>> is a bit of a window of ARM CPUs where neither solution will work; >> >>> Basically the pre V8.1 64-bit. >> >> >> >> The LPAE support for PAN emulation exists in grsecurity, if someone >> >> wanted to look at how to extract it and add it to >> >> CONFIG_CPU_SW_DOMAIN_PAN (or similar). >> > >> > Are you looking for this: >> > http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2 >> > >> > Haven't seen any follow up on it though... >> >> Ah yes! Thank you! >> >> https://patchwork.kernel.org/patch/7250401/ >> https://patchwork.kernel.org/patch/7250391/ >> https://patchwork.kernel.org/patch/7250421/ >> https://patchwork.kernel.org/patch/7250441/ >> >> Catalin, where does this stand? > > I haven't done any further improvements to them, nor have I received any > feedback. I'll rebase them against latest kernel if anyone else is > willing to test. I had a plan to run some benchmarks and see how > performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing > again for upstreaming but I haven't had the time. David, getting back to something that might good to get your help with: would you be able to test Catalin's LPAE TTBR0 PAN series on real hardware? (Are you familiar with the LKDTM tests for this[1]?) -Kees [1] http://lwn.net/Articles/663531/ specifically ACCESS_USERSPACE and EXEC_USERSPACE -- Kees Cook Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 23:52 ` Kees Cook @ 2015-12-11 1:04 ` David Brown 2016-01-11 18:33 ` David Brown 1 sibling, 0 replies; 54+ messages in thread From: David Brown @ 2015-12-11 1:04 UTC (permalink / raw) To: Kees Cook; +Cc: kernel-hardening, Catalin Marinas On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote: >David, getting back to something that might good to get your help >with: would you be able to test Catalin's LPAE TTBR0 PAN series on >real hardware? (Are you familiar with the LKDTM tests for this[1]?) I was planning on this. It's probably going to be a little while (as in January) before I have any reasonable hardware to test things on, though. I have one board I need to get working, and another is in the mail. Both, however, are A53-based, which gets all of the other configurations. I'll see if I can figure out how to get access to our test infrastructure. I am familiar with LKDTM, and it's how I was able to test PAN easily. Thanks, David ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2015-12-10 23:52 ` Kees Cook 2015-12-11 1:04 ` David Brown @ 2016-01-11 18:33 ` David Brown 2016-01-12 19:31 ` Kees Cook 1 sibling, 1 reply; 54+ messages in thread From: David Brown @ 2016-01-11 18:33 UTC (permalink / raw) To: Kees Cook; +Cc: kernel-hardening, Catalin Marinas On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote: >> I haven't done any further improvements to them, nor have I received any >> feedback. I'll rebase them against latest kernel if anyone else is >> willing to test. I had a plan to run some benchmarks and see how >> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing >> again for upstreaming but I haven't had the time. > >David, getting back to something that might good to get your help >with: would you be able to test Catalin's LPAE TTBR0 PAN series on >real hardware? (Are you familiar with the LKDTM tests for this[1]?) Sorry for the delay in getting back to you. Been both moving and taking vacation. I'd like to test this. I'm just trying to see if I can track down some hardware that'll boot LPAE. Thanks, David ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2016-01-11 18:33 ` David Brown @ 2016-01-12 19:31 ` Kees Cook 2016-01-13 11:29 ` Catalin Marinas 2016-01-13 11:31 ` Catalin Marinas 0 siblings, 2 replies; 54+ messages in thread From: Kees Cook @ 2016-01-12 19:31 UTC (permalink / raw) To: David Brown; +Cc: kernel-hardening, Catalin Marinas On Mon, Jan 11, 2016 at 10:33 AM, David Brown <david.brown@linaro.org> wrote: > On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote: > >>> I haven't done any further improvements to them, nor have I received any >>> feedback. I'll rebase them against latest kernel if anyone else is >>> willing to test. I had a plan to run some benchmarks and see how >>> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing >>> again for upstreaming but I haven't had the time. >> >> >> David, getting back to something that might good to get your help >> with: would you be able to test Catalin's LPAE TTBR0 PAN series on >> real hardware? (Are you familiar with the LKDTM tests for this[1]?) > > > Sorry for the delay in getting back to you. Been both moving and > taking vacation. > > I'd like to test this. I'm just trying to see if I can track down > some hardware that'll boot LPAE. Awesome! Thanks for the update. Catalin, did you end up figuring out if your TTBR0 stuff was correct? You'd mentioned you needed to check something about the implementation? -Kees -- Kees Cook Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2016-01-12 19:31 ` Kees Cook @ 2016-01-13 11:29 ` Catalin Marinas 2016-01-13 11:31 ` Catalin Marinas 1 sibling, 0 replies; 54+ messages in thread From: Catalin Marinas @ 2016-01-13 11:29 UTC (permalink / raw) To: Kees Cook; +Cc: David Brown, kernel-hardening + rmk On Tue, Jan 12, 2016 at 11:31:50AM -0800, Kees Cook wrote: > On Mon, Jan 11, 2016 at 10:33 AM, David Brown <david.brown@linaro.org> wrote: > > On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote: > > > >>> I haven't done any further improvements to them, nor have I received any > >>> feedback. I'll rebase them against latest kernel if anyone else is > >>> willing to test. I had a plan to run some benchmarks and see how > >>> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing > >>> again for upstreaming but I haven't had the time. > >> > >> > >> David, getting back to something that might good to get your help > >> with: would you be able to test Catalin's LPAE TTBR0 PAN series on > >> real hardware? (Are you familiar with the LKDTM tests for this[1]?) > > > > > > Sorry for the delay in getting back to you. Been both moving and > > taking vacation. > > > > I'd like to test this. I'm just trying to see if I can track down > > some hardware that'll boot LPAE. > > Awesome! Thanks for the update. > > Catalin, did you end up figuring out if your TTBR0 stuff was correct? > You'd mentioned you needed to check something about the > implementation? Unfortunately, I checked with the ARM architecture folk. While the trick is probably fine on existing hardware, the architecture allows caching of the TTBCR bits (or their effect) in the TLB. Therefore changing the TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed to have an effect until the TLBs are invalidated. CPU implementations are allowed to rely on this, so we can't safely use it in Linux. The minor side effect is that the PAN may not always work. We could invalidate the TLBs at every PAN change and take a significant performance hit. However, the more serious side effect is that TLB conflicts may happen, leading to aborts (though unlikely on existing hardware but we can't guarantee it for the future). The latter can't be avoided (only reduce) by more TLB invalidation (the proper fix would be MMU disabling). In conclusion, I'm NAK'ing my own patch ;). The alternative is to make TTBR0 point to swapper_pg_dir where there are no user mappings. The difficulty is that such patch won't fit nicely onto the existing uaccess_* macros that rmk added. It also doesn't work well with switch_mm(), we would have to defer the TTBR0 setting until returning to user space (cpu_switch_mm() should no longer be called in check_and_switch_context() as it automatically enables privileged access to user). I haven't had time to look into re-writing the patch. Hopefully sometime in February, unless someone else volunteers to take over. Question for Russell: do we have any guarantees that lowmem doesn't cross a 32-bit boundary? This would simplify the code a bit by preserving the top 32-bit of TTBR0 when changing. But looking at the sanity_check_meminfo(), I couldn't see anything that would guarantee this. Even the virt_to_phys() macro does a carry add for the top 32-bit. -- Catalin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2016-01-12 19:31 ` Kees Cook 2016-01-13 11:29 ` Catalin Marinas @ 2016-01-13 11:31 ` Catalin Marinas 2016-01-14 1:04 ` Ben Hutchings 1 sibling, 1 reply; 54+ messages in thread From: Catalin Marinas @ 2016-01-13 11:31 UTC (permalink / raw) To: Kees Cook; +Cc: David Brown, kernel-hardening, Russell King - ARM Linux + rmk (actually cc'ing him this time) On Tue, Jan 12, 2016 at 11:31:50AM -0800, Kees Cook wrote: > On Mon, Jan 11, 2016 at 10:33 AM, David Brown <david.brown@linaro.org> wrote: > > On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote: > > > >>> I haven't done any further improvements to them, nor have I received any > >>> feedback. I'll rebase them against latest kernel if anyone else is > >>> willing to test. I had a plan to run some benchmarks and see how > >>> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing > >>> again for upstreaming but I haven't had the time. > >> > >> > >> David, getting back to something that might good to get your help > >> with: would you be able to test Catalin's LPAE TTBR0 PAN series on > >> real hardware? (Are you familiar with the LKDTM tests for this[1]?) > > > > > > Sorry for the delay in getting back to you. Been both moving and > > taking vacation. > > > > I'd like to test this. I'm just trying to see if I can track down > > some hardware that'll boot LPAE. > > Awesome! Thanks for the update. > > Catalin, did you end up figuring out if your TTBR0 stuff was correct? > You'd mentioned you needed to check something about the > implementation? Unfortunately, I checked with the ARM architecture folk. While the trick is probably fine on existing hardware, the architecture allows caching of the TTBCR bits (or their effect) in the TLB. Therefore changing the TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed to have an effect until the TLBs are invalidated. CPU implementations are allowed to rely on this, so we can't safely use it in Linux. The minor side effect is that the PAN may not always work. We could invalidate the TLBs at every PAN change and take a significant performance hit. However, the more serious side effect is that TLB conflicts may happen, leading to aborts (though unlikely on existing hardware but we can't guarantee it for the future). The latter can't be avoided (only reduce) by more TLB invalidation (the proper fix would be MMU disabling). In conclusion, I'm NAK'ing my own patch ;). The alternative is to make TTBR0 point to swapper_pg_dir where there are no user mappings. The difficulty is that such patch won't fit nicely onto the existing uaccess_* macros that rmk added. It also doesn't work well with switch_mm(), we would have to defer the TTBR0 setting until returning to user space (cpu_switch_mm() should no longer be called in check_and_switch_context() as it automatically enables privileged access to user). I haven't had time to look into re-writing the patch. Hopefully sometime in February, unless someone else volunteers to take over. Question for Russell: do we have any guarantees that lowmem doesn't cross a 32-bit boundary? This would simplify the code a bit by preserving the top 32-bit of TTBR0 when changing. But looking at the sanity_check_meminfo(), I couldn't see anything that would guarantee this. Even the virt_to_phys() macro does a carry add for the top 32-bit. -- Catalin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2016-01-13 11:31 ` Catalin Marinas @ 2016-01-14 1:04 ` Ben Hutchings 2016-01-14 11:11 ` Catalin Marinas 0 siblings, 1 reply; 54+ messages in thread From: Ben Hutchings @ 2016-01-14 1:04 UTC (permalink / raw) To: Catalin Marinas Cc: Kees Cook, David Brown, Russell King - ARM Linux, kernel-hardening On Wed, 2016-01-13 at 11:31 +0000, Catalin Marinas wrote: > + rmk (actually cc'ing him this time) > > On Tue, Jan 12, 2016 at 11:31:50AM -0800, Kees Cook wrote: > > On Mon, Jan 11, 2016 at 10:33 AM, David Brown <david.brown@linaro.org> wrote: > > > On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote: > > > > > >>> I haven't done any further improvements to them, nor have I received any > > >>> feedback. I'll rebase them against latest kernel if anyone else is > > >>> willing to test. I had a plan to run some benchmarks and see how > > >>> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing > > >>> again for upstreaming but I haven't had the time. > > >> > > >> > > >> David, getting back to something that might good to get your help > > >> with: would you be able to test Catalin's LPAE TTBR0 PAN series on > > >> real hardware? (Are you familiar with the LKDTM tests for this[1]?) > > > > > > > > > Sorry for the delay in getting back to you. Been both moving and > > > taking vacation. > > > > > > I'd like to test this. I'm just trying to see if I can track down > > > some hardware that'll boot LPAE. > > > > Awesome! Thanks for the update. > > > > Catalin, did you end up figuring out if your TTBR0 stuff was correct? > > You'd mentioned you needed to check something about the > > implementation? > > Unfortunately, I checked with the ARM architecture folk. While the trick > is probably fine on existing hardware, the architecture allows caching > of the TTBCR bits (or their effect) in the TLB. Therefore changing the > TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed > to have an effect until the TLBs are invalidated. CPU implementations > are allowed to rely on this, so we can't safely use it in Linux. [...] Could you whitelist the cores where this is known to work as intended? Or is it not practical to enable/disable this PAN implementation at boot time? Ben. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [kernel-hardening] Self Introduction 2016-01-14 1:04 ` Ben Hutchings @ 2016-01-14 11:11 ` Catalin Marinas 0 siblings, 0 replies; 54+ messages in thread From: Catalin Marinas @ 2016-01-14 11:11 UTC (permalink / raw) To: Ben Hutchings Cc: Kees Cook, David Brown, Russell King - ARM Linux, kernel-hardening On Thu, Jan 14, 2016 at 01:04:38AM +0000, Ben Hutchings wrote: > On Wed, 2016-01-13 at 11:31 +0000, Catalin Marinas wrote: > > On Tue, Jan 12, 2016 at 11:31:50AM -0800, Kees Cook wrote: > > > On Mon, Jan 11, 2016 at 10:33 AM, David Brown <david.brown@linaro.org> wrote: > > > > On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote: > > > > > > > >>> I haven't done any further improvements to them, nor have I received any > > > >>> feedback. I'll rebase them against latest kernel if anyone else is > > > >>> willing to test. I had a plan to run some benchmarks and see how > > > >>> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing > > > >>> again for upstreaming but I haven't had the time. > > > >> > > > >> > > > >> David, getting back to something that might good to get your help > > > >> with: would you be able to test Catalin's LPAE TTBR0 PAN series on > > > >> real hardware? (Are you familiar with the LKDTM tests for this[1]?) > > > > > > > > > > > > Sorry for the delay in getting back to you. Been both moving and > > > > taking vacation. > > > > > > > > I'd like to test this. I'm just trying to see if I can track down > > > > some hardware that'll boot LPAE. > > > > > > Awesome! Thanks for the update. > > > > > > Catalin, did you end up figuring out if your TTBR0 stuff was correct? > > > You'd mentioned you needed to check something about the > > > implementation? > > > > Unfortunately, I checked with the ARM architecture folk. While the trick > > is probably fine on existing hardware, the architecture allows caching > > of the TTBCR bits (or their effect) in the TLB. Therefore changing the > > TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed > > to have an effect until the TLBs are invalidated. CPU implementations > > are allowed to rely on this, so we can't safely use it in Linux. > [...] > > Could you whitelist the cores where this is known to work as intended? Even this information is hard to get accurately. You would have to ask the micro-architects (and not all are ARM Ltd) about the details as these are not usually publicly available. So in Linux we aim as much as possible to stick to the architecture specification rather than individual implementations, with a few exceptions for features documented in the CPU TRM (or errata docs). > Or is it not practical to enable/disable this PAN implementation at boot > time? Some boot-time code patching may do but we should rather do it properly by using a reserved TTBR0. -- Catalin ^ permalink raw reply [flat|nested] 54+ messages in thread
end of thread, other threads:[~2016-10-18 21:21 UTC | newest] Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-10-09 12:34 [kernel-hardening] self introduction Colin Vidal 2016-10-09 14:04 ` David Windsor 2016-10-09 19:09 ` Colin Vidal 2016-10-09 19:37 ` Jann Horn 2016-10-10 6:02 ` Reshetova, Elena 2016-10-10 16:01 ` Colin Vidal 2016-10-10 17:01 ` Reshetova, Elena 2016-10-10 21:05 ` Kees Cook 2016-10-12 3:19 ` Gengjia Chen 2016-10-12 22:31 ` Kees Cook 2016-10-13 11:14 ` Gengjia Chen 2016-10-13 18:50 ` Kees Cook 2016-10-17 11:57 ` Gengjia Chen 2016-10-17 20:15 ` Kees Cook 2016-10-18 11:52 ` Gengjia Chen 2016-10-18 21:21 ` Kees Cook 2016-10-12 8:25 ` Colin Vidal 2016-10-12 22:35 ` Kees Cook 2016-10-13 13:54 ` Reshetova, Elena 2016-10-13 18:53 ` Kees Cook 2016-10-13 19:26 ` Hans Liljestrand 2016-10-10 20:57 ` Kees Cook 2016-10-12 8:27 ` Colin Vidal 2016-10-12 22:40 ` Kees Cook 2016-10-14 18:32 ` Andy Lutomirski -- strict thread matches above, loose matches on Subject: below -- 2015-12-09 17:21 [kernel-hardening] Self Introduction David Brown 2015-12-09 22:19 ` Kees Cook 2015-12-10 0:00 ` David Brown 2015-12-10 0:14 ` Kees Cook 2015-12-10 0:26 ` David Brown 2015-12-10 0:41 ` Kees Cook 2015-12-10 17:14 ` Stephen Smalley 2015-12-10 17:49 ` Kees Cook 2015-12-10 17:55 ` Daniel Micay 2015-12-10 18:42 ` Kees Cook 2015-12-10 19:07 ` Daniel Micay 2015-12-10 19:23 ` Kees Cook 2015-12-10 19:38 ` Schaufler, Casey 2015-12-10 19:45 ` Kees Cook 2015-12-11 17:54 ` Valdis.Kletnieks 2015-12-11 18:44 ` Kees Cook 2015-12-12 11:40 ` Heiko Carstens 2015-12-10 22:38 ` PaX Team 2015-12-10 23:04 ` Daniel Micay 2015-12-10 18:42 ` Catalin Marinas 2015-12-10 18:47 ` Kees Cook 2015-12-10 23:52 ` Kees Cook 2015-12-11 1:04 ` David Brown 2016-01-11 18:33 ` David Brown 2016-01-12 19:31 ` Kees Cook 2016-01-13 11:29 ` Catalin Marinas 2016-01-13 11:31 ` Catalin Marinas 2016-01-14 1:04 ` Ben Hutchings 2016-01-14 11:11 ` Catalin Marinas
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.