[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZuPDZL_EIoS60L1a@gondor.apana.org.au>
Date: Fri, 13 Sep 2024 12:45:24 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Roberto Sassu <roberto.sassu@...weicloud.com>
Cc: dhowells@...hat.com, dwmw2@...radead.org, davem@...emloft.net,
linux-kernel@...r.kernel.org, keyrings@...r.kernel.org,
linux-crypto@...r.kernel.org, zohar@...ux.ibm.com,
linux-integrity@...r.kernel.org, torvalds@...ux-foundation.org,
roberto.sassu@...wei.com
Subject: Re: [PATCH v3 00/14] KEYS: Add support for PGP keys and signatures
Roberto Sassu <roberto.sassu@...weicloud.com> wrote:
>
> For the envisioned use cases, PGP operations cannot be done in user space,
> since the consumers are in the kernel itself (Integrity Digest Cache and
> IMA). Also they cannot be done in a trusted initial ram disk, since PGP
> operations can occur also while the system is running (e.g. after software
> package installation).
Does this address Linus's objections? If not then we cannot proceed.
Personally I don't think the argument above holds water. With
IPsec we had a similar issue of authenticating untrusted peers
using public key cryptography. In that case we successfully
delegated the task to user-space and it is still how it works
to this day.
A user-space daemon dedicated to public key crypto seems equally
applicable to your scenario.
The original application that brought public key crypto into the
kernel was module loading. If we really wanted to we could extend
the user-space verification to modules too and perhaps kick all
public key crypto out of the kernel.
The complexity and lack of reviewer attention in this area means
that we're more likely to introduce security holes into the kernel
with such code.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists