[PATCH 0/5] Config Enforcer

[Nigel Cunningham]

Hi Andy.

Andy Whitcroft wrote:
> 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.

Thanks. Would you consider documenting that somewhere (perhaps in the
error message?) for packaging newbies like me who might otherwise get stuck?

>>> 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.

Ah, makes perfect sense now! Thanks!

Nigel