Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1452925 > unrolled thread

[PULL] modules-next

Started byRusty Russell <rusty@rustcorp.com.au>
First post2016-08-01 03:10 +0200
Last post2016-08-04 03:00 +0200
Articles 5 — 3 participants

Back to article view | Back to linux.kernel

Contents

  [PULL] modules-next Rusty Russell <rusty@rustcorp.com.au> - 2016-08-01 03:10 +0200
    Re: [PULL] modules-next Linus Torvalds <torvalds@linux-foundation.org> - 2016-08-01 03:50 +0200
      Re: [PULL] modules-next Ben Hutchings <ben@decadent.org.uk> - 2016-08-01 23:00 +0200
      Re: [PULL] modules-next Rusty Russell <rusty@rustcorp.com.au> - 2016-08-02 06:40 +0200
        Re: [PULL] modules-next Rusty Russell <rusty@rustcorp.com.au> - 2016-08-04 03:00 +0200

#1452925 — [PULL] modules-next

FromRusty Russell <rusty@rustcorp.com.au>
Date2016-08-01 03:10 +0200
Subject[PULL] modules-next
Message-ID<s19TX-7LM-3@gated-at.bofh.it>
The following changes since commit 3fc9d690936fb2e20e180710965ba2cc3a0881f8:

  Merge branch 'for-4.8/drivers' of git://git.kernel.dk/linux-block (2016-07-26 15:37:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git tags/modules-next-for-linus

for you to fetch changes up to 8acc0026b0f3046c9929d1f33cf840cd190d1b12:

  extable.h: add stddef.h so "NULL" definition is not implicit (2016-07-28 15:23:47 +0930)

----------------------------------------------------------------
Only interesting thing here is Jessica's patch to add ro_after_init support
to modules.  The rest are all trivia.

Cheers,
Rusty.

----------------------------------------------------------------
Ben Hutchings (3):
      module: Invalidate signatures on force-loaded modules
      Documentation/module-signing.txt: Note need for version info if reusing a key
      module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled

Jessica Yu (1):
      modules: add ro_after_init support

Jiri Kosina (1):
      module: fix noreturn attribute for __module_put_and_exit()

Libor Pechacek (1):
      module: Issue warnings when tainting kernel

Paul Gortmaker (2):
      exceptions: fork exception table content from module.h into extable.h
      extable.h: add stddef.h so "NULL" definition is not implicit

Prarit Bhargava (1):
      modules: Add kernel parameter to blacklist modules

Rusty Russell (2):
      module: fix redundant test.
      jump_label: disable preemption around __module_text_address().

Steven Rostedt (1):
      module: Do a WARN_ON_ONCE() for assert module mutex not held

 Documentation/kernel-parameters.txt |   3 +
 Documentation/module-signing.txt    |   6 ++
 include/linux/extable.h             |  32 ++++++++++
 include/linux/module.h              |  37 +++--------
 include/uapi/linux/elf.h            |   1 +
 init/Kconfig                        |   1 +
 kernel/jump_label.c                 |   5 +-
 kernel/livepatch/core.c             |   2 +-
 kernel/module.c                     | 121 +++++++++++++++++++++++++++++-------
 9 files changed, 156 insertions(+), 52 deletions(-)
 create mode 100644 include/linux/extable.h

[toc] | [next] | [standalone]

#1452930

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2016-08-01 03:50 +0200
Message-ID<s1awF-7Zx-3@gated-at.bofh.it>
In reply to#1452925
So this feels wrong to me, can you guys please explain:

On Sun, Jul 31, 2016 at 9:02 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> Ben Hutchings (3):
>       module: Invalidate signatures on force-loaded modules
>       module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled

forcing a load and SIG_FORCE are entirely independent issues, afaik. I
think requiring signed modules is just a good idea. But that doesn't
necessarily mean that you don't have a signed module that is signed
with a key you trust, but you still want to force-load it for the
wrong kernel version (ie maybe you have a binary-only module from your
IT department (and your IT department is evil,but at least they sign
it to show that the module is trust-worthy as coming from them, even
if they have some dubious behavior), but you did some kernel updates
that still allow the module to work but the version doesn't match any
more).

Am I missing something? What's the connection between
MODULE_FORCE_LOAD and MODULE_SIG_FORCE? Because it smells like they
are independent and that the above changes are very very dubious.

I didn't actually pull the tree, I just reacted to the pull request itself.

             Linus

[toc] | [prev] | [next] | [standalone]

#1453470

FromBen Hutchings <ben@decadent.org.uk>
Date2016-08-01 23:00 +0200
Message-ID<s1stz-32g-11@gated-at.bofh.it>
In reply to#1452930

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2016-07-31 at 21:44 -0400, Linus Torvalds wrote:
> So this feels wrong to me, can you guys please explain:
> 
> On Sun, Jul 31, 2016 at 9:02 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > 
> > Ben Hutchings (3):
> >       module: Invalidate signatures on force-loaded modules
> >       module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled
> 
> forcing a load and SIG_FORCE are entirely independent issues, afaik. I
> think requiring signed modules is just a good idea. But that doesn't
> necessarily mean that you don't have a signed module that is signed
> with a key you trust, but you still want to force-load it for the
> wrong kernel version (ie maybe you have a binary-only module from your
> IT department (and your IT department is evil,but at least they sign
> it to show that the module is trust-worthy as coming from them, even
> if they have some dubious behavior), but you did some kernel updates
> that still allow the module to work but the version doesn't match any
> more).

We discussed this before and I thought you were happy with this
version.  If the use case you describe is at all common, it could
perhaps be handled by having a tool that patches the version
information and re-signs the module with a different trusted key.

> Am I missing something? What's the connection between
> MODULE_FORCE_LOAD and MODULE_SIG_FORCE? Because it smells like they
> are independent and that the above changes are very very dubious.

As I understand it:
- module signature enforcement means that root is not trusted to load
  arbitrary code into the kernel; instead the code has to be approved
  by one of the signing key holders
- force-loading a module means "I promise that this module is ABI
  compatible, even though it doesn't appear to be"

No-one signs that promise, and if it's false, the ABI differences could
mean that an otherwise benign module would compromise the kernel.  So
as I see it, the kernel should not trust a force-loaded signed module
any more than an unsigned module.

If you still think that module signature enforcement is compatible with
force-loading, I would like to know what you consider the purpose of
enforcement to be.

Ben.

> I didn't actually pull the tree, I just reacted to the pull request itself.
> 
>              Linus
-- 

Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.

[toc] | [prev] | [next] | [standalone]

#1453585

FromRusty Russell <rusty@rustcorp.com.au>
Date2016-08-02 06:40 +0200
Message-ID<s1zEJ-7Ue-11@gated-at.bofh.it>
In reply to#1452930
Linus Torvalds <torvalds@linux-foundation.org> writes:
> So this feels wrong to me, can you guys please explain:
>
> On Sun, Jul 31, 2016 at 9:02 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>
>> Ben Hutchings (3):
>>       module: Invalidate signatures on force-loaded modules
>>       module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled
>
> forcing a load and SIG_FORCE are entirely independent issues, afaik. I
> think requiring signed modules is just a good idea. But that doesn't
> necessarily mean that you don't have a signed module that is signed
> with a key you trust, but you still want to force-load it for the
> wrong kernel version (ie maybe you have a binary-only module from your
> IT department (and your IT department is evil,but at least they sign
> it to show that the module is trust-worthy as coming from them, even
> if they have some dubious behavior), but you did some kernel updates
> that still allow the module to work but the version doesn't match any
> more).
>
> Am I missing something? What's the connection between
> MODULE_FORCE_LOAD and MODULE_SIG_FORCE? Because it smells like they
> are independent and that the above changes are very very dubious.
>
> I didn't actually pull the tree, I just reacted to the pull request itself.

Well, MODULE_FORCE_LOAD is really "I am a doing crazy shit", and
MODULE_SIG_FORCE is "Don't let me do crazy shit".

You have to contrive pretty hard to get a situation where the
combination makes sense, so I tend to let Ben worry about the module
signing stuff.

I can pull them out of modules-next if you'd prefer.

Cheers,
Rusty.

[toc] | [prev] | [next] | [standalone]

#1456095

FromRusty Russell <rusty@rustcorp.com.au>
Date2016-08-04 03:00 +0200
Message-ID<s2faW-1z3-11@gated-at.bofh.it>
In reply to#1453585
Rusty Russell <rusty@rustcorp.com.au> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> So this feels wrong to me, can you guys please explain:
...
>> I didn't actually pull the tree, I just reacted to the pull request itself.
...
> I can pull them out of modules-next if you'd prefer.

OK, removed that patch.  Here's the update pullreq:

The following changes since commit 3fc9d690936fb2e20e180710965ba2cc3a0881f8:

  Merge branch 'for-4.8/drivers' of git://git.kernel.dk/linux-block (2016-07-26 15:37:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git tags/modules-next-for-linus

for you to fetch changes up to 49aadcf1b6f4240751921dad52e86c760d70a5f1:

  extable.h: add stddef.h so "NULL" definition is not implicit (2016-08-04 10:16:56 +0930)

----------------------------------------------------------------
Removed the MODULE_SIG_FORCE-means-no-MODULE_FORCE_LOAD patch.

Only interesting thing here is Jessica's patch to add ro_after_init support
to modules.  The rest are all trivia.

Cheers,
Rusty.

----------------------------------------------------------------
Ben Hutchings (2):
      module: Invalidate signatures on force-loaded modules
      Documentation/module-signing.txt: Note need for version info if reusing a key

Jessica Yu (1):
      modules: add ro_after_init support

Jiri Kosina (1):
      module: fix noreturn attribute for __module_put_and_exit()

Libor Pechacek (1):
      module: Issue warnings when tainting kernel

Paul Gortmaker (2):
      exceptions: fork exception table content from module.h into extable.h
      extable.h: add stddef.h so "NULL" definition is not implicit

Prarit Bhargava (1):
      modules: Add kernel parameter to blacklist modules

Rusty Russell (2):
      module: fix redundant test.
      jump_label: disable preemption around __module_text_address().

Steven Rostedt (1):
      module: Do a WARN_ON_ONCE() for assert module mutex not held

 Documentation/kernel-parameters.txt |   3 +
 Documentation/module-signing.txt    |   6 ++
 include/linux/extable.h             |  32 ++++++++++
 include/linux/module.h              |  37 +++--------
 include/uapi/linux/elf.h            |   1 +
 kernel/jump_label.c                 |   5 +-
 kernel/livepatch/core.c             |   2 +-
 kernel/module.c                     | 121 +++++++++++++++++++++++++++++-------
 8 files changed, 155 insertions(+), 52 deletions(-)
 create mode 100644 include/linux/extable.h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web