Hi Eric- > On Nov 12, 2021, at 1:49 PM, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Fri, Nov 12, 2021 at 12:39:52PM -0500, Chuck Lever wrote: >> This enables "# cat cert.pem | keyctl padd asymmetric <keyring>" >> >> Since prep->data is a "const void *" I didn't feel comfortable with >> pem_decode() simply overwriting either the pointer or the contents >> of the provided buffer. A secondary buffer is therefore allocated, >> and then later freed by .free_preparse. >> >> This compiles, but is otherwise untested. I'm interested in opinions >> about this approach. >> >> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> > > Why? You can easily convert PEM to DER in userspace, for example with a command > like 'openssl x509 -in cert.pem -out cert.der -outform der'. There's no need > for the kernel to do it. Correct, it's not a hard requirement. However, this change does broaden the add_key(2) API to enable it to accept a PEM-encoded certificate directly instead of needing to run the blob through an intermediate step, simplifying applications that might use it for adding X.509 keys to kernel keyrings. 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 . 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. -- Chuck Lever
