Re: ASN.1

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

On Tue May 21, 2024 at 9:01 PM EEST, Jarkko Sakkinen wrote:
> On Tue May 21, 2024 at 6:20 PM EEST, Jarkko Sakkinen wrote:
> > On Tue May 21, 2024 at 5:52 PM EEST, Miguel Ojeda wrote:
> > 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 ;-)
>
> Hey, sorry I was mixing things a bit so let me clear this up!
>
> The decoder works as follows. There is a compiler, which generates
> bytecode object linked to vmlinux and a header with symbol declaration.
> Then there is a asn1_ber_decoder(), which runs the bytecode through a
> trivial interpreter with e.g. a key blob as parameter.
>
> And this part is great and it does not really get in the way. All of
> kernel uses it to parse ber/der/cer blobs in, and it is somewhat stable,
> and super well tested. For decoder the value of Rust is not that great.
>
> Encoder (asn1_encoder.c) is just a set of basic functions, like one
> function per tagged type to serialize that type. Most valuable asset
> would be to replicate this set in Rust with better defined contraints
> etc.
>
> Sorry for longish explanation, just wanted to clear up this story :-)
> I.e encoder is higher value asset than the decoder as far as I'm
> concerned, despite being much more trivial to implement.

For the patch set I'm working on I do have good solution. I only need to
encode this:

RsaPubKey ::= SEQUENCE {
	n INTEGER ({ rsa_get_n }),
	e INTEGER ({ rsa_get_e })
}

And nice thing is that e is always 65537 and length of e is always 3
i.e. {3} serialized so it is serialized as

	static const u8 EXPONENT[5] = {0x02, 1, 0x01, 0x01, 0x01};

Sequence and n can be expressed along the lines of

	/* Last two bytes are filled with 16-bit big-endian length: */
	u8 sequence[] = {0x30, 0x82, 0x00, 0x00};
	u8 n_head[] = {0x02, 0x82, 0x00, 0x00};

So I just copy stuff in order:

1. sequence
2. n_head
3. n (contents)
4. e

And this is along the line what I'm actually going to do because it is
stable for the use case. However, it would be nice that instead of such
sudoku there would be super stable Rust functions to take care of
writing these. This particular use case is sorted and I'll be fine, but
these pop up from time to time in different situations.

The problem with encoders I found for Rust from crates.io is that they
are like too bounded to the type system of Rust by implementing
conversion traits (From, Into etc.) available. Instead of this approach
for it might be more feasible to have dummy functions with no mangling
in the symbols like encode_sequence, encode_integer etc. You can always
use these dummy global functions to implement those fancy traits and
provide bridge for C at the same time and direct as possible access to
the actual functionality.

I think this is simple but very nice and usable pattern for bridging
from C to Rust provided services.

BR, Jarkko