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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx/ 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 *sig > > as 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
