LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: [PATCH 0/6] MODSIGN: Kernel module signing
       [not found]     ` <7OTGJ-1G5-23@gated-at.bofh.it>
@ 2007-02-16 15:38       ` Bodo Eggert
  0 siblings, 0 replies; 30+ messages in thread
From: Bodo Eggert @ 2007-02-16 15:38 UTC (permalink / raw)
  To: Roman Zippel, David Howells, torvalds, akpm, herbert.xu,
	linux-kernel, davej, arjan, linux-crypto

Roman Zippel <zippel@linux-m68k.org> wrote:
> On Thu, 15 Feb 2007, David Howells wrote:

>> > This is really the weak point - it offers no advantage over an equivalent
>> > implementation in user space (e.g. in the module tools). So why has to be
>> > done in the kernel?
>> 
>> Because the init_module() system call is the common point of module
>> submission
>> to the kernel, not any particular userspace program.  There is no requirement
>> for userspace to load a module by invoking a module tools program or library,
>> and so userspace can bypass the checks entirely by just calling
>> init_module().
>> Assume for a moment that you can't trust userspace...  (Obviously, if you
>> can't trust the kernel then you're already stuffed.)
> 
> All the security stuff in the kernel should provide the necessary means to
> restrict this system call.

Hardening a system should include deeper layers, too.

>> It is possible to protect /dev/mem and /dev/kmem or make them unavailable and
>> it is possible to protect the kernel's memory whilst it is running (provided
>> you don't have nommu or broken hardware and you don't let userspace concoct
>> any DMA request it likes) which mostly closes those other vectors I
>> mentioned.
>> This isn't something I intended to look at with this patch.  Those are
>> separate holes.
> 
> Exactly and as long as there are these holes, these patches are only
> kernel bloat.

Off cause there are other ways to expose the kernel, but they can be plugged,
too, one by one. You wouldn't leave your door open just because your window
is open, while leaving the window open because the door is open.

> The simple verification can also be done in userspace and

You may verify in userspace, but you can't use the result.

OTOH, having 1000 lines of code to verify a module _is_ bloat for this task.
Remove a 0 and it should be plenty (not counting the help text).

> module signing offers no real security.

It offers security against a class of attacks.

> What real value do these patches provide, that can't be reached via other
> means?

It provides an extra layer of security: If an exploit allows execution of
insmod(userstring), it can't compromise kernel internals.

> Who else than distributions would be interested in this?

How large is the userbase _not_ using a distribution? And are they unable to
unselect [X] Signes modules support?

> Pretty
> much any use you initially mentioned can be done in simpler ways, e.g.
> anyone afraid of modules simply disables module loading completely.

That would work if there was no need for modules. Unfortunately some people
are doomed with external modules, or not experienced enough to customize
their system. Those could benefit from a sysctl(?) saying "unsigned_modules
= taint|disallow".
-- 
Whenever you have plenty of ammo, you never miss. Whenever you are low on
ammo, you can't hit the broad side of a barn.

Friß, Spammer: 5usmqnrkze@xFzMz.7eggert.dyndns.org

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-16 20:21   ` Dave Jones
@ 2007-02-16 20:27     ` Arjan van de Ven
  0 siblings, 0 replies; 30+ messages in thread
From: Arjan van de Ven @ 2007-02-16 20:27 UTC (permalink / raw)
  To: Dave Jones
  Cc: Pavel Machek, David Howells, torvalds, akpm, herbert.xu,
	linux-kernel, linux-crypto


> 
> The restricted dev/mem patches we've had in Fedora for a while
> do the right thing, but they're a bit crufty (in part due to
> drivers/char/mem.c being a bit of a mess before we even start
> patching it).  I've had "clean these up for upstream" on my
> todo for a while. I might get around to it one of these days.


the real thing is that /dev/mem is too many things for too many people.
Fundamentally it has 3 components
1) ram-but-not-kernel data: basically BIOS datastructures
2) kernel visible ram: user/kernel data, this has all the nasty cache
coherency issues. This is also a "debug only" use, and "rootkit only"
sometimes ;) 
3) MMIO space: this really should not be used anymore, sysfs provides a
MUCH better interface and it also breaks if you have enforcing IOMMU's
in the system... it can't really work since the kernel doesn't get told
which device is being accessed

unless we split this up (well the third is split already) it's going to
remain a big mess.

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15 22:13 ` Pavel Machek
@ 2007-02-16 20:21   ` Dave Jones
  2007-02-16 20:27     ` Arjan van de Ven
  0 siblings, 1 reply; 30+ messages in thread
From: Dave Jones @ 2007-02-16 20:21 UTC (permalink / raw)
  To: Pavel Machek
  Cc: David Howells, torvalds, akpm, herbert.xu, linux-kernel, arjan,
	linux-crypto

On Thu, Feb 15, 2007 at 10:13:04PM +0000, Pavel Machek wrote:
 > Hi!
 > 
 > > Now, this is not a complete solution by any means: the core kernel is not
 > > protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
 > > controls) one relatively simple attack vector.
 > 
 > Could we fix the /dev/*mem holes, first? They are already used by
 > malicious modules (aka rootkits...).  Or can selinux already provide
 > /dev/*mem protection with no way for admin to turn it off?

There are some valid uses for peeking through /dev/mem. Things like
dmidecode for example.  So you don't want to disable it completely
in a lot of cases, but have fine-grained access to specific parts
of the file.  I'm not sure SELinux can do this. Maybe the MLS stuff
helps here (though I'm far from an expert on this, so I could be
talking out of my rear).

The restricted dev/mem patches we've had in Fedora for a while
do the right thing, but they're a bit crufty (in part due to
drivers/char/mem.c being a bit of a mess before we even start
patching it).  I've had "clean these up for upstream" on my
todo for a while. I might get around to it one of these days.

		Dave

-- 
http://www.codemonkey.org.uk

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15 22:12             ` Andreas Gruenbacher
@ 2007-02-16  0:15               ` Olaf Kirch
  0 siblings, 0 replies; 30+ messages in thread
From: Olaf Kirch @ 2007-02-16  0:15 UTC (permalink / raw)
  To: Andreas Gruenbacher
  Cc: Valdis.Kletnieks, Dave Jones, Andrew Morton, David Howells,
	torvalds, herbert.xu, linux-kernel, arjan, linux-crypto

On Thursday 15 February 2007 12:34, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 14 Feb 2007 22:14:53 PST, Andreas Gruenbacher said:
> > I agree, that's really what should happen. We solve this by marking
> > modules as supported, partner supported, or unsupported, but in an
> > "insecure" way, so partners and users could try to fake the support
> > status of a module and/or remove status flags from Oopses, and
> > cryptography wouldn't save us.
>
> Where cryptography *can* save you is that a partner or user can't fake a
> 'Suse Supported' signature without access to the Suse private key.

The user has control over the running kernel, and given enough time
and clue, can circumvent any protection mechanism the vendor comes
up with. And that's a good thing IMO, unless you believe in "trusted
computing" and all those Bigbrotherisms some agencies want to put
in your machines.

So the user is running a system in some state that may or may not
resemble what the vendor shipped. When the machine crashes, the
user is free to munge the oops until it looks like a valid one.

Someone mentioned in this context that you can sign the oops - but to
do that you need a private key. And the whole point of this exercise is
that the user does not have access to that key.

So as far as support is concerned, you're back in square one.
You cannot tell a "genuine" oops produced on a supported kernel
from a doctored one produced on Joe Doe's Garage Kernel.

Olaf
-- 
Olaf Kirch        |  Anyone who has had to work with X.509 has probably
okir@lst.de       |  experienced what can best be described as
------------------+  ISO water torture. -- Peter Gutmann

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-14 19:09 David Howells
                   ` (5 preceding siblings ...)
  2007-02-15 21:03 ` Adrian Bunk
@ 2007-02-15 22:13 ` Pavel Machek
  2007-02-16 20:21   ` Dave Jones
  6 siblings, 1 reply; 30+ messages in thread
From: Pavel Machek @ 2007-02-15 22:13 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, herbert.xu, linux-kernel, davej, arjan, linux-crypto

Hi!

> Now, this is not a complete solution by any means: the core kernel is not
> protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
> controls) one relatively simple attack vector.

Could we fix the /dev/*mem holes, first? They are already used by
malicious modules (aka rootkits...).  Or can selinux already provide
/dev/*mem protection with no way for admin to turn it off?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15 21:32       ` Adrian Bunk
@ 2007-02-15 22:12         ` Valdis.Kletnieks
  0 siblings, 0 replies; 30+ messages in thread
From: Valdis.Kletnieks @ 2007-02-15 22:12 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Dave Jones, Andrew Morton, David Howells, torvalds, herbert.xu,
	linux-kernel, arjan, linux-crypto

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

On Thu, 15 Feb 2007 22:32:40 +0100, Adrian Bunk said:
> There are different opinions whether the "complete source code" of the 
> GPLv2 includes in such cases public keys, making it questionable whether 
> your example will survive at court in all jurisdictions.

It's no less shaky than the whole EXPORT_SYMBOL_GPL-as-enforcement crock. :)

> E.g. remember that gpl-violations.org has already successfully enforced 
> the publication of public keys for "firmware only loads signed kernels" 
> cases by threatening companies to otherwise take legal actions in 
> Germany.

A court order for the publication of *public* keys? :)

I think you meant "private keys" in both paragraphs above.  And it's probably
a non-issue the way Red Hat implemented it - they included a document on
"How to generate your own public/private key pair", which invokes commands that
create a bitstring that you can then use to sign the entire applicable part
of the kernel tree.  The fact that it's not the *same* bitstring as they used
is (IMHO) legally about as relevant as the fact that they compiled the tree
with one release of GCC, included instructions on how to compile it, and I
don't get a bitwise identical binary if I compile it with a different GCC
release.

Yes, you're still screwed if you only build *part* of the kernel tree and
expect it to work - modules you sign won't load into their kernel, and vice
versa.  But that's the same problem as the old 2.4 "You didn't do a make clean
between rebuilds and you bugged out because different parts of the tree were
built with different GCC releases".  As distributed, you *can* build a working
kernel from the pieces and instructions provided.



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15 20:34           ` Valdis.Kletnieks
@ 2007-02-15 22:12             ` Andreas Gruenbacher
  2007-02-16  0:15               ` Olaf Kirch
  0 siblings, 1 reply; 30+ messages in thread
From: Andreas Gruenbacher @ 2007-02-15 22:12 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: Dave Jones, Andrew Morton, David Howells, torvalds, herbert.xu,
	linux-kernel, arjan, linux-crypto

On Thursday 15 February 2007 12:34, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 14 Feb 2007 22:14:53 PST, Andreas Gruenbacher said:
> > I agree, that's really what should happen. We solve this by marking
> > modules as supported, partner supported, or unsupported, but in an
> > "insecure" way, so partners and users could try to fake the support
> > status of a module and/or remove status flags from Oopses, and
> > cryptography wouldn't save us.
>
> Where cryptography *can* save you is that a partner or user can't fake a
> 'Suse Supported' signature without access to the Suse private key.

No question about that. We actually already get this from rpm signatures. What 
would module signatures buy us? The kernel could then reliably determine that 
an unsigned module was loaded. But people could still fake their Oopses, or 
overwite the flags which indicate that a module's signature didn't match, so 
we still wouldn't reliably get at that information.

Andreas

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15  6:14         ` Andreas Gruenbacher
  2007-02-15  6:22           ` Dave Jones
  2007-02-15 20:34           ` Valdis.Kletnieks
@ 2007-02-15 22:10           ` Pavel Machek
  2 siblings, 0 replies; 30+ messages in thread
From: Pavel Machek @ 2007-02-15 22:10 UTC (permalink / raw)
  To: Andreas Gruenbacher
  Cc: Dave Jones, Andrew Morton, David Howells, torvalds, herbert.xu,
	linux-kernel, arjan, linux-crypto

Hi!

> > well, the situation for external modules is no worse than usual.
> > They still work, they just aren't signed. Which from a distributor point
> > of view, is actually a nice thing, as they stick out like a sore thumb
> > in oops reports with (U) markers :)
> 
> I agree, that's really what should happen. We solve this by marking modules as 
> supported, partner supported, or unsupported, but in an "insecure" way, so 
> partners and users could try to fake the support status of a module and/or 
> remove status flags from Oopses, and cryptography wouldn't save us. We could 
> try to sign Oopses which I guess you guys are doing. This whole issue hasn't 

I do not think any ammount of crypto can determine that I loaded
unsupported module, then edited oops. (TPM hw module may be able to do that, not
sure).

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15 20:55     ` Valdis.Kletnieks
@ 2007-02-15 21:32       ` Adrian Bunk
  2007-02-15 22:12         ` Valdis.Kletnieks
  0 siblings, 1 reply; 30+ messages in thread
From: Adrian Bunk @ 2007-02-15 21:32 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: Dave Jones, Andrew Morton, David Howells, torvalds, herbert.xu,
	linux-kernel, arjan, linux-crypto

On Thu, Feb 15, 2007 at 03:55:41PM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 14 Feb 2007 23:13:45 EST, Dave Jones said:
> > One argument in its favour is aparently Red Hat isn't the only vendor
> > with something like this.  I've not investigated it, but I hear rumours
> > that suse has something similar.  Having everyone using the same code
> > would be a win for obvious reasons.
> 
> Another argument in its favor is that it actually allows the kernel to
> implement *real* checking of module licenses and trumps all the proposals
> to deal with MODULE_LICENSE("GPL\0Haha!").  A vendor (or user) that wants
> to be *sure* that only *really really* GPL modules are loaded can simply
> refuse to load unsigned modules - and then refuse to sign a module until
> after they had themselves visited the source's website, verified that the
> source code was available under GPL, and so on.
> 
> Remember - the GPL is about the availability of the source.  And at modprobe
> time, the source isn't available.  So you're left with two options:
> 
> 1) Trust the binary to not lie to you about its license.
> 2) Ask a trusted 3rd party (usually, the person/distro that built the kernel)
> whether they've verified the claim that it's really GPL.

There are different opinions whether the "complete source code" of the 
GPLv2 includes in such cases public keys, making it questionable whether 
your example will survive at court in all jurisdictions.

E.g. remember that gpl-violations.org has already successfully enforced 
the publication of public keys for "firmware only loads signed kernels" 
cases by threatening companies to otherwise take legal actions in 
Germany.

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


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-14 19:40 ` David Howells
  2007-02-14 21:32   ` Michael Halcrow
  2007-02-14 21:59   ` David Howells
@ 2007-02-15 21:31   ` Indan Zupancic
  2 siblings, 0 replies; 30+ messages in thread
From: Indan Zupancic @ 2007-02-15 21:31 UTC (permalink / raw)
  To: David Howells
  Cc: Linus Torvalds, akpm, herbert.xu, linux-kernel, davej, arjan,
	linux-crypto

Hello,

On Wed, February 14, 2007 20:40, David Howells wrote:
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> >  (1) A cut-down MPI library derived from GPG with error handling added.
>>
>> Do we really need to add this?
>
> I presume you mean the MPI library specifically?  If so, then yes.  It's
> necessary to do DSA signature verification (or RSA for that matter).
>
>> Wouldn't it be much nicer to just teach people to use one of the existing
>> signature things that we need for _other_ cases anyway, and already have
>> merged?
>
> Existing signature things?  I know not of such beasts, nor can I see them
> offhand.

The question is if using DSA/RSA is the right choice for something like this.
I think that the symmetrically encrypted hash output as signature would provide
the same amount of security. The only additional requirement is that the key
can't be read by userspace. But if they can reach the kernel binary, they can
modify it too. Same for the bootloader, where you'd want the key and initial
checking anyway. Else this whole thing could be done in user space as Roman
Zippel said...

The ELF section stuff seems like unnecessary bloat too. Can't you use/extend
modinfo, or kernel symbols?

With the above changes the code should shrink to only a few hundred new lines
of code, instead of thousands, and signature checking will be much faster too.

Greetings,

Indan



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-14 19:09 David Howells
                   ` (4 preceding siblings ...)
  2007-02-15 17:32 ` David Howells
@ 2007-02-15 21:03 ` Adrian Bunk
  2007-02-15 22:13 ` Pavel Machek
  6 siblings, 0 replies; 30+ messages in thread
From: Adrian Bunk @ 2007-02-15 21:03 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, herbert.xu, linux-kernel, davej, arjan, linux-crypto

On Wed, Feb 14, 2007 at 07:09:38PM +0000, David Howells wrote:
>...
> There are several reasons why these patches are useful, amongst which are:
>...
>  (4) to allow other support providers to do likewise, or at least to _detect_
>      the fact that unsupported modules are loaded;
> 
>  (5) to allow the detection of modules replaced by a second-order distro or a
>      preloaded Linux purveyor.
>...

Who might have rebuilt the whole kernel using a new signature.

Or a bug reporter might have edited out the parts containing the 
information that unsupported code was loaded.

Or the unsupported module itself might have removed all traces of having 
been loaded from the kernel.

For printing nvidia(U), you could simply add some marker similar to 
MODULE_LICENSE() that gets added to supported modules during "official" 
builds and gets checked when loading a module.

That's 10k LOC less and the same level of security...

> David

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


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing 
  2007-02-15 20:01     ` David Lang
@ 2007-02-15 21:01       ` Roman Zippel
  0 siblings, 0 replies; 30+ messages in thread
From: Roman Zippel @ 2007-02-15 21:01 UTC (permalink / raw)
  To: David Lang
  Cc: David Howells, torvalds, akpm, herbert.xu, linux-kernel, davej,
	arjan, linux-crypto

Hi,

On Thu, 15 Feb 2007, David Lang wrote:

> this issue, and these holes keep comeing up in discussions, why can't these
> holes be closed? I seem to remember seeing patches that would remove /dev/kmem
> being sent to the list, but they weren't accepted into the kernel (and I seem
> to remember people being against the concept of removeing them, not against
> techincal details of the patches. but this was many years ago)

1. It depends on the ratio of added code and its usefulness. I must assume 
the first patch didn't even make it to the kernel due to its size, so I 
think it's not unreasonable to explore the alternatives.
2. There are many ways to load an unauthorized module, thus you have to 
prevent any modification of the kernel not just in memory but also on 
disk.

bye, Roman

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15  4:13   ` Dave Jones
  2007-02-15  5:35     ` Andreas Gruenbacher
@ 2007-02-15 20:55     ` Valdis.Kletnieks
  2007-02-15 21:32       ` Adrian Bunk
  1 sibling, 1 reply; 30+ messages in thread
From: Valdis.Kletnieks @ 2007-02-15 20:55 UTC (permalink / raw)
  To: Dave Jones
  Cc: Andrew Morton, David Howells, torvalds, herbert.xu, linux-kernel,
	arjan, linux-crypto

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

On Wed, 14 Feb 2007 23:13:45 EST, Dave Jones said:
> One argument in its favour is aparently Red Hat isn't the only vendor
> with something like this.  I've not investigated it, but I hear rumours
> that suse has something similar.  Having everyone using the same code
> would be a win for obvious reasons.

Another argument in its favor is that it actually allows the kernel to
implement *real* checking of module licenses and trumps all the proposals
to deal with MODULE_LICENSE("GPL\0Haha!").  A vendor (or user) that wants
to be *sure* that only *really really* GPL modules are loaded can simply
refuse to load unsigned modules - and then refuse to sign a module until
after they had themselves visited the source's website, verified that the
source code was available under GPL, and so on.

Remember - the GPL is about the availability of the source.  And at modprobe
time, the source isn't available.  So you're left with two options:

1) Trust the binary to not lie to you about its license.
2) Ask a trusted 3rd party (usually, the person/distro that built the kernel)
whether they've verified the claim that it's really GPL.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15  6:14         ` Andreas Gruenbacher
  2007-02-15  6:22           ` Dave Jones
@ 2007-02-15 20:34           ` Valdis.Kletnieks
  2007-02-15 22:12             ` Andreas Gruenbacher
  2007-02-15 22:10           ` Pavel Machek
  2 siblings, 1 reply; 30+ messages in thread
From: Valdis.Kletnieks @ 2007-02-15 20:34 UTC (permalink / raw)
  To: Andreas Gruenbacher
  Cc: Dave Jones, Andrew Morton, David Howells, torvalds, herbert.xu,
	linux-kernel, arjan, linux-crypto

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

On Wed, 14 Feb 2007 22:14:53 PST, Andreas Gruenbacher said:
> I agree, that's really what should happen. We solve this by marking modules as
> supported, partner supported, or unsupported, but in an "insecure" way, so
> partners and users could try to fake the support status of a module and/or
> remove status flags from Oopses, and cryptography wouldn't save us.

Where cryptography *can* save you is that a partner or user can't fake a
'Suse Supported' signature without access to the Suse private key.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing 
  2007-02-15 18:33   ` Roman Zippel
@ 2007-02-15 20:01     ` David Lang
  2007-02-15 21:01       ` Roman Zippel
  0 siblings, 1 reply; 30+ messages in thread
From: David Lang @ 2007-02-15 20:01 UTC (permalink / raw)
  To: Roman Zippel
  Cc: David Howells, torvalds, akpm, herbert.xu, linux-kernel, davej,
	arjan, linux-crypto

On Thu, 15 Feb 2007, Roman Zippel wrote:

> On Thu, 15 Feb 2007, David Howells wrote:
>
>> It is possible to protect /dev/mem and /dev/kmem or make them unavailable and
>> it is possible to protect the kernel's memory whilst it is running (provided
>> you don't have nommu or broken hardware and you don't let userspace concoct any
>> DMA request it likes) which mostly closes those other vectors I mentioned.
>> This isn't something I intended to look at with this patch.  Those are separate
>> holes.
>
> Exactly and as long as there are these holes, these patches are only
> kernel bloat. The simple verification can also be done in userspace and
> module signing offers no real security.
> What real value do these patches provide, that can't be reached via other
> means? Who else than distributions would be interested in this? Pretty
> much any use you initially mentioned can be done in simpler ways, e.g.
> anyone afraid of modules simply disables module loading completely.

this issue, and these holes keep comeing up in discussions, why can't these 
holes be closed? I seem to remember seeing patches that would remove /dev/kmem 
being sent to the list, but they weren't accepted into the kernel (and I seem to 
remember people being against the concept of removeing them, not against 
techincal details of the patches. but this was many years ago)

at one point I remember hearing that X required raw /dev/kmem, but for servers 
you don't need/want X anyway, so this is a useful option even if X doesn't get 
fixed.

David Lang

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing 
  2007-02-15 17:32 ` David Howells
@ 2007-02-15 18:33   ` Roman Zippel
  2007-02-15 20:01     ` David Lang
  0 siblings, 1 reply; 30+ messages in thread
From: Roman Zippel @ 2007-02-15 18:33 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, herbert.xu, linux-kernel, davej, arjan, linux-crypto

Hi,

On Thu, 15 Feb 2007, David Howells wrote:

> > This is really the weak point - it offers no advantage over an equivalent 
> > implementation in user space (e.g. in the module tools). So why has to be 
> > done in the kernel?
> 
> Because the init_module() system call is the common point of module submission
> to the kernel, not any particular userspace program.  There is no requirement
> for userspace to load a module by invoking a module tools program or library,
> and so userspace can bypass the checks entirely by just calling init_module().
> Assume for a moment that you can't trust userspace...  (Obviously, if you can't
> trust the kernel then you're already stuffed.)

All the security stuff in the kernel should provide the necessary means to 
restrict this system call.

> It is possible to protect /dev/mem and /dev/kmem or make them unavailable and
> it is possible to protect the kernel's memory whilst it is running (provided
> you don't have nommu or broken hardware and you don't let userspace concoct any
> DMA request it likes) which mostly closes those other vectors I mentioned.
> This isn't something I intended to look at with this patch.  Those are separate
> holes.

Exactly and as long as there are these holes, these patches are only 
kernel bloat. The simple verification can also be done in userspace and 
module signing offers no real security.
What real value do these patches provide, that can't be reached via other 
means? Who else than distributions would be interested in this? Pretty 
much any use you initially mentioned can be done in simpler ways, e.g. 
anyone afraid of modules simply disables module loading completely.

bye, Roman

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing 
  2007-02-14 19:09 David Howells
                   ` (3 preceding siblings ...)
  2007-02-15 14:35 ` Roman Zippel
@ 2007-02-15 17:32 ` David Howells
  2007-02-15 18:33   ` Roman Zippel
  2007-02-15 21:03 ` Adrian Bunk
  2007-02-15 22:13 ` Pavel Machek
  6 siblings, 1 reply; 30+ messages in thread
From: David Howells @ 2007-02-15 17:32 UTC (permalink / raw)
  To: Roman Zippel
  Cc: torvalds, akpm, herbert.xu, linux-kernel, davej, arjan,
	linux-crypto, dhowells

Roman Zippel <zippel@linux-m68k.org> wrote:

> > Now, this is not a complete solution by any means: the core kernel is not
> > protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
> > controls) one relatively simple attack vector.
> 
> This is really the weak point - it offers no advantage over an equivalent 
> implementation in user space (e.g. in the module tools). So why has to be 
> done in the kernel?

Because the init_module() system call is the common point of module submission
to the kernel, not any particular userspace program.  There is no requirement
for userspace to load a module by invoking a module tools program or library,
and so userspace can bypass the checks entirely by just calling init_module().
Assume for a moment that you can't trust userspace...  (Obviously, if you can't
trust the kernel then you're already stuffed.)

It is possible to protect /dev/mem and /dev/kmem or make them unavailable and
it is possible to protect the kernel's memory whilst it is running (provided
you don't have nommu or broken hardware and you don't let userspace concoct any
DMA request it likes) which mostly closes those other vectors I mentioned.
This isn't something I intended to look at with this patch.  Those are separate
holes.

Making the core kernel load image inaccessible or immutable to root is not
something I can provide a generic solution for and security checking the core
kernel load image has to be done at an earlier layer as you can't rely on
something guaranteeing its own integrity because if someone can alter that
something, then they can bypass the self-checking too...

However, modules permits arbitrary modification of the running kernel to be
attempted.

David

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing 
  2007-02-14 19:09 David Howells
                   ` (2 preceding siblings ...)
  2007-02-15  3:41 ` Andrew Morton
@ 2007-02-15 14:35 ` Roman Zippel
  2007-02-15 17:32 ` David Howells
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 30+ messages in thread
From: Roman Zippel @ 2007-02-15 14:35 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, herbert.xu, linux-kernel, davej, arjan, linux-crypto

Hi,

On Wed, 14 Feb 2007, David Howells wrote:

> Now, this is not a complete solution by any means: the core kernel is not
> protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
> controls) one relatively simple attack vector.

This is really the weak point - it offers no advantage over an equivalent 
implementation in user space (e.g. in the module tools). So why has to be 
done in the kernel?

bye, Roman

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15  6:14         ` Andreas Gruenbacher
@ 2007-02-15  6:22           ` Dave Jones
  2007-02-15 20:34           ` Valdis.Kletnieks
  2007-02-15 22:10           ` Pavel Machek
  2 siblings, 0 replies; 30+ messages in thread
From: Dave Jones @ 2007-02-15  6:22 UTC (permalink / raw)
  To: Andreas Gruenbacher
  Cc: Andrew Morton, David Howells, torvalds, herbert.xu, linux-kernel,
	arjan, linux-crypto

On Wed, Feb 14, 2007 at 10:14:53PM -0800, Andreas Gruenbacher wrote:
 > On Wednesday 14 February 2007 21:45, Dave Jones wrote:
 > > well, the situation for external modules is no worse than usual.
 > > They still work, they just aren't signed. Which from a distributor point
 > > of view, is actually a nice thing, as they stick out like a sore thumb
 > > in oops reports with (U) markers :)
 > 
 > I agree, that's really what should happen. We solve this by marking modules as 
 > supported, partner supported, or unsupported, but in an "insecure" way, so 
 > partners and users could try to fake the support status of a module and/or 
 > remove status flags from Oopses, and cryptography wouldn't save us. We could 
 > try to sign Oopses which I guess you guys are doing. This whole issue hasn't 
 > been a serious problem in the past though, and we generally try to trust 
 > users not to play games on us.

For the most part it works out.  I've had users file oopses where they've editted
out Tainted: P, and left in nvidia(U) for example :-)

		Dave

-- 
http://www.codemonkey.org.uk

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15  5:45       ` Dave Jones
@ 2007-02-15  6:14         ` Andreas Gruenbacher
  2007-02-15  6:22           ` Dave Jones
                             ` (2 more replies)
  0 siblings, 3 replies; 30+ messages in thread
From: Andreas Gruenbacher @ 2007-02-15  6:14 UTC (permalink / raw)
  To: Dave Jones
  Cc: Andrew Morton, David Howells, torvalds, herbert.xu, linux-kernel,
	arjan, linux-crypto

On Wednesday 14 February 2007 21:45, Dave Jones wrote:
> well, the situation for external modules is no worse than usual.
> They still work, they just aren't signed. Which from a distributor point
> of view, is actually a nice thing, as they stick out like a sore thumb
> in oops reports with (U) markers :)

I agree, that's really what should happen. We solve this by marking modules as 
supported, partner supported, or unsupported, but in an "insecure" way, so 
partners and users could try to fake the support status of a module and/or 
remove status flags from Oopses, and cryptography wouldn't save us. We could 
try to sign Oopses which I guess you guys are doing. This whole issue hasn't 
been a serious problem in the past though, and we generally try to trust 
users not to play games on us.

In the end, it all seems to boils down to a difference in philosophy.

Thanks,
Andreas

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15  5:35     ` Andreas Gruenbacher
@ 2007-02-15  5:45       ` Dave Jones
  2007-02-15  6:14         ` Andreas Gruenbacher
  0 siblings, 1 reply; 30+ messages in thread
From: Dave Jones @ 2007-02-15  5:45 UTC (permalink / raw)
  To: Andreas Gruenbacher
  Cc: Andrew Morton, David Howells, torvalds, herbert.xu, linux-kernel,
	arjan, linux-crypto

On Wed, Feb 14, 2007 at 09:35:40PM -0800, Andreas Gruenbacher wrote:
 > On Wednesday 14 February 2007 20:13, Dave Jones wrote:
 > > I've not investigated it, but I hear rumours that suse has something
 > > similar.
 > 
 > Actually, no. We don't belive that module signing adds significant value,

ok, then I was misinformed.

 > and it also doesn't work well with external modules.

well, the situation for external modules is no worse than usual.
They still work, they just aren't signed. Which from a distributor point
of view, is actually a nice thing, as they stick out like a sore thumb
in oops reports with (U) markers :)

 > (The external modules we really care about are GPL ones; it gives us a way
 > to update drivers without pushing out entirely new kernels.)

external modules still compile, and run just fine. The signed modules code
doesn't prevent loading of them unless the user decides to do so with
a special boot option (which is no different really than say, reducing
the cap-bound sysctl to prevent module loading).

		Dave

-- 
http://www.codemonkey.org.uk

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15  4:13   ` Dave Jones
@ 2007-02-15  5:35     ` Andreas Gruenbacher
  2007-02-15  5:45       ` Dave Jones
  2007-02-15 20:55     ` Valdis.Kletnieks
  1 sibling, 1 reply; 30+ messages in thread
From: Andreas Gruenbacher @ 2007-02-15  5:35 UTC (permalink / raw)
  To: Dave Jones
  Cc: Andrew Morton, David Howells, torvalds, herbert.xu, linux-kernel,
	arjan, linux-crypto

On Wednesday 14 February 2007 20:13, Dave Jones wrote:
> I've not investigated it, but I hear rumours that suse has something
> similar.

Actually, no. We don't belive that module signing adds significant value, and 
it also doesn't work well with external modules. (The external modules we 
really care about are GPL ones; it gives us a way to update drivers without 
pushing out entirely new kernels.)

Cheers,
Andreas

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-15  3:41 ` Andrew Morton
@ 2007-02-15  4:13   ` Dave Jones
  2007-02-15  5:35     ` Andreas Gruenbacher
  2007-02-15 20:55     ` Valdis.Kletnieks
  0 siblings, 2 replies; 30+ messages in thread
From: Dave Jones @ 2007-02-15  4:13 UTC (permalink / raw)
  To: Andrew Morton
  Cc: David Howells, torvalds, herbert.xu, linux-kernel, arjan, linux-crypto

On Wed, Feb 14, 2007 at 07:41:12PM -0800, Andrew Morton wrote:

 >  77 files changed, 9681 insertions(+), 10 deletions(-)
 > 
 > just to be able to sign modules.
 > 
 > Normally I'd collapse writhing in laughter, but..
 > 
 > > These patches have been in use by RHEL and Fedora kernels for years, and so
 > > have been thoroughly tested.
 > 
 > so I guess there's an argument for merging them so we can send them back to
 > you guys.  But there's also an argument to declare all this gunk a
 > vendor-only thing.  How much pain would that cause?

it needs rediffing pretty much every time the cryptoapi changes.
On a good month that means once per point release, otherwise...

One argument in its favour is aparently Red Hat isn't the only vendor
with something like this.  I've not investigated it, but I hear rumours
that suse has something similar.  Having everyone using the same code
would be a win for obvious reasons.

		Dave

-- 
http://www.codemonkey.org.uk

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-14 19:09 David Howells
  2007-02-14 19:26 ` Linus Torvalds
  2007-02-14 19:40 ` David Howells
@ 2007-02-15  3:41 ` Andrew Morton
  2007-02-15  4:13   ` Dave Jones
  2007-02-15 14:35 ` Roman Zippel
                   ` (3 subsequent siblings)
  6 siblings, 1 reply; 30+ messages in thread
From: Andrew Morton @ 2007-02-15  3:41 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, herbert.xu, linux-kernel, davej, arjan, linux-crypto

On Wed, 14 Feb 2007 19:09:38 +0000 David Howells <dhowells@redhat.com> wrote:

> These patches provide a GPG-based kernel module signing facility.  Their use is
> not fully automated within the confines of the kernel build process because it
> needs provision of keys from outside of the kernel before the kernel can be
> compiled.
> 
> The patches are:
> 
>  (1) A cut-down MPI library derived from GPG with error handling added.
> 
>  (2) Permit hash algorithms to hash kernel data defined by a virtual address
>      and a length rather than trying to use scattergather lists (which require
>      struct page pointers to be determined).
> 
>  (3) Add extra information to the per-arch ELF headers to more fully describe
>      the format of the ELF metadata.
> 
>  (4) Add module verification capabilities, including ELF metadata verification.
> 
>  (5) Add a generic DSA signature checker.  Given a SHA1 hash of the data to be
>      verified and a binary blob holding a GPG signature stream, this verifies
>      the signature using a built-in ring of public keys.
> 
>  (6) Add a module signature checker that applies signature checking to modules
>      on module load, checking the signature against the ring of public keys
>      compiled into the kernel.

Grand total:

 77 files changed, 9681 insertions(+), 10 deletions(-)

just to be able to sign modules.

Normally I'd collapse writhing in laughter, but..

> These patches have been in use by RHEL and Fedora kernels for years, and so
> have been thoroughly tested.

so I guess there's an argument for merging them so we can send them back to
you guys.  But there's also an argument to declare all this gunk a
vendor-only thing.  How much pain would that cause?

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-14 21:59   ` David Howells
@ 2007-02-14 22:21     ` Michael Halcrow
  0 siblings, 0 replies; 30+ messages in thread
From: Michael Halcrow @ 2007-02-14 22:21 UTC (permalink / raw)
  To: David Howells
  Cc: Linus Torvalds, akpm, herbert.xu, linux-kernel, davej, arjan,
	linux-crypto

On Wed, Feb 14, 2007 at 09:59:37PM +0000, David Howells wrote:
> Michael Halcrow <mhalcrow@us.ibm.com> wrote:
> 
> > Right now, eCryptfs just delegates its modular exponentiation
> > operations to a userspace daemon. If RSA ever finds its way into the
> > kernel, I might tweak eCryptfs to use that instead for some of the
> > public key operations.
> 
> Am I right in thinking that RSA uses many of the same MPI lib bits
> as DSA?

I would imagine so. Assuming we aren't having to hassle with key
generation (eCryptfs takes care of that in userspace), then RSA is,
more or less, a^b mod c (mpi_mulpowm() and friends).

Mike

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing 
  2007-02-14 19:40 ` David Howells
  2007-02-14 21:32   ` Michael Halcrow
@ 2007-02-14 21:59   ` David Howells
  2007-02-14 22:21     ` Michael Halcrow
  2007-02-15 21:31   ` Indan Zupancic
  2 siblings, 1 reply; 30+ messages in thread
From: David Howells @ 2007-02-14 21:59 UTC (permalink / raw)
  To: Michael Halcrow
  Cc: Linus Torvalds, akpm, herbert.xu, linux-kernel, davej, arjan,
	linux-crypto

Michael Halcrow <mhalcrow@us.ibm.com> wrote:

> Right now, eCryptfs just delegates its modular exponentiation
> operations to a userspace daemon. If RSA ever finds its way into the
> kernel, I might tweak eCryptfs to use that instead for some of the
> public key operations.

Am I right in thinking that RSA uses many of the same MPI lib bits as DSA?

David

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing
  2007-02-14 19:40 ` David Howells
@ 2007-02-14 21:32   ` Michael Halcrow
  2007-02-14 21:59   ` David Howells
  2007-02-15 21:31   ` Indan Zupancic
  2 siblings, 0 replies; 30+ messages in thread
From: Michael Halcrow @ 2007-02-14 21:32 UTC (permalink / raw)
  To: David Howells
  Cc: Linus Torvalds, akpm, herbert.xu, linux-kernel, davej, arjan,
	linux-crypto

On Wed, Feb 14, 2007 at 07:40:57PM +0000, David Howells wrote:
> Hashing, yes; encryption, yes; signature checking: no from what I
> can see.
> 
> It's possible that I can share code with eCryptFS, though at first
> sight that doesn't seem to overlap with what I want to do.

Right now, eCryptfs just delegates its modular exponentiation
operations to a userspace daemon. If RSA ever finds its way into the
kernel, I might tweak eCryptfs to use that instead for some of the
public key operations.

Mike

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing 
  2007-02-14 19:09 David Howells
  2007-02-14 19:26 ` Linus Torvalds
@ 2007-02-14 19:40 ` David Howells
  2007-02-14 21:32   ` Michael Halcrow
                     ` (2 more replies)
  2007-02-15  3:41 ` Andrew Morton
                   ` (4 subsequent siblings)
  6 siblings, 3 replies; 30+ messages in thread
From: David Howells @ 2007-02-14 19:40 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: akpm, herbert.xu, linux-kernel, davej, arjan, linux-crypto

Linus Torvalds <torvalds@linux-foundation.org> wrote:

> >  (1) A cut-down MPI library derived from GPG with error handling added.
> 
> Do we really need to add this?

I presume you mean the MPI library specifically?  If so, then yes.  It's
necessary to do DSA signature verification (or RSA for that matter).

> Wouldn't it be much nicer to just teach people to use one of the existing 
> signature things that we need for _other_ cases anyway, and already have 
> merged?

Existing signature things?  I know not of such beasts, nor can I see them
offhand.

> (Of course, it's possible that none of the current crypto supports any 
> signature checking at all - I didn't actually look. In which case my 
> argument is pointless).

Hashing, yes; encryption, yes; signature checking: no from what I can see.

It's possible that I can share code with eCryptFS, though at first sight that
doesn't seem to overlap with what I want to do.

David

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH 0/6] MODSIGN: Kernel module signing 
  2007-02-14 19:09 David Howells
@ 2007-02-14 19:26 ` Linus Torvalds
  2007-02-14 19:40 ` David Howells
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 30+ messages in thread
From: Linus Torvalds @ 2007-02-14 19:26 UTC (permalink / raw)
  To: David Howells; +Cc: akpm, herbert.xu, linux-kernel, davej, arjan, linux-crypto



On Wed, 14 Feb 2007, David Howells wrote:
>
>  (1) A cut-down MPI library derived from GPG with error handling added.

Do we really need to add this?

Wouldn't it be much nicer to just teach people to use one of the existing 
signature things that we need for _other_ cases anyway, and already have 
merged?

(Of course, it's possible that none of the current crypto supports any 
signature checking at all - I didn't actually look. In which case my 
argument is pointless).

		Linus

^ permalink raw reply	[flat|nested] 30+ messages in thread

* [PATCH 0/6] MODSIGN: Kernel module signing 
@ 2007-02-14 19:09 David Howells
  2007-02-14 19:26 ` Linus Torvalds
                   ` (6 more replies)
  0 siblings, 7 replies; 30+ messages in thread
From: David Howells @ 2007-02-14 19:09 UTC (permalink / raw)
  To: torvalds, akpm, herbert.xu
  Cc: linux-kernel, davej, arjan, linux-crypto, dhowells



These patches provide a GPG-based kernel module signing facility.  Their use is
not fully automated within the confines of the kernel build process because it
needs provision of keys from outside of the kernel before the kernel can be
compiled.

The patches are:

 (1) A cut-down MPI library derived from GPG with error handling added.

 (2) Permit hash algorithms to hash kernel data defined by a virtual address
     and a length rather than trying to use scattergather lists (which require
     struct page pointers to be determined).

 (3) Add extra information to the per-arch ELF headers to more fully describe
     the format of the ELF metadata.

 (4) Add module verification capabilities, including ELF metadata verification.

 (5) Add a generic DSA signature checker.  Given a SHA1 hash of the data to be
     verified and a binary blob holding a GPG signature stream, this verifies
     the signature using a built-in ring of public keys.

 (6) Add a module signature checker that applies signature checking to modules
     on module load, checking the signature against the ring of public keys
     compiled into the kernel.


These patches have been in use by RHEL and Fedora kernels for years, and so
have been thoroughly tested.  The signed modules survive both the debuginfo
separation performed by rpmbuild and the strip performed when modules are being
reduced as much as possible before being included in an initial ramdisk
composition.  Signed modules have been tested to work with LE and BE, 32- and
64-bit arch kernels, including i386, x86_64, ppc64, ia64, s390 and s390x.

There are several reasons why these patches are useful, amongst which are:

 (1) to protect against accidentally-corrupted modules causing damage;

 (2) to protect against maliciously modified modules causing damage;

 (3) to allow a sysadmin (or more likely an IT department) to enforce a policy
     that only known and approved modules shall be loaded onto machines which
     they're expected to support;

 (4) to allow other support providers to do likewise, or at least to _detect_
     the fact that unsupported modules are loaded;

 (5) to allow the detection of modules replaced by a second-order distro or a
     preloaded Linux purveyor.

Basically, these patches have two main appeals to me: (a) preventing malicious
modules from being loaded, and (b) reducing support workload by pointing out
modules on a crashing box that aren't what they're expected to be.


Now, this is not a complete solution by any means: the core kernel is not
protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
controls) one relatively simple attack vector.

This facility is optional: the builder of a kernel is by no means under any
requirement to actually enable it, let alone force the set of loadable modules
to be restricted to just those that the builder provides (there are degrees of
restriction available).


Note to Andrew and Linus: Herbert Xu and the crypto guys need to check the
crypto bits before this should be accepted.  Possibly these patches should go
via the crypto tree.

David

^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2007-02-16 20:28 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <7OPWh-470-9@gated-at.bofh.it>
     [not found] ` <7OxPF-16i-7@gated-at.bofh.it>
     [not found]   ` <7OSKA-8A-17@gated-at.bofh.it>
     [not found]     ` <7OTGJ-1G5-23@gated-at.bofh.it>
2007-02-16 15:38       ` [PATCH 0/6] MODSIGN: Kernel module signing Bodo Eggert
2007-02-14 19:09 David Howells
2007-02-14 19:26 ` Linus Torvalds
2007-02-14 19:40 ` David Howells
2007-02-14 21:32   ` Michael Halcrow
2007-02-14 21:59   ` David Howells
2007-02-14 22:21     ` Michael Halcrow
2007-02-15 21:31   ` Indan Zupancic
2007-02-15  3:41 ` Andrew Morton
2007-02-15  4:13   ` Dave Jones
2007-02-15  5:35     ` Andreas Gruenbacher
2007-02-15  5:45       ` Dave Jones
2007-02-15  6:14         ` Andreas Gruenbacher
2007-02-15  6:22           ` Dave Jones
2007-02-15 20:34           ` Valdis.Kletnieks
2007-02-15 22:12             ` Andreas Gruenbacher
2007-02-16  0:15               ` Olaf Kirch
2007-02-15 22:10           ` Pavel Machek
2007-02-15 20:55     ` Valdis.Kletnieks
2007-02-15 21:32       ` Adrian Bunk
2007-02-15 22:12         ` Valdis.Kletnieks
2007-02-15 14:35 ` Roman Zippel
2007-02-15 17:32 ` David Howells
2007-02-15 18:33   ` Roman Zippel
2007-02-15 20:01     ` David Lang
2007-02-15 21:01       ` Roman Zippel
2007-02-15 21:03 ` Adrian Bunk
2007-02-15 22:13 ` Pavel Machek
2007-02-16 20:21   ` Dave Jones
2007-02-16 20:27     ` Arjan van de Ven

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).