On Fri, Jun 03, 2016 at 02:26:54PM -0700, Kees Cook wrote: > On Fri, Jun 3, 2016 at 11:51 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Jun 03, 2016 at 11:40:24AM -0700, Kees Cook wrote: > >> Guided by grsecurity's analogous __read_only markings in arch/arm, > >> this applies several uses of __ro_after_init to structures that are > >> only updated during __init. > >> > >> Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> > >> --- > >> arch/arm/kernel/cpuidle.c | 2 +- > >> arch/arm/kernel/setup.c | 10 +++++----- > >> arch/arm/kernel/smp.c | 2 +- > >> arch/arm/lib/delay.c | 2 +- > >> arch/arm/mm/mmu.c | 9 ++------- > >> arch/x86/mm/ioremap.c | 3 +-- > > > > I don't think this x86 file is an arm-specific one :) > > Hah, whooops. :) > > > That minor nit aside, these patches are a great step forward, are you > > going to take them and work to push them upstream, or do you want/need > > others to do this? > > I'll collect more like these and carry a tree for -next and push them for v4.8. Sounds good! Is there any "problem" with applying these markings to code that could be built as a module? I'm thinking of lots of buses and drivers that have structures like this, but can be a module or not, depending on the configuration selected. It would be nice to get the "benefit" of protection if the code is built into the kernel image. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
