[PATCH 0/5] Config Enforcer

[Andy Whitcroft]

On Fri, Dec 11, 2009 at 07:55:39AM +1100, Nigel Cunningham wrote:
> Hi.
> 
> Andy Whitcroft wrote:
> > It was proposed that we add a config enforcer build check to the kernel
> > build process.  This checker reviews the configuration at build time to
> > confirm that specific options have specific values.  This allows us to
> > confirm and enforce the values of cirtain values.  Where those values
> 
> s/cirtain/certain/
> 
> > are not set the build will fail.
> 
> Is there a way for the builder to disable the checks? (They might want
> non-standard options occasionally).

Yes, there is a skipconfig=true option analogous to those for abi and
module checks.

> > This patch set adds a new check phase 'prepare-checks' which is triggered
> > when the prepare phase is running.  It then adds a new config-prepare-check
> > which looks at the newly generated config and checks the specified options.
> > 
> > The config option checks are specified debian.master/configs/enforce.
> > This contains a predicate based language.  Each line represents one
> > check, if the the line evaluates false then the check is deemed failed.
> > Each line is made up of one or more predicates which are assertions.
> > The primary assertions relate to the existance and values of parameters:
> 
> s/existance/existence/
> 
> > 
> >   value CONFIG_SYN_COOKIES y
> >   exists CONFIG_SYN_COOKIES
> > 
> > The rest of the assertions check environmentatal factors such as architecture
> 
> s/environmentatal/environmental/
> 
> > and flavour names:
> > 
> >   arch armel
> >   flavour generic
> > 
> > These may be combined using and/or and parentheses, the resulting formular
> 
> s/forumular/forula/
> 
> > is then executed and if the overall result is true the line is ok.  This allows us to ensure options are set to different values based on architecture:
> > 
> >   (( arch armel | arch sparc ) & value CONFIG_DEFAULT_MMAP_MIN_ADDR 32768 ) | \
> >        ( value CONFIG_DEFAULT_MMAP_MIN_ADDR 65536)
> > 
> > Following this email are 5 patches.  The first brings the new checker
> > and some basic rules.  The remainder fix up the various violations.
> 
> What's the point? Is it an attempt to pick up bugs in vanilla and/or
> patches that mess up configuration, or typos in Ubuntu's own changes, or
> something else again? ("It was proposed" doesn't say why this patch
> series is needed).

The point is to ensure the configuration items which we have specifically
decided have particular values in the Ubuntu configuraitons cannot vary
from those without being detected.  As a side bonus we have somewhere in
the source tree to document why they are set as they are.

For example we had a setting for CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR,
upstream renamed this variable and we lost the protections it provided.

With this system in place the checker would detect that the value was no
longer present erroring during configuration updates and builds should it
not be corrected.  Thus preventing a kernel without the option entering
the archive.  In this particular case we would have detected the loss
of this parameter at the first rebase and switched to the new value
without exposure.

-apw