Aneesh Kumar K.V wrote:
> Dan Williams <dan.j.williams@xxxxxxxxx> writes:
>
> > +/**
> > + * enum pci_tsm_req_scope - Scope of guest requests to be validated by TSM
> > + *
> > + * Guest requests are a transport for a TVM to communicate with a TSM + DSM for
> > + * a given TDI. A TSM driver is responsible for maintaining the kernel security
> > + * model and limit commands that may affect the host, or are otherwise outside
> > + * the typical TDISP operational model.
> > + */
> > +enum pci_tsm_req_scope {
> > + /**
> > + * @PCI_TSM_REQ_INFO: Read-only, without side effects, request for
> > + * typical TDISP collateral information like Device Interface Reports.
> > + * No device secrets are permitted, and no device state is changed.
> > + */
> > + PCI_TSM_REQ_INFO = 0,
> > + /**
> > + * @PCI_TSM_REQ_STATE_CHANGE: Request to change the TDISP state from
> > + * UNLOCKED->LOCKED, LOCKED->RUN. No any other device state,
> > + * configuration, or data change is permitted.
> > + */
> > + PCI_TSM_REQ_STATE_CHANGE = 1,
> > + /**
> > + * @PCI_TSM_REQ_DEBUG_READ: Read-only request for debug information
> > + *
> > + * A method to facilitate TVM information retrieval outside of typical
> > + * TDISP operational requirements. No device secrets are permitted.
> > + */
> > + PCI_TSM_REQ_DEBUG_READ = 2,
> > + /**
> > + * @PCI_TSM_REQ_DEBUG_WRITE: Device state changes for debug purposes
> > + *
> > + * The request may affect the operational state of the device outside of
> > + * the TDISP operational model. If allowed, requires CAP_SYS_RAW_IO, and
> > + * will taint the kernel.
> > + */
> > + PCI_TSM_REQ_DEBUG_WRITE = 3,
> > +};
> > +
>
> Will all architectures need to support all the above pci_tsm_req_scope
> values?
Are you confusing this new "enum pci_tsm_req_scope" proposal with the
previous "struct pci_tsm_guest_req_info" proposal.
>
> For example, on ARM, I’ve implemented a simpler approach [1] by using an
> architecture-specific pci_tsm_req_scope / type. This simplifies
> the implementation, as I can access `info->req` and `info->resp`
> directly within the same callback, without needing an additional
> structure to carry arch-specific request types like
> `ARM_CCA_DA_OBJECT_SIZE` or `ARM_CCA_DA_OBJECT_READ`.
So both of those are both PCI_TSM_REQ_INFO scope.
The observation is that Linux already has an opaque blob passing
mechanism wrapped by a security model, fwctl. The proposal is just
reuse those mechanics, skip a wrapper struct for the arguments, and let
the low level handler be responsible for response buffer allocation.
