FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 12-10-2009, 04:41 PM
Andy Whitcroft
 
Default Config Enforcer

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
are not set the build will fail.

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:

value CONFIG_SYN_COOKIES y
exists CONFIG_SYN_COOKIES

The rest of the assertions check environmentatal factors such as architecture
and flavour names:

arch armel
flavour generic

These may be combined using and/or and parentheses, the resulting formular
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.

-apw

Andy Whitcroft (5):
UBUNTU: config-check -- add a configuration enforcer
UBUNTU: [Config] Enable CONFIG_SYN_COOKIES for versatile
UBUNTU: [Config] Enable CONFIG_SECURITY_SMACK for ports
UBUNTU: [Config] Enable CONFIG_SECURITY_FILE_CAPABILITIES for ports
UBUNTU: [Config] Disable CONFIG_COMPAT_BRK for ports

debian.master/config/amd64/config.common.amd64 | 1 -
debian.master/config/armel/config.common.armel | 1 -
debian.master/config/config.common.ports | 7 +-
debian.master/config/config.common.ubuntu | 1 +
debian.master/config/enforce | 25 ++++
debian.master/config/i386/config.common.i386 | 1 -
debian.master/config/lpia/config.common.lpia | 1 -
debian.master/rules.d/2-binary-arch.mk | 2 +-
debian.master/rules.d/4-checks.mk | 8 +
debian.master/scripts/config-check | 168 ++++++++++++++++++++++++
debian.master/scripts/misc/kernelconfig | 25 ++++-
11 files changed, 231 insertions(+), 9 deletions(-)
create mode 100644 debian.master/config/enforce
create mode 100755 debian.master/scripts/config-check


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-10-2009, 07:55 PM
Nigel Cunningham
 
Default Config Enforcer

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

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

Regards,

Nigel

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-11-2009, 11:08 AM
Andy Whitcroft
 
Default Config Enforcer

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-11-2009, 12:59 PM
Tim Gardner
 
Default Config Enforcer

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
> are not set the build will fail.
>
> 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:
>
> value CONFIG_SYN_COOKIES y
> exists CONFIG_SYN_COOKIES
>
> The rest of the assertions check environmentatal factors such as architecture
> and flavour names:
>
> arch armel
> flavour generic
>
> These may be combined using and/or and parentheses, the resulting formular
> 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.
>
> -apw
>
> Andy Whitcroft (5):
> UBUNTU: config-check -- add a configuration enforcer
> UBUNTU: [Config] Enable CONFIG_SYN_COOKIES for versatile
> UBUNTU: [Config] Enable CONFIG_SECURITY_SMACK for ports
> UBUNTU: [Config] Enable CONFIG_SECURITY_FILE_CAPABILITIES for ports
> UBUNTU: [Config] Disable CONFIG_COMPAT_BRK for ports
>
> debian.master/config/amd64/config.common.amd64 | 1 -
> debian.master/config/armel/config.common.armel | 1 -
> debian.master/config/config.common.ports | 7 +-
> debian.master/config/config.common.ubuntu | 1 +
> debian.master/config/enforce | 25 ++++
> debian.master/config/i386/config.common.i386 | 1 -
> debian.master/config/lpia/config.common.lpia | 1 -
> debian.master/rules.d/2-binary-arch.mk | 2 +-
> debian.master/rules.d/4-checks.mk | 8 +
> debian.master/scripts/config-check | 168 ++++++++++++++++++++++++
> debian.master/scripts/misc/kernelconfig | 25 ++++-
> 11 files changed, 231 insertions(+), 9 deletions(-)
> create mode 100644 debian.master/config/enforce
> create mode 100755 debian.master/scripts/config-check
>
>

I think this is a great idea.

rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-11-2009, 08:22 PM
Nigel Cunningham
 
Default Config Enforcer

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 05:37 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org