linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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);
> }
> 


  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).