> On Nov 13, 2021, at 6:02 PM, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Sat, Nov 13, 2021 at 07:12:44PM +0000, Chuck Lever III wrote: >> >> Certainly, the kernel could include a single set of base64 encoders >> and decoders that can be used by all in-kernel consumers. See for >> example net/ceph/armor.c and fs/crypto/fname.c . > > Not really, there are many variants of Base64 and different policy decisions > that can be made: the chosen character set, whether to pad or not pad, whether > to allow whitespace, how to handle invalid characters, how to handle invalid > padding, whether to nul-terminate, and so on. There's lots of room for bugs and > incompatibilities. > >> >> Because PEM decoding does not require any policy decisions, and >> because the kernel already has at least two existing partial >> base64 implementations, I'm not aware of a technical reason a >> system call like add_key(2) should not to accept PEM-encoded >> asymmetric key material. > > Adding kernel UAPIs expands the kernel's attack surface, causing security > vulnerabilities. It also increases the number of UAPIs that need to be > permanently supported. It makes no sense to add kernel UAPIs for things that > can be easily done in userspace. > > They work well as April Fools' jokes, though: > https://lore.kernel.org/r/1459463613-32473-1-git-send-email-richard@xxxxxx > Perhaps you meant to save your patch for April 1? That remark is uncalled for and out of line. Perhaps you just don't know what "strawman" means or why someone would post unfinished code to ask for direction. I'll mark that down to your inexperience. Interestingly, I don't see you listed as a maintainer in this area: $ scripts/get_maintainer.pl crypto/asymmetric_keys/ David Howells <dhowells@xxxxxxxxxx> (maintainer:ASYMMETRIC KEYS) Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> (maintainer:CRYPTO API) "David S. Miller" <davem@xxxxxxxxxxxxx> (maintainer:CRYPTO API) keyrings@xxxxxxxxxxxxxxx (open list:ASYMMETRIC KEYS) linux-crypto@xxxxxxxxxxxxxxx (open list:CRYPTO API) linux-kernel@xxxxxxxxxxxxxxx (open list) $ I actually /have/ talked with one of these maintainers, and he suggested PEM decoding under add_key(2) would be appropriate and valuable. It actually wasn't my idea. I shall credit his idea in the next version of this patch so there won't be any further confusion. -- Chuck Lever
