> Il giorno 17 gen 2018, alle ore 06:44, Eric Biggers <ebigge...@gmail.com> ha
> scritto:
>
> On Wed, Jan 17, 2018 at 06:36:16AM +0100, Paolo Valente wrote:
>>
>>
>>> Il giorno 17 gen 2018, alle ore 06:16, Eric Biggers <ebigge...@gmail.com>
>>> ha scritto:
>>>
>>> Hi Paolo,
>>>
>>> On Fri, Jan 12, 2018 at 07:06:12AM +0100, Paolo Valente wrote:
>>>>
>>>>
>>>>> Il giorno 11 gen 2018, alle ore 23:37, Arnd Bergmann <a...@arndb.de> ha
>>>>> scritto:
>>>>>
>>>>> On Thu, Jan 11, 2018 at 7:29 PM, Paolo Valente <paolo.vale...@linaro.org>
>>>>> wrote:
>>>>>> Hi guys,
>>>>>> this is a help request, for a problem that has been driving me crazy
>>>>>> all day long, without any success :(
>>>>>>
>>>>>> I've compiled a 4.15-rc7 custom kernel on a freshly-installed Fedora
>>>>>> 27, using the usual "make ; make modules_install ; make install"
>>>>>> procedure. No error reported while building. But at boot the
>>>>>> kernel immediately fails as follows, apparently while loading/parsing
>>>>>> an X.509 certificate:
>>>>>
>>>>> The BUG_ON() you hit is this one in public_key_verify_signature():
>>>>>
>>>>> BUG_ON(!sig->digest);
>>>>>
>>>>> There was a patch series by Eric Biggers that touched these files to
>>>>> add some fixes
>>>>> after v4.15-rc1. I'm not runnig that code myself, but it sounds like
>>>>> a real regression,
>>>>> so I'm adding Eric (to look at the code), the corresponding mailing
>>>>> list and Thorsten
>>>>> (for regression tracking) to Cc.
>>>>>
>>>>> x509_cert_parse() allocates the 'cert->sig' structure, and calls
>>>>> x509_get_sig_params(),
>>>>> which may or may not allocate a digest. It returns with
>>>>> cert->unsupported_sig=true
>>>>> in case it fails to allocate a digest for some reason (crypto_alloc_shash
>>>>> failed
>>>>> or no sig->hash_algo).
>>>>>
>>>>> The full set of Eric's patches is
>>>>>
>>>>> 54c1fb39fe04 X.509: fix comparisons of ->pkey_algo
>>>>> 18026d866801 KEYS: reject NULL restriction string when type is specified
>>>>> 3d1f0255426a security: keys: remove redundant assignment to key_ref
>>>>> aa3300362060 X.509: use crypto_shash_digest()
>>>>> 72f9a07b6bfa KEYS: be careful with error codes in
>>>>> public_key_verify_signature()
>>>>> a80745a6de51 pkcs7: use crypto_shash_digest()
>>>>> 7204eb8590c7 pkcs7: fix check for self-signed certificate
>>>>> 8ecb506d3476 pkcs7: return correct error code if pkcs7_check_authattrs()
>>>>> fails
>>>>> 8dfd2f22d3bf 509: fix printing uninitialized stack memory when OID is
>>>>> empty
>>>>> 47e0a208fb9d X.509: fix buffer overflow detection in sprint_oid()
>>>>> 0f30cbea005b X.509: reject invalid BIT STRING for subjectPublicKey
>>>>> 81a7be2cd69b ASN.1: check for error from ASN1_OP_END__ACT actions
>>>>> e0058f3a874e ASN.1: fix out-of-bounds read when parsing indefinite length
>>>>> item
>>>>> 4dca6ea1d943 KEYS: add missing permission check for request_key()
>>>>> destination
>>>>> a2d8737d5c78 KEYS: remove unnecessary get/put of explicit dest_keyring
>>>>>
>>>>> and it's based on -rc2. If you want to do a quicker bisection, I'd
>>>>> suggest you try
>>>>> 4.15-rc2 and 54c1fb39fe04 to start with.
>>>>>
>>>>
>>>> Thank you very much Arnd. Fortunately, for the task I'm performing, a
>>>> 4.14 will do too. And I'm under pressure to finally finish this task.
>>>> Yet, even before I finish with this task, I'm willing to do any test
>>>> that the guys you added may want me to do. And, if more useful for
>>>> the community, ok for me to switch to the most appropriate public
>>>> mailing lists.
>>>>
>>>
>>> Have you managed to bisect this yet? I'm not seeing how my changes could
>>> have
>>> caused this, but it does seem there may be an existing bug where this BUG()
>>> can
>>> be hit if a certificate's signature uses a hash algorithm that is not built
>>> into
>>> the kernel. To verify whether that is happening can you try adding:
>>>
>>> diff --git a/crypto/asymmetric_keys/x509_public_key.c
>>> b/crypto/asymmetric_keys/x509_public_key.c
>>> index 9338b4558cdc..f1804640445a 100644
>>> --- a/crypto/asymmetric_keys/x509_public_key.c
>>> +++ b/crypto/asymmetric_keys/x509_public_key.c
>>> @@ -58,6 +58,8 @@ int x509_get_sig_params(struct x509_certificate *cert)
>>> tfm = crypto_alloc_shash(sig->hash_algo, 0, 0);
>>> if (IS_ERR(tfm)) {
>>> if (PTR_ERR(tfm) == -ENOENT) {
>>> + pr_err("Hash algorithm %s not supported by crypto
>>> API\n",
>>> + sig->hash_algo);
>>> cert->unsupported_sig = true;
>>> return 0;
>>> }
>>>
>>> If the pr_err() is hit then check the status of the corresponding
>>> CONFIG_CRYPTO_
>>> option in your .config, for example CONFIG_CRYPTO_SHA256 if the algorithm is
>>> "sha256".
>>>
>>
>> Hi Eric,
>> in the meantime I have moved to rc8, and the problem has disappeared.
>> Does this ring any bell? Otherwise, I'll retry with rc7 after adding
>> your error message.
>>
>> Thanks,
>> Paolo
>>
>
> No, it doesn't ring a bell. Is it possible you changed your kernel config
> between rc7 and rc8?
I have used the same procedure to generate for both configs: with a
4.14 running,
./scripts/kconfig/streamline_config.pl > ~/linux-build/.config
Unfortunately, I have overwritten the config I used for rc7. I'll
repeat my workflow for rc7 and get back to you.
Thanks,
Paolo
