On Wednesday 27 February 2013, Stephen Boyd wrote: > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 28be08c..ae80518 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -1292,6 +1292,24 @@ config LATENCYTOP > Enable this option if you want to use the LatencyTOP tool > to find out which userspace is blocking on what kernel operations. > > +config ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS > + bool > + > +config DEBUG_STRICT_USER_COPY_CHECKS > + bool "Strict user copy size checks" > + depends on ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS > + depends on DEBUG_KERNEL && !TRACE_BRANCH_PROFILING > + help > + Enabling this option turns a certain set of sanity checks for user > + copy operations into compile time failures. > + > + The copy_from_user() etc checks are there to help test if there > + are sufficient security checks on the length argument of > + the copy operation, by having gcc prove that the argument is > + within bounds. > + > + If unsure, say N. > + Is there actually any architecture dependency left after this? I wonder if we actually need the ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS symbol, or could just show the DEBUG_STRICT_USER_COPY_CHECKS option on all architectures. It's fine to do your patch as a first step though, which would not change the behavior. > diff --git a/lib/Makefile b/lib/Makefile > index 32f4455..59fabd0 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -15,6 +15,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ > is_single_threaded.o plist.o decompress.o kobject_uevent.o \ > earlycpio.o percpu-refcount.o > > +lib-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o > lib-$(CONFIG_MMU) += ioremap.o > lib-$(CONFIG_SMP) += cpumask.o > I think this should instead be +lib-$(DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o No point building that file if we are not using it. Other than that, Acked-by: Arnd Bergmann <arnd@xxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
