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 17:31:26 +0000 [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);
> }
>
WARNING: multiple messages have this Message-ID (diff)
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: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 5:09 [PATCH v8 0/8] TPM 2.0 trusted keys with attached policy James Bottomley
2020-03-10 5:09 ` James Bottomley
2020-03-10 5:09 ` [PATCH v8 1/8] lib: add ASN.1 encoder James Bottomley
2020-03-10 5:09 ` James Bottomley
2020-03-10 15:22 ` James Bottomley
2020-03-10 15:22 ` James Bottomley
2020-03-10 5:15 ` [PATCH v8 0/8] TPM 2.0 trusted keys with attached policy James Bottomley
2020-03-10 5:15 ` James Bottomley
2020-03-10 5:16 ` [PATCH v8 1/8] lib: add ASN.1 encoder James Bottomley
2020-03-10 5:16 ` James Bottomley
2020-03-19 16:47 ` David Howells
2020-03-19 17:31 ` James Bottomley [this message]
2020-03-19 17:31 ` James Bottomley
2020-03-19 19:12 ` David Howells
2020-03-19 20:07 ` James Bottomley
2020-03-19 20:07 ` James Bottomley
2020-03-19 19:16 ` Eric Biggers
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-10 5:16 ` 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 ` 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 ` 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 ` James Bottomley
2020-03-10 5:16 ` [PATCH v8 6/8] security: keys: trusted: add PCR policy to TPM2 keys James Bottomley
2020-03-10 5:16 ` James Bottomley
2020-03-19 16:57 ` David Howells
2020-03-19 18:59 ` James Bottomley
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 ` James Bottomley
2020-03-10 5:16 ` [PATCH v8 8/8] security: keys: trusted: implement counter/timer policy James Bottomley
2020-03-10 5:16 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.