Re: ASN.1

["Jarkko Sakkinen" <jarkko@kernel.org>]

On Tue May 21, 2024 at 5:52 PM EEST, Miguel Ojeda wrote:
> Hi Jarkko,
>
> On Tue, May 21, 2024 at 8:36 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > So question is how to approach this? How the holding data structure for
> > holding the deserialized data should represented so that is is also
> > directly accessible from C?
>
> Daniel (Cc'd) is working on in-kernel Rust codecs and is experimenting
> with `cbindgen` support to easily provide an API for C code (of
> course, you can do it manually too), so you may want to talk :) He
> recently wrote this article on it: https://lwn.net/Articles/970565/
>
> The main issue with a parallel implementation is whether the relevant
> maintainers will be OK with keeping both versions alive in the kernel.
> As usual, some ideas that may help offsetting the maintenance cost may
> be showcasing a security benefit, or a performance improvement, or a
> complexity reduction, or an avoidance of unsafe code, etc.

For me the main use case would be loading of keys (I co-maintain
keyring).

For keyring the ASN.1 C-API is actually quite good in the sense that
callbacks in parsing and sequential encoding are great at not conserving
memory (actually zero consumption almost). In that sense I'm happy with
it.

It is just hard to modify in the sense that it is very prone to
off-by-one errors and such.

Here's an example of a patch set that I wrote over the weekend for
asymmetric keys:

https://lore.kernel.org/linux-integrity/20240521031645.17008-1-jarkko@kernel.org/

In this case I could imagine loading ASN.1 blob by calling Rust
functions. But yeah more like "immediate mode" API rather than "retained
mode" style ;-)

> Cheers,
> Miguel

BR, Jarkko