Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Kernel (http://www.linux-archive.org/debian-kernel/)
-   -   modpost: add option to allow external modules to avoid taint (http://www.linux-archive.org/debian-kernel/610133-modpost-add-option-allow-external-modules-avoid-taint.html)

"John W. Linville" 12-14-2011 03:20 PM

modpost: add option to allow external modules to avoid taint
 
In some cases, it might be desirable to package a module from an
external source tree alongside the base kernel. In those cases, it
might also be desirable to not have those modules tainting the kernel.

This patch provides a mechanism for an external module build to declare
itself as an "integrated build". Such a module is then treated the same
as an intree module.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Any thoughts on this? I'm thinking of adding this to Fedora kernels,
where I have been working to integrate the compat-wireless package as
part of the base kernel RPM.

scripts/Makefile.modpost | 1 +
scripts/mod/modpost.c | 10 ++++++++--
2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index 08dce14..160c6fb 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -81,6 +81,7 @@ modpost = scripts/mod/modpost
$(if $(KBUILD_EXTMOD),-o $(modulesymfile))
$(if $(CONFIG_DEBUG_SECTION_MISMATCH),,-S)
$(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w)
+ $(if $(INTEGRATED_BUILD),-B)
$(if $(cross_build),-c)

quiet_cmd_modpost = MODPOST $(words $(filter-out vmlinux FORCE, $^)) modules
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 2bd594e..5d077f9 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -43,6 +43,9 @@ static int warn_unresolved = 0;
static int sec_mismatch_count = 0;
static int sec_mismatch_verbose = 1;

+/* Is this a module being built as part of an integrated package? */
+static int integrated_build = 0;
+
enum export {
export_plain, export_unused, export_gpl,
export_unused_gpl, export_gpl_future, export_unknown
@@ -1851,7 +1854,7 @@ static void add_header(struct buffer *b, struct module *mod)

static void add_intree_flag(struct buffer *b, int is_intree)
{
- if (is_intree)
+ if (is_intree || integrated_build)
buf_printf(b, "
MODULE_INFO(intree, "Y");
");
}

@@ -2101,7 +2104,7 @@ int main(int argc, char **argv)
struct ext_sym_list *extsym_iter;
struct ext_sym_list *extsym_start = NULL;

- while ((opt = getopt(argc, argv, "i:I:e:cmsSo:awM:K:")) != -1) {
+ while ((opt = getopt(argc, argv, "i:I:e:cmsSo:awM:K:B")) != -1) {
switch (opt) {
case 'i':
kernel_read = optarg;
@@ -2139,6 +2142,9 @@ int main(int argc, char **argv)
case 'w':
warn_unresolved = 1;
break;
+ case 'B':
+ integrated_build = 1;
+ break;
default:
exit(1);
}
--
1.7.4.4


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1323879603-2961-1-git-send-email-linville@tuxdriver.com">http://lists.debian.org/1323879603-2961-1-git-send-email-linville@tuxdriver.com

Ben Hutchings 12-14-2011 03:52 PM

modpost: add option to allow external modules to avoid taint
 
On Wed, 2011-12-14 at 11:20 -0500, John W. Linville wrote:
> In some cases, it might be desirable to package a module from an
> external source tree alongside the base kernel. In those cases, it
> might also be desirable to not have those modules tainting the kernel.
>
> This patch provides a mechanism for an external module build to declare
> itself as an "integrated build". Such a module is then treated the same
> as an intree module.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> Any thoughts on this? I'm thinking of adding this to Fedora kernels,
> where I have been working to integrate the compat-wireless package as
> part of the base kernel RPM.
[...]

If you're integrating it then why can't you *really* build it in-tree?

Ben.

--
Ben Hutchings
Computers are not intelligent. They only think they are.

"John W. Linville" 12-14-2011 04:39 PM

modpost: add option to allow external modules to avoid taint
 
On Wed, Dec 14, 2011 at 04:52:00PM +0000, Ben Hutchings wrote:
> On Wed, 2011-12-14 at 11:20 -0500, John W. Linville wrote:
> > In some cases, it might be desirable to package a module from an
> > external source tree alongside the base kernel. In those cases, it
> > might also be desirable to not have those modules tainting the kernel.
> >
> > This patch provides a mechanism for an external module build to declare
> > itself as an "integrated build". Such a module is then treated the same
> > as an intree module.
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > Any thoughts on this? I'm thinking of adding this to Fedora kernels,
> > where I have been working to integrate the compat-wireless package as
> > part of the base kernel RPM.
> [...]
>
> If you're integrating it then why can't you *really* build it in-tree?

Well, of course, I could. But it would be a _huge_ waste of my time
doing so. The compat-wireless package is already sitting there,
complete with all the necessary backporting infrastructure. It's all
fat and juicy, waiting to be used. Wasting time replicating that
just doesn't make any sense to my mind.

John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111214173922.GA2607@tuxdriver.com">http://lists.debian.org/20111214173922.GA2607@tuxdriver.com

Rusty Russell 12-16-2011 02:56 AM

modpost: add option to allow external modules to avoid taint
 
On Wed, 14 Dec 2011 11:20:03 -0500, "John W. Linville" <linville@tuxdriver.com> wrote:
> In some cases, it might be desirable to package a module from an
> external source tree alongside the base kernel. In those cases, it
> might also be desirable to not have those modules tainting the kernel.
>
> This patch provides a mechanism for an external module build to declare
> itself as an "integrated build". Such a module is then treated the same
> as an intree module.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> Any thoughts on this? I'm thinking of adding this to Fedora kernels,
> where I have been working to integrate the compat-wireless package as
> part of the base kernel RPM.

I don't think the feature is useful it it's too easy to disable.
Experience has shown this with license tags.

We really want to indicate "out-of-support" which is only a 1:1
mapping to out-of-tree for upstream kernels.

How does Debian handle this?

Perhaps it makes more sense to use the proposed module signing stuff in
a simplified mode to mark built-with-kernel modules (eg. just put the
sha of known modules inside the kernel).

I think we should revert this change, meanwhile, and figure out what to
do.

Cheers,
Rusty.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mxatp3ty.fsf@rustcorp.com.au">http://lists.debian.org/87mxatp3ty.fsf@rustcorp.com.au

Ben Hutchings 12-16-2011 03:39 AM

modpost: add option to allow external modules to avoid taint
 
On Fri, 2011-12-16 at 14:26 +1030, Rusty Russell wrote:
> On Wed, 14 Dec 2011 11:20:03 -0500, "John W. Linville" <linville@tuxdriver.com> wrote:
> > In some cases, it might be desirable to package a module from an
> > external source tree alongside the base kernel. In those cases, it
> > might also be desirable to not have those modules tainting the kernel.
> >
> > This patch provides a mechanism for an external module build to declare
> > itself as an "integrated build". Such a module is then treated the same
> > as an intree module.
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > Any thoughts on this? I'm thinking of adding this to Fedora kernels,
> > where I have been working to integrate the compat-wireless package as
> > part of the base kernel RPM.
>
> I don't think the feature is useful it it's too easy to disable.
> Experience has shown this with license tags.
>
> We really want to indicate "out-of-support" which is only a 1:1
> mapping to out-of-tree for upstream kernels.

Who are 'we' in this instance?

> How does Debian handle this?

All the modules in Debian's kernel binary packages are built in-tree.
Backported modules are patched in as necessary.

Debian includes many packages of OOT modules, but those are supported by
their respective maintainers and not the kernel team. So for the kernel
team, the 'O' flag does not mean 'unsupported' but may indicate that
another maintainer should handle the bug (or it may also be irrelevant
to the bug).

> Perhaps it makes more sense to use the proposed module signing stuff in
> a simplified mode to mark built-with-kernel modules (eg. just put the
> sha of known modules inside the kernel).

Unlike commercial distributions, no-one is paying Debian for support
contracts and no-one can game the system by hiding OOT modules. So it's
probably not worthwhile for us to use module signing at all.

However, supposing we did go down this route, I would guess that
checksums for ~3000 modules take up more space than the signature
checking code. Instead, we could perhaps generate a key pair during
build, include the public key in the kernel and then discard the private
key. (But getting entropy would likely be a problem for the key
generation.)

Ben.

> I think we should revert this change, meanwhile, and figure out what to
> do.
>
> Cheers,
> Rusty.
>

--
Ben Hutchings
Computers are not intelligent. They only think they are.

Rusty Russell 12-19-2011 04:45 AM

modpost: add option to allow external modules to avoid taint
 
On Fri, 16 Dec 2011 04:39:49 +0000, Ben Hutchings <ben@decadent.org.uk> wrote:
Non-text part: multipart/signed
> On Fri, 2011-12-16 at 14:26 +1030, Rusty Russell wrote:
> > On Wed, 14 Dec 2011 11:20:03 -0500, "John W. Linville" <linville@tuxdriver.com> wrote:
> > We really want to indicate "out-of-support" which is only a 1:1
> > mapping to out-of-tree for upstream kernels.
>
> Who are 'we' in this instance?

Whoever turns this flag on. I was using friendly, inclusive language :)

> > How does Debian handle this?
>
> All the modules in Debian's kernel binary packages are built in-tree.
> Backported modules are patched in as necessary.
>
> Debian includes many packages of OOT modules, but those are supported by
> their respective maintainers and not the kernel team. So for the kernel
> team, the 'O' flag does not mean 'unsupported' but may indicate that
> another maintainer should handle the bug (or it may also be irrelevant
> to the bug).

So, in your case, the kernel team want to know what's outside their
support, so this flag works well for you.

As John pointed out, it's a bit useless for them. We could enable it
with a config option, or they could ignore it, since they're going to
module-signing route anyway.

> > Perhaps it makes more sense to use the proposed module signing stuff in
> > a simplified mode to mark built-with-kernel modules (eg. just put the
> > sha of known modules inside the kernel).
>
> Unlike commercial distributions, no-one is paying Debian for support
> contracts and no-one can game the system by hiding OOT modules. So it's
> probably not worthwhile for us to use module signing at all.
>
> However, supposing we did go down this route, I would guess that
> checksums for ~3000 modules take up more space than the signature
> checking code. Instead, we could perhaps generate a key pair during
> build, include the public key in the kernel and then discard the private
> key. (But getting entropy would likely be a problem for the key
> generation.)

Agreed, 60k is a bit expensive for this minor feature.

Thanks,
Rusty.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k45tnmgm.fsf@rustcorp.com.au">http://lists.debian.org/87k45tnmgm.fsf@rustcorp.com.au


All times are GMT. The time now is 03:42 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.