Make a marshallable interface/type constraint

[chrisfenner]

Make a marshallable interface/type constraint

[chrisfenner]

Let's add a Go1.18 type constraint for this:

There's tons of types, so we can divide them by category:

type TPMA interface {
  TPMAAlgorithm | TPMAObject | TPMASession | TPMALocality | ...
}

type Marshallable  interface {
  TPMA | TPMT | TPMS | ...
}

While we're taking a dependency on Go1.18, let's also consider using type constraints for the unions:

// TPMUCapabilities represents a TPMU_CAPABILITIES.
// See definition in Part 2: Structures, section 10.10.1.
type TPMUCapabilities struct {
	Algorithms    *TPMLAlgProperty       `gotpm:"selector=0x00000000"` // TPM_CAP_ALGS
	Handles       *TPMLHandle            `gotpm:"selector=0x00000001"` // TPM_CAP_HANDLES
	Command       *TPMLCCA               `gotpm:"selector=0x00000002"` // TPM_CAP_COMMANDS
	PPCommands    *TPMLCC                `gotpm:"selector=0x00000003"` // TPM_CAP_PP_COMMANDS
	AuditCommands *TPMLCC                `gotpm:"selector=0x00000004"` // TPM_CAP_AUDIT_COMMANDS
	AssignedPCR   *TPMLPCRSelection      `gotpm:"selector=0x00000005"` // TPM_CAP_PCRS
	TPMProperties *TPMLTaggedTPMProperty `gotpm:"selector=0x00000006"` // TPM_CAP_TPM_PROPERTIES
	PCRProperties *TPMLTaggedPCRProperty `gotpm:"selector=0x00000007"` // TPM_CAP_PCR_PROPERTIES
	ECCCurves     *TPMLECCCurve          `gotpm:"selector=0x00000008"` // TPM_CAP_ECC_CURVES
	AuthPolicies  *TPMLTaggedPolicy      `gotpm:"selector=0x00000009"` // TPM_CAP_AUTH_POLICIES
	ACTData       *TPMLACTData           `gotpm:"selector=0x0000000A"` // TPM_CAP_ACT
}

// TPMSCapabilityData represents a TPMS_CAPABILITY_DATA.
// See definition in Part 2: Structures, section 10.10.2.
type TPMSCapabilityData struct {
	// the capability
	Capability TPMCap
	// the capability data
	Data TPMUCapabilities `gotpm:"tag=Capability"`
}

We can make marshalling trivial with a type constraint:

// TPMUCapabilities represents a TPMU_CAPABILITIES.
// See definition in Part 2: Structures, section 10.10.1.
type TPMUCapabilities interface {
	TPMLAlgProperty | TPMLHandle | TPMLCCA | TPMLCC | TPMLPCRSelection |TPMLTaggedTPMProperty | TPMLTaggedPCRProperty |TPMLECCCurve | TPMLTaggedPolicy | TPMLACTData
}

// TPMSCapabilityData represents a TPMS_CAPABILITY_DATA.
// See definition in Part 2: Structures, section 10.10.2.
type TPMSCapabilityData struct {
	// the capability
	Capability TPMCap
	// the capability data
	Data TPMUCapabilities
}

This has the added benefit of deleting a level of nesting:

parms := tpmu.PublicParms{
	ECCDetail: &tpms.ECCParms{
		Scheme: tpmt.ECCScheme{
			Scheme: tpm.AlgECDSA,
			Details: tpmu.AsymScheme{
				ECDSA: &tpms.SigSchemeECDSA{
					HashAlg: tpm.AlgSHA256,
				},
			},
		},
		CurveID: tpm.ECCNistP256,
	},
}

to

parms := tpmu.PublicParms{
	ECCDetail: &tpms.ECCParms{
		Scheme: tpmt.ECCScheme{
			Scheme: tpm.AlgECDSA,
			Details: tpms.SigSchemeECDSA{
				HashAlg: tpm.AlgSHA256,
			},
		},
		CurveID: tpm.ECCNistP256,
	},
}

However we have to do an extra step on the library side to make unmarshalling work. For each of the TPMU we have to define a "custom" unmarshalling function that checks the value of the selector and unmarshals a value of the correct corresponding type. This is not a big deal, given that there are about 18 or so TPMU structures - not too many to do by hand.

The Unmarshal function can check if a type implements customUnmarshallable and invoke the custom unmarshaller, and we can hide the details of this from the callers. Also, removing the TPMU handler type annotations from the library will simplify it at least enough to offset the complexity of adding an interface.

@josephlr @alexmwu WDYT?

[chrisfenner]

Similar to what we saw in #307, TPMU types can't be based on type constraints since they have to be types.