On Fri, 15 Sep 2006 14:58:06 -0700 [email protected] wrote:
>
> The patch titled
>
> allow /proc/config.gz to be built as a module
>
> has been added to the -mm tree. Its filename is
>
> allow-proc-configgz-to-be-built-as-a-module.patch
>
> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> out what to do about this
>
> ------------------------------------------------------
> Subject: allow /proc/config.gz to be built as a module
> From: Ross Biro <[email protected]>
When/where was this patch submitted? I seem to have missed it
(or it was so long ago that I forgot about it).
> The driver for /proc/config.gz consumes rather a lot of memory and it is in
> fact possible to build it as a module.
Can you try to quantify "rather a lot of memory"?
> In some ways this is a bit risky, because the .config which is used for
> compiling kernel/configs.c isn't necessarily the same as the .config which was
> used to build vmlinux.
and that's why a module wasn't allowed.
It's not worth the risk IMO.
> But OTOH the potential memory savings are decent, and it'd be fairly dumb to
> build your configs.o with a different .config.
>
> Signed-off-by: Andrew Morton <[email protected]>
> Cc: "Randy.Dunlap" <[email protected]>
> Cc: Sam Ravnborg <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> init/Kconfig | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN init/Kconfig~allow-proc-configgz-to-be-built-as-a-module init/Kconfig
> --- a/init/Kconfig~allow-proc-configgz-to-be-built-as-a-module
> +++ a/init/Kconfig
> @@ -241,7 +241,7 @@ config AUDITSYSCALL
> ensure that INOTIFY is configured.
>
> config IKCONFIG
> - bool "Kernel .config support"
> + tristate "Kernel .config support"
> ---help---
> This option enables the complete Linux kernel ".config" file
> contents to be saved in the kernel. It provides documentation
> _
---
~Randy
On 9/15/06, Randy.Dunlap <[email protected]> wrote:
> > In some ways this is a bit risky, because the .config which is used for
> > compiling kernel/configs.c isn't necessarily the same as the .config which was
> > used to build vmlinux.
>
> and that's why a module wasn't allowed.
> It's not worth the risk IMO.
It's not worth the risk for distributions or if you are tyring to
support people building their own kernels. But if you are in an
environment where you have enough control that you are not worried the
kernel and the module being built at separate times or with different
configs, then it's a nice compromise between convenience and memory
use.
Ross
On Fri, 15 Sep 2006 19:04:30 -0400 rossb wrote:
> On 9/15/06, Randy.Dunlap <[email protected]> wrote:
> > > In some ways this is a bit risky, because the .config which is used for
> > > compiling kernel/configs.c isn't necessarily the same as the .config which was
> > > used to build vmlinux.
> >
> > and that's why a module wasn't allowed.
> > It's not worth the risk IMO.
>
> It's not worth the risk for distributions or if you are tyring to
> support people building their own kernels. But if you are in an
> environment where you have enough control that you are not worried the
> kernel and the module being built at separate times or with different
> configs, then it's a nice compromise between convenience and memory
> use.
One can have any number of private kernel patches, too.
Or put another way: Just because it can be done doesn't mean
that it should be done.
And I'm still interested in the other questions that were not answered.
---
~Randy
On Fri, 15 Sep 2006 15:47:52 -0700
"Randy.Dunlap" <[email protected]> wrote:
> On Fri, 15 Sep 2006 14:58:06 -0700 [email protected] wrote:
>
> >
> > The patch titled
> >
> > allow /proc/config.gz to be built as a module
> >
> > has been added to the -mm tree. Its filename is
> >
> > allow-proc-configgz-to-be-built-as-a-module.patch
> >
> > See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> > out what to do about this
> >
> > ------------------------------------------------------
> > Subject: allow /proc/config.gz to be built as a module
> > From: Ross Biro <[email protected]>
>
> When/where was this patch submitted? I seem to have missed it
> (or it was so long ago that I forgot about it).
Ross wrote it today and I stole it.
> > The driver for /proc/config.gz consumes rather a lot of memory and it is in
> > fact possible to build it as a module.
>
> Can you try to quantify "rather a lot of memory"?
I confused it with /proc/kallsyms. No, /proc/config.gz doesn't use much
memory.
> > In some ways this is a bit risky, because the .config which is used for
> > compiling kernel/configs.c isn't necessarily the same as the .config which was
> > used to build vmlinux.
>
> and that's why a module wasn't allowed.
> It's not worth the risk IMO.
I'd want to be hearing from distro people on that - I'd expect that the
.config which is used to build configs.ko would not differ from that which
is used to build vmlinux.
Plus it's configurable.
Am not particularly fussed either way, really. It would be better if
treading on /proc/config.gz were to cause a modprobe of the driver for it,
but procfs doesn't work that way.
On Fri, 15 Sep 2006 16:41:35 -0700 Andrew Morton wrote:
> On Fri, 15 Sep 2006 15:47:52 -0700
> "Randy.Dunlap" <[email protected]> wrote:
>
> > On Fri, 15 Sep 2006 14:58:06 -0700 [email protected] wrote:
> >
> > >
> > > The patch titled
> > >
> > > allow /proc/config.gz to be built as a module
> > >
> > > has been added to the -mm tree. Its filename is
> > >
> > > allow-proc-configgz-to-be-built-as-a-module.patch
> > >
> > > See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> > > out what to do about this
> > >
> > > ------------------------------------------------------
> > > Subject: allow /proc/config.gz to be built as a module
> > > From: Ross Biro <[email protected]>
> >
> > When/where was this patch submitted? I seem to have missed it
> > (or it was so long ago that I forgot about it).
>
> Ross wrote it today and I stole it.
>
> > > The driver for /proc/config.gz consumes rather a lot of memory and it is in
> > > fact possible to build it as a module.
> >
> > Can you try to quantify "rather a lot of memory"?
>
> I confused it with /proc/kallsyms. No, /proc/config.gz doesn't use much
> memory.
>
> > > In some ways this is a bit risky, because the .config which is used for
> > > compiling kernel/configs.c isn't necessarily the same as the .config which was
> > > used to build vmlinux.
> >
> > and that's why a module wasn't allowed.
> > It's not worth the risk IMO.
>
> I'd want to be hearing from distro people on that - I'd expect that the
> .config which is used to build configs.ko would not differ from that which
> is used to build vmlinux.
>
> Plus it's configurable.
>
> Am not particularly fussed either way, really. It would be better if
> treading on /proc/config.gz were to cause a modprobe of the driver for it,
> but procfs doesn't work that way.
I'm not terribly fussed either way either. We have just about
hit my quota/limit for discussion of this patch. :)
If memory is an issue, one should just build the .config file
into the kernel image and use scripts/extract-ikconfig to
read it back (IMHO).
---
~Randy
On Fri, Sep 15, 2006 at 04:41:35PM -0700, Andrew Morton wrote:
> I'd want to be hearing from distro people on that - I'd expect that the
> .config which is used to build configs.ko would not differ from that which
> is used to build vmlinux.
What's the point though? If you can find configs.ko, you can have
install_modules copy config.gz there, no? And you also have it in
/boot/config-`uname -r`. /proc/config.gz has a trust value only
because it is linked into the image. Having it as a module gives the
exact save level of trustyness that the perfectly well working
solution of copying in /boot had before.
In other terms, if you allow configs.ko, you can't trust the contents
of /proc/config.gz anymore and /proc/config.gz lost all its interest
where it comes to debugging.
OG.
On Fri, Sep 15, 2006 at 04:41:35PM -0700, Andrew Morton wrote:
> On Fri, 15 Sep 2006 15:47:52 -0700
> "Randy.Dunlap" <[email protected]> wrote:
>
> > On Fri, 15 Sep 2006 14:58:06 -0700 [email protected] wrote:
> >
> > >
> > > The patch titled
> > >
> > > allow /proc/config.gz to be built as a module
> > >
> > > has been added to the -mm tree. Its filename is
> > >
> > > allow-proc-configgz-to-be-built-as-a-module.patch
> > >
> > > See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> > > out what to do about this
> > >
> > > ------------------------------------------------------
> > > Subject: allow /proc/config.gz to be built as a module
> > > From: Ross Biro <[email protected]>
> >
> > When/where was this patch submitted? I seem to have missed it
> > (or it was so long ago that I forgot about it).
>
> Ross wrote it today and I stole it.
>
> > > The driver for /proc/config.gz consumes rather a lot of memory and it is in
> > > fact possible to build it as a module.
> >
> > Can you try to quantify "rather a lot of memory"?
>
> I confused it with /proc/kallsyms. No, /proc/config.gz doesn't use much
> memory.
>
> > > In some ways this is a bit risky, because the .config which is used for
> > > compiling kernel/configs.c isn't necessarily the same as the .config which was
> > > used to build vmlinux.
> >
> > and that's why a module wasn't allowed.
> > It's not worth the risk IMO.
>
> I'd want to be hearing from distro people on that - I'd expect that the
> .config which is used to build configs.ko would not differ from that which
> is used to build vmlinux.
>...
If you are concerned about memory usage, and you are anyway building a
kernel package for a distribution, the reasonable solution is
place the .config in /boot/config-...
That's also what I know from the Debian kernel packages.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
> > In some ways this is a bit risky, because the .config which is used for
> > compiling kernel/configs.c isn't necessarily the same as the .config which was
> > used to build vmlinux.
>
> and that's why a module wasn't allowed.
> It's not worth the risk IMO.
Hi,
I agree with Randy here; this does not make sense. Either you're ok with
a small risk that the config doesn't match the kernel (and you
use /boot/config-<version> as put there by make install and by all
distributions) or you want a 100.00% guarantee and use /proc/config.gz.
Making the later unreliable (even if that is a CHOICE a user of it
cannot find this out, in the config.gz he sees the CONFIG option for
this may say =y even if the actual config has it as module!. So users of
this are now in the cold).
One hack we could do is make an md5sum or similar of the config and
stick that somewhere which is built in and always available (proc or
sysfs or something like that); that can be used to validate any config
basically to be "correct matching". In fact we could even make it
(optionally) part of the VERMAGIC to avoid any kind of mismatch at all.
Greetings,
Arjan van de Ven
On 9/16/06, Arjan van de Ven <[email protected]> wrote:
> > > In some ways this is a bit risky, because the .config which is used for
> > > compiling kernel/configs.c isn't necessarily the same as the .config which was
> > > used to build vmlinux.
> >
> > and that's why a module wasn't allowed.
> > It's not worth the risk IMO.
The problem is, the patch is basically s/bool/tristate/ so you can't
really count on /proc/config.gz anyway. It's a lot like security
through obscurity.
> One hack we could do is make an md5sum or similar of the config and
> stick that somewhere which is built in and always available (proc or
> sysfs or something like that); that can be used to validate any config
> basically to be "correct matching". In fact we could even make it
> (optionally) part of the VERMAGIC to avoid any kind of mismatch at all.
Not a bad idea, but I think you want to be able to edit your config
before compiling modules. In particular, you might want to turn
something from off to module.
How about we embed the md5sum of the config in the kernel, make it
available via /proc or /sysfs and then have /proc/config.gz return an
error in the event the md5sum doesn't match?
Ross
On Sat, Sep 16, 2006 at 08:48:26PM -0400, rossb wrote:
> On 9/16/06, Arjan van de Ven <[email protected]> wrote:
> >> > In some ways this is a bit risky, because the .config which is used for
> >> > compiling kernel/configs.c isn't necessarily the same as the .config
> >which was
> >> > used to build vmlinux.
> >>
> >> and that's why a module wasn't allowed.
> >> It's not worth the risk IMO.
>
> The problem is, the patch is basically s/bool/tristate/ so you can't
> really count on /proc/config.gz anyway. It's a lot like security
> through obscurity.
>
> >One hack we could do is make an md5sum or similar of the config and
> >stick that somewhere which is built in and always available (proc or
> >sysfs or something like that); that can be used to validate any config
> >basically to be "correct matching". In fact we could even make it
> >(optionally) part of the VERMAGIC to avoid any kind of mismatch at all.
>
> Not a bad idea, but I think you want to be able to edit your config
> before compiling modules. In particular, you might want to turn
> something from off to module.
>
> How about we embed the md5sum of the config in the kernel, make it
> available via /proc or /sysfs and then have /proc/config.gz return an
> error in the event the md5sum doesn't match?
IMHO this all sounds like overdesigning something that is only a quick
hack that is sometimes handy:
If you don't want to waste kernel memory, set CONFIG_IKCONFIG=n.
If you are building a kernel for a distribution kernel, set
CONFIG_IKCONFIG=n and place the .config in /boot/config-*
(or a similar place).
We don't need a sophisticated well-defined semantics for the case when
the .config changes due to additional modules selected or other special
cases.
> Ross
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, 15 Sep 2006 16:41:35 -0700 Andrew Morton wrote:
> On Fri, 15 Sep 2006 15:47:52 -0700
> "Randy.Dunlap" <[email protected]> wrote:
>
> > On Fri, 15 Sep 2006 14:58:06 -0700 [email protected] wrote:
> >
> > >
> > > The patch titled
> > >
> > > allow /proc/config.gz to be built as a module
> > >
> > > has been added to the -mm tree. Its filename is
> > >
> > > allow-proc-configgz-to-be-built-as-a-module.patch
> > >
> > > See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> > > out what to do about this
> > >
> > > ------------------------------------------------------
> > > Subject: allow /proc/config.gz to be built as a module
> > > From: Ross Biro <[email protected]>
> >
> > When/where was this patch submitted? I seem to have missed it
> > (or it was so long ago that I forgot about it).
>
> Ross wrote it today and I stole it.
>
> > > The driver for /proc/config.gz consumes rather a lot of memory and it is in
> > > fact possible to build it as a module.
> >
> > Can you try to quantify "rather a lot of memory"?
>
> I confused it with /proc/kallsyms. No, /proc/config.gz doesn't use much
> memory.
>
> > > In some ways this is a bit risky, because the .config which is used for
> > > compiling kernel/configs.c isn't necessarily the same as the .config which was
> > > used to build vmlinux.
> >
> > and that's why a module wasn't allowed.
> > It's not worth the risk IMO.
*************************************************
> I'd want to be hearing from distro people on that - I'd expect that the
*************************************************
> .config which is used to build configs.ko would not differ from that which
> is used to build vmlinux.
Can any of the distro people chime in here? Andrew merged this
patch to mainline today. Several people had disagreed with merging
it, but now Andrew says we need more discussion (if or) in order to
revert it.
> Plus it's configurable.
>
> Am not particularly fussed either way, really. It would be better if
> treading on /proc/config.gz were to cause a modprobe of the driver for it,
> but procfs doesn't work that way.
---
~Randy
On Sun, Oct 01, Randy Dunlap wrote:
> Can any of the distro people chime in here? Andrew merged this
> patch to mainline today. Several people had disagreed with merging
> it, but now Andrew says we need more discussion (if or) in order to
> revert it.
Everyone who wants this to be =m can do so.
The rest will likely leave it =y.