"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: ‘
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 jus
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
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 6e03943da0f3b0
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: Pro
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 signing_key.x509.k
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
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 signing_key.x509.si
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 wonde
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 output,
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 a
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 broke
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
wher
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-crypto" in
the body of a message to majord...@vger.kernel.
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 an
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 t
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 a
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)$
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:
git://
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.
>
> O
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 unsi
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 yo
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
discussi
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 viewing
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 uses
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 s
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:
http://git.kernel.org/?p=linux/kernel/git/dhowells/linux-modsign.git;a=shortlog;h=refs/heads
29 matches
Mail list logo
