On Wednesday 27 February 2013, Stephen Boyd wrote:
> On 02/27/13 12:32, Arnd Bergmann wrote:
> > 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.
> 
> A lot of arches seem to not want to enable it because false positives
> are everywhere. It really depends on how good the compiler is at doing
> constant propagation and dead code removal.

Ok, I see. Of course they would not need to enable that option, but
I guess if we know that enabling it doesn't work, there is no point
in providing the option.

> >>  
> >> +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.
> 
> We still need it to link the kernel because the callers of the function
> don't have ifdefs. Also, all arches were doing an obj-y before, so this
> is equivalent.

Ok.

        Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to