Date: Mon, 30 Jan 2017 12:02:27 -0800 From: Kees Cook <keescook@...omium.org> To: Jessica Frazelle <me@...sfraz.com> Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: Introduction On Fri, Jan 27, 2017 at 11:14 AM, Jessica Frazelle <me@...sfraz.com> wrote: > Cool! Have already started looking into it! Super excited :D > > On Thu, Jan 26, 2017 at 1:42 PM Kees Cook <keescook@...omium.org> wrote: >> >> On Wed, Jan 25, 2017 at 8:12 PM, Jessica Frazelle <me@...sfraz.com> wrote: >> > Honestly I'm open to working on whatever no one else wants too :) >> >> You said the magic words! ;) Looking at the TODO, I'll pick this >> semi-randomly: >> >> - expand use of __ro_after_init, especially in arch/arm64 >> >> It'd be nice to look through arch/arm64 to find anything that is close >> to be able to be declared as const, but can't due to some post-boot >> but pre-init changes. This is needs some manual examination currently, >> but you can look at other uses of __ro_after_init in arch/x86 and >> arch/arm. Of course, there's no reason to limit yourself to arch/arm64 >> if you find similar things in the core kernel code too. I had someone point out that the IRQ subsystem has a lot of ops-type structures that could be either const or __ro_after_init, for example msi_domain_ops. That might be another area to look at. -Kees -- Kees Cook Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.