Re: TDISP enablement

[Dan Williams <dan.j.williams@intel.com>]

Alexey Kardashevskiy wrote:
[..]
> > Next bit probably has holes...  Key is that a lot of the checks
> > may fail, and it's up to host userspace policy to decide whether
> > to proceed (other policy in the secure VM side of things obviously)
> > 
> > So my rough thinking is - for the two options (IDE / TDISP)
> > 
> > Comparing with Alexey's flow I think only real difference is that
> > I call out explicit host userspace policy controls. I'd also like
> 
> My imagination fails me :) What is the host supposed to do if the device 
> verification fails/succeeds later, and how much later, and the device is 
> a boot disk? Or is this userspace going to be limited to initramdisk? 
> What is that thing which we are protecting against? Or it is for CUDA 
> and such (which yeah, it can wait)?
> 
> > to use similar interfaces to convey state to host userspace as
> > per Lukas' existing approaches.  Sure there will also be in
> > kernel interfaces for driver to get data if it knows what to do
> > with it.  I'd also like to enable the non tdisp flow to handle
> > IDE setup 'natively' if that's possible on particular hardware.
> > 
> > 1. Host has a go at CMA/SPDM. Policy might say that a failure here is
> >     a failure in general so reject device - or it might decide it's up to
> >     the PSP etc.   (userspace can see if it succeeded)
> >     I'd argue host software can launch this at any time.  It will
> >     be a denial of service attack but so are many other things the host
> >     can do.
> 
> Trying to visualize it in my head - policy is a kernel cmdline or module 
> parameter?
> 
> > 2. TDISP policy decision from host (userspace policy control)
> >     Need to know end goal.
> 
> /sys/bus/pci/devices/0000:11:22.3/tdisp ?
> 
> > 3. IDE opt in from userspace.  Policy decision.
> >    - If not TDISP
> >      - device_connect(IDE ONLY) - bunch of proxying in host OS.
> >      - Cert chain and measurements presented to host, host can then check if
> >        it is happy and expose for next policy decision.
> >      - Hooks exposed for host to request more measurements, key refresh etc.
> >        Idea being that the flow is host driven with PSP providing required
> >        services.  If host can just do setup directly that's fine too.
> 
> I'd expect the user to want IDE on from the very beginning, why wait to 
> turn it on later? The question is rather if the user wants to panic() or 
> warn() or block the device if IDE setup failed.

Right, but when you run out of streams where is the policy to decide who
wins. That's why I was thinking lazy IDE when it is explicitly requested 
> 
> >    - If TDISP (technically you can run tdisp from host, but lets assume
> >      for now no one wants to do that? (yet)).
> >      - device_connect(TDISP) - bunch of proxying in host OS.
> >      - Cert chain and measurements presented to host, host can then check if
> >        it is happy and expose for next policy decision.
> 
> On AMD SEV TIO the TDISP setup happens in "tdi_bind" when the device is 
> about to be passed through which is when QEMU (==userspace) starts.
> 
> > 
> > 4. Flow after this depends on early or late binding (lockdown)
> >     but could load driver at this point.  Userspace policy.
> >     tdi-bind etc.
> 
> Not sure I follow this. A host or guest driver?
> 
> 
> >>
> >>> If the user wants only IDE, the AMD PSP's device_connect needs to be called
> >>> and the host OS does not get to know the IDE keys. Other vendors allow
> >>> programming IDE keys to the RC on the baremetal, and this also may co-exist
> >>> with a TSM running outside of Linux - the host still manages trafic classes
> >>> and streams.
> >>
> >> I'm wondering if your implementation is spec compliant:
> >>
> >> PCIe r6.1 sec 6.33.3 says that "It is permitted for a Root Complex
> >> to [...] use implementation specific key management."  But "For
> >> Endpoint Functions, [...] Function 0 must implement [...]
> >> the IDE key management (IDE_KM) protocol as a Responder."
> >>
> >> So the keys need to be programmed into the endpoint using IDE_KM
> >> but for the Root Port it's permitted to use implementation-specific
> >> means.
> >>
> >> The keys for the endpoint and Root Port are the same because this
> >> is symmetric encryption.
> >>
> >> If the keys are internal to the PSP, the kernel can't program the
> >> keys into the endpoint using IDE_KM.  So your implementation precludes
> >> IDE setup by the host OS kernel.
> > 
> > Proxy the CMA messages through the host OS. Doesn't mean host has
> > visibility of the keys or certs.  So indeed, the actual setup isn't being done
> > by the host kernel, but rather by it requesting the 'blob' to send
> > to the CMA DOE from PSP.
> > 
> > By my reading that's a bit inelegant but I don't see it being a break
> > with the specification.
> > 
> >>
> >> device_connect is meant to be used for TDISP, i.e. with devices which
> >> have the TEE-IO Supported bit set in the Device Capabilities Register.
> >>
> >> What are you going to do with IDE-capable devices which have that bit
> >> cleared?  Are they unsupported by your implementation?
> >>
> >> It seems to me an architecture cannot claim IDE compliance if it's
> >> limited to TEE-IO capable devices, which might only be a subset of
> >> the available products.
> > 
> > Agreed.  If can request the PSP does a non TDISP IDE setup then
> > I think we are fine.  If not then indeed usecases are limited and
> > meh, it might be a spec compliance issue but I suspect not as
> > TDISP has a note at the top that says:
> > 
> > "Although it is permitted (and generally expected) that TDIs will
> > be implemented such that they can be assigned to Legacy VMs, such
> > use is not the focus of TDISP."
> > 
> > Which rather implies that devices that don't support other usecases
> > are allowed.
> > 
> >>
> >>
> >>> The next steps:
> >>> - expose blobs via configfs (like Dan did configfs-tsm);
> >>> - s/tdisp.ko/coco.ko/;
q> >>> - ask the audience - what is missing to make it reusable for other vendors
> >>> and uses?
> >>
> >> I intend to expose measurements in sysfs in a measurements/ directory
> >> below each CMA-capable device's directory.  There are products coming
> >> to the market which support only CMA and are not interested in IDE or
> >> TISP.  When bringing up TDISP, measurements received as part of an
> >> interface report must be exposed in the same way so that user space
> >> tooling which evaluates the measurememt works both with TEE-IO capable
> >> and incapable products.  This could be achieved by fetching measurements
> >> from the interface report instead of via SPDM when TDISP is in use.
> > 
> > Absolutely agree on this and superficially it feels like this should not
> > be hard to hook up.
> 
> True. sysfs it is then. Thanks,
> 
> > 
> > There will also be paths where a driver wants to see the measurement report
> > but that should also be easy enough to enable.
> > 
> > Jonathan
> >>
> >> Thanks,
> >>
> >> Lukas
> >>
> > 
> 
> -- 
> Alexey
> 
>