Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
MIME-Version: 1.0
References: <169570181657.596431.6178773442587231200.stgit@dwillia2-xfh.jf.intel.com>
 <169570182987.596431.14062417344858914481.stgit@dwillia2-xfh.jf.intel.com>
 <c3d347a7-58d6-4830-aad4-d354b83f0704@linux.intel.com> <CA+1=6yfmLXJbZu7Gd7cp_HOAbmHwx54aPgozWKBikWwZSYTOZw@mail.gmail.com>
 <6513e6079a427_91c1e294e@dwillia2-xfh.jf.intel.com.notmuch>
 <CA+1=6yeP6dDiXVQrxMt0AaEF_7S05p4Do67=ysXK-Chfvu-9ow@mail.gmail.com> <CAMkAt6ohEnYwC8yVzye0F4gApvuyktHDP-q8-p7gJnSAyRMR_Q@mail.gmail.com>
In-Reply-To: <CAMkAt6ohEnYwC8yVzye0F4gApvuyktHDP-q8-p7gJnSAyRMR_Q@mail.gmail.com>
From:   Thomas Fossati <thomas.fossati@linaro.org>
Date:   Wed, 27 Sep 2023 21:05:39 +0200
Message-ID: <CA+1=6yczjPCaPsVc+s9_HC-6pNk52VsFviMeqqDWR4v2RFDBjw@mail.gmail.com>
Subject: Re: [PATCH v4 2/6] configfs-tsm: Introduce a shared ABI for
 attestation reports
To:     Peter Gonda <pgonda@google.com>
Cc:     Dan Williams <dan.j.williams@intel.com>,
        linux-coco@lists.linux.dev,
        Dionna Amalie Glaze <dionnaglaze@google.com>,
        James Bottomley <James.Bottomley@hansenpartnership.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Samuel Ortiz <sameo@rivosinc.com>,
        Thomas Gleixner <tglx@linutronix.de>, peterz@infradead.org,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        dave.hansen@linux.intel.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Peter,

On Wed, 27 Sept 2023 at 16:38, Peter Gonda <pgonda@google.com> wrote:
>
> On Wed, Sep 27, 2023 at 2:25=E2=80=AFAM Thomas Fossati
> <thomas.fossati@linaro.org> wrote:
> >
> > On Wed, 27 Sept 2023 at 10:21, Dan Williams <dan.j.williams@intel.com> =
wrote:
> > > It can be expanded when/if those platforms expand the
> > > size of the supported user data, or another configfs-tsm backend arri=
ves
> > > that needs that capability.
> >
> > Makes sense, thanks.
>
> I'm not familiar with the rats eat spec but I would assume the
> protocol would acquire more than just the nonce in the inblob.
> Probably some combination of claims, nonce, and information about a
> public key?

Looking at existing EAT-based (or EAT-like) serialisations:

Arm CCA has a single, 64 bytes challenge (see =C2=A7A7 of =E2=80=9CRealm Ma=
nagement
Monitor (RMM) Specification=E2=80=9D [1].)

CoVE too, see [2].

Nitro instead is doing something different: GetAttestationDoc() has
optional user-provided public key, custom user data, and a custom
nonce passed in as separate input arguments [3].

So, what @inblob's structure looks like really is a choice of the
attester's vendor.

> Does the specification allow for the data needing to be
> signed by the TSM to be hashed first?

EAT per se is mostly agnostic, it has a flexible and extensible type
system, which can adapt to most attester =E2=80=9Cshapes=E2=80=9D.

Hope this answers your questions.

cheers, t

[1] https://developer.arm.com/documentation/den0137/latest
[2] https://github.com/riscv-non-isa/riscv-ap-tee/blob/main/specification/a=
ttestation.adoc#tvm-challenge-claim
[3] https://github.com/aws/aws-nitro-enclaves-nsm-api/blob/4b851f3006c6fa98=
f23dcffb2cba03b39de9b8af/nsm-lib/src/lib.rs#L218