"Kasatkin, Dmitry" writes:
> http://git.kernel.org/?p=linux/kernel/git/rusty/linux.git;a=commit;h=a15e196c5543d1d2d7f0cd70e62351aeb1f8b871
>
> It breaks bisect..
>
> CC kernel/module_signing.o
> kernel/module_signing.c: In function ‘mod_verify_sig’:
> kernel/module_signing.c:21:10: error:
Kasatkin, Dmitry dmitry.kasat...@intel.com writes:
http://git.kernel.org/?p=linux/kernel/git/rusty/linux.git;a=commit;h=a15e196c5543d1d2d7f0cd70e62351aeb1f8b871
It breaks bisect..
CC kernel/module_signing.o
kernel/module_signing.c: In function ‘mod_verify_sig’:
On Thu, Oct 4, 2012 at 2:22 AM, Rusty Russell wrote:
> David Howells writes:
>
>> Rusty Russell 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
On Thu, Oct 4, 2012 at 2:22 AM, Rusty Russell ru...@rustcorp.com.au wrote:
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
David Howells writes:
> Rusty Russell 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
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
Rusty Russell 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 not really set up to
On Tue, Oct 02, 2012 at 12:58:03PM +0930, Rusty Russell wrote:
> Josh Boyer writes:
>
> > On Sat, Sep 29, 2012 at 08:13:25AM +0100, David Howells wrote:
> >> Rusty Russell wrote:
> >>
> >> > [2.808075] Loading module verification certificates
> >> > [2.809331] X.509: Cert
Josh Boyer writes:
> On Sat, Sep 29, 2012 at 08:13:25AM +0100, David Howells wrote:
>> Rusty Russell wrote:
>>
>> > [2.808075] Loading module verification certificates
>> > [2.809331] X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has
>> > expired
>> > [2.810500] MODSIGN:
David Howells writes:
> Rusty Russell 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
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 wrote:
>
> > [2.808075] Loading module verification certificates
> > [2.809331] X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has
> > expired
> > [2.810500] MODSIGN: Problem loading in-kernel X.509
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
Rusty Russell 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
Rusty Russell 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.
Ah!
I
David Howells writes:
> Rusty Russell 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
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
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
Rusty Russell 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 because a couple of IPv6
Rusty Russell 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 irritatingly
Rusty Russell 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 spot the bit
Geert Uytterhoeven 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-kernel" in
the body of a message to
Mimi Zohar writes:
> On Wed, 2012-09-26 at 13:16 +0930, Rusty Russell wrote:
>> David Howells 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
On Wed, Sep 26, 2012 at 5:46 AM, Rusty Russell 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 ball, but I
David Howells 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
rusty@rusty-x201:~/devel/kernel/linux (tmp-merge)$
David Howells 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)
>
> are
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)
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
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-kernel 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:
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:
On Wed, 2012-09-26 at 13:16 +0930, Rusty Russell wrote:
> David Howells 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.
>
>
David Howells writes:
> Rusty Russell 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
Rusty Russell 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.
I've adjusted
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
David Howells 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 accidentally-off-list
Kasatkin, Dmitry wrote:
> Just one question about key description...
> request_asymmetric_key uses format for key description: ": ".
> Preparsing code creates description from those values.
> I see that key id is not 8 bytes anymore but full hash size of 20 bytes.
Remember: This is for
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
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
David Howells 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 greater, but the code
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:
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
58 matches
Mail list logo
