On Fri, Jun 3, 2016 at 2:54 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > 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. There's no operational problem, it will just currently offer no protections, and once the module side of things HAS been fixed, if any got marked incorrectly, it'll be discovered then instead of when they were added. -Kees -- Kees Cook Chrome OS & Brillo Security -- 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
