On Fri, 2023-06-02 at 13:38 -0400, Linus Torvalds wrote:
On Fri, Jun 2, 2023 at 10:41 AM Roberto Sassu roberto.sassu@huaweicloud.com wrote:
sorry for this unusual procedure of me requesting a patch to be pulled. I asked for several months the maintainers (David: asymmetric keys, Jarkko: key subsystem) to pick my patch but without any luck.
Hmm.
The patch behind that tag looks sane to me, but this is not code I am hugely familiar with.
Who is the caller that passes in the public_key_signature data on the stack to public_key_verify_signature()? This may well be the right point to move it away from the stack in order to have a valid sg-list, but even if this patch is all good, it would be nice to have the call chain documented as part of the commit message.
Oh, it seems it was only in the first version of the patch:
https://lore.kernel.org/linux-kernel/20221104122023.1750333-1-roberto.sassu@...
Originally, the kernel panic was due to EVM, but I later found that IMA Appraisal could have caused the same.
I signed the tag, but probably it would not matter, since my key is not among your trusted keys.
It does matter - I do pull from people even without full chains, I just end up being a lot more careful, and I still want to see the signature for any future reference...
Ok, then it makes sense to push my key to a key server.
Thanks
Roberto
DavidH, Herbert, please comment:
https://github.com/robertosassu/linux.git tags/asym-keys-fix-for-linus-v6.4-rc5
basically public_key_verify_signature() is passed that
const struct public_key_signature *sigas an argument, and currently does
sg_init_table(src_sg, 2); sg_set_buf(&src_sg[0], sig->s, sig->s_size); sg_set_buf(&src_sg[1], sig->digest, sig->digest_size);on it which is *not* ok if the s->s and s->digest points to stack data that ends up not dma'able because of a virtually mapped stack.
The patch re-uses the allocation it already does for the key data, and it seems sane.
But again, this is not code I look at normally, so...
Linus