From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: David Howells <dhowells@redhat.com>
Cc: linux-integrity@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
David Woodhouse <dwmw2@infradead.org>,
keyrings@vger.kernel.org
Subject: Re: [PATCH v8 1/8] lib: add ASN.1 encoder
Date: Thu, 19 Mar 2020 10:31:26 -0700 [thread overview]
Message-ID: <1584639086.3610.28.camel@HansenPartnership.com> (raw)
In-Reply-To: <3180269.1584636439@warthog.procyon.org.uk>
On Thu, 2020-03-19 at 16:47 +0000, David Howells wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> > + * Copyright (C) 2019 James.Bottomley@HansenPartnership.com
>
> 2020?
Actually, no, under the Berne convention it should be the date the work
was committed to a fixed medium. In theory, that's the first git
commit I did in my internal repository. There's a lot of wiggle room
in this: authors tend to use the date the manuscript was completed, not
when it was started, for instance, but 2019 would seem to be the more
accurate year even so.
> > +unsigned char *
> > +asn1_encode_integer(unsigned char *data, const unsigned char
> > *end_data,
> > + s64 integer);
>
> I wonder if we should actually use u8 rather than unsigned char for
> data pointers like this. That applies to asn1_ber_decoder() also.
I followed exactly what you did in asn1_decoder.c ... I think there's
value in having a completely signature consistent interface. Of
course, if you want to alter the encoder and decoder to u8 that can be
done as a follow on patch.
> You should be able to precalculate the length from fls64() or
> ilog2(), e.g.:
>
> static size_t asn1_uint_len(unsigned long long integer)
> {
> size_t l = integer ? fls64(integer) : 1;
> return l / 8 + 1;
> }
>
> See attached toy program.
We can, but it adds a lot of complexity for pretty much no gain: it's
no real hassle to begin the encoding and then find the buffer is too
short, and the code is definitely much easier to follow.
> > +/**
> > + * asn1_encode_tag() - add a tag for optional or explicit value
> > + * @data: pointer to place tag at
> > + * @end_data: end of data pointer, points one beyond last
> > usable byte in @data
> > + * @tag: tag to be placed
> > + * @string: the data to be tagged
> > + * @len: the length of the data to be tagged
> > + *
> > + * Note this currently only handles short form tags < 31. To
> > encode
> > + * in place pass a NULL @string and -1 for @len; all this will do
> > is
> > + * add an indefinite length tag and update the data pointer to the
> > + * place where the tag contents should be placed. After the data
> > is
> > + * placed, repeat the prior statement but now with the known
> > length.
> > + * In order to avoid having to keep both before and after
> > pointers,
> > + * the repeat expects to be called with @data pointing to where
> > the
> > + * first encode placed it.
> > + */
>
> I wonder if it's worth appending a note to the comment that if
> indefinite length encoding is selected, then the result is not DER-
> compliant and may not be CER-compliant since you're advertising
> BER/DER/CER.
We only encode definite length currently, so the comment is superfluous
(and probably confusing if you don't know the difference between
DER/BER and CER). Let's add something like this iff we ever start to
use indefinite lengths in the encoder.
> > + if (*data_len < 1)
> > + return -EINVAL;
>
> ENOBUFS? I guess it doesn't really matter.
This error gets sent to the user who's not doing to know why because
it's a kernel internal length we got wrong ... let's just keep EINVAL
which is our default "something went wrong" error.
> David
> ---
> #include <stdio.h>
>
> static inline int fls64(unsigned long long x)
> {
> int bitpos = -1;
> /*
> * AMD64 says BSRQ won't clobber the dest reg if x==0; Intel64
> says the
> * dest reg is undefined if x==0, but their CPU architect says
> its
> * value is written to set it to the same as before.
> */
> asm("bsrq %1,%q0"
> : "+r" (bitpos)
> : "rm" (x));
> return bitpos + 1;
> }
>
> static const unsigned long long vals[] = {
> 0x1000000, 0xffffff, 0x800000, 0x7fffff,
> 0x100000, 0xfffff, 0x80000, 0x7ffff,
> 0x10000, 0xffff, 0x8000, 0x7fff,
> 0x1000, 0xfff, 0x800, 0x7ff,
> 0x100, 0xff, 0x80, 0x7f,
> 3, 2, 1, 0
> };
>
> static size_t asn1_uint_len(unsigned long long integer)
> {
> size_t l = integer ? fls64(integer) : 1;
> return l / 8 + 1;
> }
>
> int main()
> {
> const unsigned long long *p = vals;
> unsigned long long integer;
>
> do {
> integer = *p++;
> printf("len: %16llx -> %zu\n", integer,
> asn1_uint_len(integer));
> } while (integer);
> }
>
next prev parent reply other threads:[~2020-03-19 17:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 5:15 [PATCH v8 0/8] TPM 2.0 trusted keys with attached policy James Bottomley
2020-03-10 5:16 ` [PATCH v8 1/8] lib: add ASN.1 encoder James Bottomley
2020-03-19 16:47 ` David Howells
2020-03-19 17:31 ` James Bottomley [this message]
2020-03-19 19:12 ` David Howells
2020-03-19 20:07 ` James Bottomley
2020-03-19 19:16 ` Eric Biggers
2020-03-10 5:16 ` [PATCH v8 2/8] oid_registry: Add TCG defined OIDS for TPM keys James Bottomley
2020-03-19 16:48 ` David Howells
2020-03-10 5:16 ` [PATCH v8 3/8] security: keys: trusted: fix TPM2 authorizations James Bottomley
2020-03-10 5:16 ` [PATCH v8 4/8] security: keys: trusted: use ASN.1 TPM2 key format for the blobs James Bottomley
2020-03-10 5:16 ` [PATCH v8 5/8] security: keys: trusted: Make sealed key properly interoperable James Bottomley
2020-03-10 5:16 ` [PATCH v8 6/8] security: keys: trusted: add PCR policy to TPM2 keys James Bottomley
2020-03-19 16:57 ` David Howells
2020-03-19 18:59 ` James Bottomley
2020-03-10 5:16 ` [PATCH v8 7/8] security: keys: trusted: add ability to specify arbitrary policy James Bottomley
2020-03-10 5:16 ` [PATCH v8 8/8] security: keys: trusted: implement counter/timer policy James Bottomley
-- strict thread matches above, loose matches on Subject: below --
2020-03-10 5:09 [PATCH v8 0/8] TPM 2.0 trusted keys with attached policy James Bottomley
2020-03-10 5:09 ` [PATCH v8 1/8] lib: add ASN.1 encoder James Bottomley
2020-03-10 15:22 ` James Bottomley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1584639086.3610.28.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).