David Howells dhowe...@redhat.com writes:
Rusty Russell ru...@rustcorp.com.au wrote:
Right. I think we need to use different names for generated vs supplied
files
The problem with supplied files is people who do allyesconfig, allmodconfig
and randconfig just to test things finding that
David Howells dhowe...@redhat.com writes:
Rusty Russell ru...@rustcorp.com.au wrote:
I noticed the Cert number didn't change with rebuilds: distclean
didn't remove some files:
$ git clean -f -f -x -d
Removing extra_certificates
Removing signing_key.priv
Removing signing_key.x509
Josh Boyer jwbo...@redhat.com writes:
On Sat, Sep 29, 2012 at 08:13:25AM +0100, David Howells wrote:
Rusty Russell ru...@rustcorp.com.au wrote:
[2.808075] Loading module verification certificates
[2.809331] X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has
expired
[
On Tue, Oct 02, 2012 at 12:58:03PM +0930, Rusty Russell wrote:
Josh Boyer jwbo...@redhat.com writes:
On Sat, Sep 29, 2012 at 08:13:25AM +0100, David Howells wrote:
Rusty Russell ru...@rustcorp.com.au wrote:
[2.808075] Loading module verification certificates
[2.809331]
Rusty Russell ru...@rustcorp.com.au wrote:
Right. I think we need to use different names for generated vs supplied
files
The problem with supplied files is people who do allyesconfig, allmodconfig
and randconfig just to test things finding that their builds break. The
kernel build magic is
On Sat, Sep 29, 2012 at 08:13:25AM +0100, David Howells wrote:
Rusty Russell ru...@rustcorp.com.au wrote:
[2.808075] Loading module verification certificates
[2.809331] X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has
expired
[2.810500] MODSIGN: Problem loading
David Howells dhowe...@redhat.com writes:
Rusty Russell ru...@rustcorp.com.au wrote:
And after those three fixes, I still get all fail:
[3.361036] Request for unknown module key 'Magrathea: Glacier signing
key: 6
e03943da0f3b015ba6ed7f5e0cac4fe48680994' err -11
Can you look back
Rusty Russell ru...@rustcorp.com.au wrote:
[2.808075] Loading module verification certificates
[2.809331] X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has
expired
[2.810500] MODSIGN: Problem loading in-kernel X.509 certificate (-127)
Hmmm... Other people have seen that.
Rusty Russell ru...@rustcorp.com.au wrote:
I noticed the Cert number didn't change with rebuilds: distclean
didn't remove some files:
$ git clean -f -f -x -d
Removing extra_certificates
Removing signing_key.priv
Removing signing_key.x509
Removing signing_key.x509.keyid
Removing
David Howells dhowe...@redhat.com writes:
Hi Rusty,
Could you pull my tree?
And after those three fixes, I still get all fail:
[3.361036] Request for unknown module key 'Magrathea: Glacier signing key: 6
e03943da0f3b015ba6ed7f5e0cac4fe48680994' err -11
David Howells dhowe...@redhat.com writes:
Hi Rusty,
Could you pull my tree?
David
---
The following changes since commit eeea3ac912207dcf759b95b2b4c36f96bce583bf:
Merge tag 'fixes-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2012-09-06
10:23:58 -0700)
On Wed, Sep 26, 2012 at 5:46 AM, Rusty Russell ru...@rustcorp.com.au wrote:
You previously wrote:
You can't compare them that easily. One has a FIPS-mode panic and the other
doesn't. Do we want to panic if we reject an unsigned module in enforcing
mode when we're in FIPS mode?
It's a line
Mimi Zohar zo...@linux.vnet.ibm.com writes:
On Wed, 2012-09-26 at 13:16 +0930, Rusty Russell wrote:
David Howells dhowe...@redhat.com writes:
The module signing patches provide:
- Some fixes to Rusty's patch. Also an additional patch to extend the
policy
handling for modules
Geert Uytterhoeven ge...@linux-m68k.org wrote:
Just wondering, what's the advantage of doing panic over just
rejecting the module?
Panic is a DoS?
FIPS mode is strange like that.
David
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to
Rusty Russell ru...@rustcorp.com.au wrote:
And after those three fixes, I still get all fail:
[3.361036] Request for unknown module key 'Magrathea: Glacier signing
key: 6
e03943da0f3b015ba6ed7f5e0cac4fe48680994' err -11
Can you look back further in your kernel output, see if you can
Rusty Russell ru...@rustcorp.com.au wrote:
warning: (MODULE_SIG) selects ASYMMETRIC_KEY_TYPE which has unmet direct
dependencies (CRYPTO KEYS)
Ah, I see:
+ select CONFIG_KEYS
+ select CONFIG_CRYPTO
I fixed this commit, rather than go around again.
Thanks.
select is
Rusty Russell ru...@rustcorp.com.au wrote:
[3.361036] Request for unknown module key 'Magrathea: Glacier signing
key: 6
e03943da0f3b015ba6ed7f5e0cac4fe48680994' err -11
Okay, it turns out that my attempts to remove SHA1 by editing it out of the
.config file were doomed to failure
Hi Rusty,
I've pushed two additional patches. The first makes the X.509 cert signature
use the same hash algorithm as the signatures on the modules - which should
fix the problem you're seeing, I think. The second makes elements of the
names use UTF8 strings, just in case someone wants to use
Hi Rusty,
Could you pull my tree?
David
---
The following changes since commit eeea3ac912207dcf759b95b2b4c36f96bce583bf:
Merge tag 'fixes-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2012-09-06 10:23:58
-0700)
are available in the git repository at:
Rusty Russell ru...@rustcorp.com.au wrote:
We do a very simple search for a particular string appended to the module
(which is cache-hot and about to be SHA'd anyway). There's both a config
option and a boot parameter which control whether we accept (and taint) or
fail with unsigned modules.
David Howells dhowe...@redhat.com writes:
Rusty Russell ru...@rustcorp.com.au wrote:
We do a very simple search for a particular string appended to the module
(which is cache-hot and about to be SHA'd anyway). There's both a config
option and a boot parameter which control whether we accept
On Wed, 2012-09-26 at 13:16 +0930, Rusty Russell wrote:
David Howells dhowe...@redhat.com writes:
The module signing patches provide:
- Some fixes to Rusty's patch. Also an additional patch to extend the
policy
handling for modules signed with an unknown key and to handle FIPS
Hello David,
As I can see API has changed towards our discussion on KS.
Now digest can be supplied to the verify_signature in a
public_key_signature argument.
It looks that in such away we can use this API for IMA/EVM as well.
Just one question about key description...
request_asymmetric_key
Kasatkin, Dmitry dmitry.kasat...@intel.com wrote:
Just one question about key description...
request_asymmetric_key uses format for key description: signer: key-id.
Preparsing code creates description from those values.
I see that key id is not 8 bytes anymore but full hash size of 20 bytes.
David Howells dhowe...@redhat.com writes:
The module signing patches provide:
- Some fixes to Rusty's patch. Also an additional patch to extend the policy
handling for modules signed with an unknown key and to handle FIPS mode.
Ok, I merged some of this (after our previous
Hi Herbert, Rusty,
Here are my latest module signing patches on top of the asymmetric key crypto
patches, which I hope Herbert will consider taking, at least from the
crypto-keys-post-KS branch:
David Howells dhowe...@redhat.com wrote:
Note, this implementation of the X.509 certificate parser uses a couple of
patterns to drive a reusable ASN.1 decoder. I do, however, have a direct
in-line decoder implementation also that can only decode X.509 certs. The
stack space usage is
27 matches
Mail list logo
