[svsm-devel] vTPM service attestation format update

[Dionna Amalie Glaze]

On Thu, Mar 27, 2025 at 4:37 AM Geoffrey Ndu <gndu8086 at gmail.com> wrote:
>
> I believe it would be helpful to add the error code as a read-only
> attribute in configfs
>

After closer inspection, I think that we should probably generalize
this to report the svsm protocol error.
For vTPM, then, we'd want to reserve perhaps the first 256 numbers for
administrative errors for the service, but then use the rest for the
TPM_RC.
Adding the TPM_RC to PROTOCOL_BASE + 0x100 will not overflow the 32
bits for the error code since the top 20 bits are specified to be 0.
So I'll add a service_error attribute to tsm/report. Given the way
tsm_report_state is separated from tsm_report, it will be ugly to add
the administrative fields back in to limit the visibility to equal
read/write generations, so I'll just make it available if SVSM is
available.

> Geoffrey
>
> On Wed, Mar 26, 2025 at 9:02 PM Dionna Amalie Glaze
> <dionnaglaze at google.com> wrote:
> >
> > As the selector is used to drive a create_primary command, it's
> > possible for the command to fail before getting to the attestation
> > report creation.
> > If this svsm attestation report fails with invalid_parameter, then
> > sev-guest will retry in a loop thinking the only way for the request
> > to fail is due to output buffer sizes being wrong.
> >
> > I think in addition to the selector address and length, I'll use the
> > would-be-reserved 4 following bytes for an error code related to the
> > selector.  If this is set, then the attestation should not be retried.
> > Does it make sense to add the error code as a RO configfs attribute?
> > We can make it visible only if the write generation is the same as the
> > generation it was when the error code was recorded.
> >
> > On Fri, Mar 7, 2025 at 9:51 AM Dionna Amalie Glaze
> > <dionnaglaze at google.com> wrote:
> > >
> > > On Fri, Mar 7, 2025 at 6:24 AM James Bottomley
> > > <James.Bottomley at hansenpartnership.com> wrote:
> > > >
> > > > On Fri, 2025-03-07 at 11:48 +0000, Geoffrey Ndu wrote:
> > > > > Since the single_service_manifest call for the vTPM effectively
> > > > > certifies EKs, why don’t the “selector” be the handle values for EK
> > > > > certificates, as specified by the TCG in 2.2.2.5.1 of “TCG EK
> > > > > Credential Profile For TPM Family 2.0; Level 0”? This approach would
> > > > > simplify the user experience, as every SVSM would function
> > > > > identically, and  SVSM vTPMs would exhibit analogous behaviour to
> > > > > physical TPMs.
> > > >
> > > > Because to make life easier we might want to short circuit the EK/AK
> > > > makecredential/activatecredential round trip and simply construct a
> > > > signing EK to use in place of an arbitrary AK.  Then to make the
> > > > signing EK easily useful, we might want it not to have a policy
> > > > statement tying it to the endorsement hierarchy password (particularly
> > > > as we know that will be empty).  To allow this type of thing we need to
> > > > allow flexibility in the EK creation which isn't listed in the TCG
> > > > profile EK templates.
> > > >
> > >
> > > I have local changes to tpm-rs that I haven't pushed to make this
> > > commit work on its own, but this is what I'm prototyping.
> > >
> > > https://github.com/coconut-svsm/svsm/commit/db1ad6018b04b995e0278455eb2f9a66569cbcc9
> > >
> > > > Regards,
> > > >
> > > > James
> > > >
> > >
> > >
> > > --
> > > -Dionna Glaze, PhD, CISSP, CCSP (she/her)
> >
> >
> >
> > --
> > -Dionna Glaze, PhD, CISSP, CCSP (she/her)



-- 
-Dionna Glaze, PhD, CISSP, CCSP (she/her)