Alexey Kardashevskiy wrote:
[..]
> > Otherwise, at pci_ide_stream_setup() time I expect that the core would
> > need to do something gross like check the incoming Stream ID and walk
> > all idle streams to make sure they are not aliasing that ID.
>
> This is what PCIe spec suggests doing now imho.
Ok, I am about to send out v2, let's follow on to that with an
implementation that simply sets all idle stream indexes to Stream ID
255. Then, catch cases where the low-level TSM driver tries to use ID
255. This is on the assumption that most implementations will allocate
starting from zero.
> >>>> And then what are we doing to do when we start adding link streams? I
> >>>> suggest decoupling pci_ide::stream_id from stream_id in sel_ide_offset()
> >>>> (which is more like selective_stream_index) from the start.
> >>>
> >>> Setting aside that I agree with you that Stream index be separated from
> >>> from Stream ID, what would motivate Linux to consider setting up Link
> >>> Stream IDE?
> >>>
> >>> One of the operational criticisms of Link IDE is that it requires adding
> >>> more points of failure into the TCB where a compromised switch can snoop
> >>> traffic. It also adds more Keys and their associated maintainenace
> >>> overhead. So, before we start planning ahead for Link IDE and Selective
> >>> Stream IDE to co-exist in the implementation, I think we need a clear
> >>> use case that demonstrates Link IDE is going to graduate from the
> >>> specification into practical deployments.
> >>
> >> Probably for things like CXL which connect directly to the soc? I do not
> >> really know, I only touch link streams because of that only device which
> >> is like to see the light of the day though.
> >
> > CXL TSP is a wholly separate operation model and it expects that CXL
> > devices, and more specifically CXL memory, are inside the TCB before the
> > OS boots. So there is no current need for Linux to consider Link IDE for
> > CXL.
>
> Link IDE or any IDE? I know very little about CXL but some of those
> device types are not just simple fast memory but also do read/write
> from/to that memory so they cannot rely on CPU memory encryption and IDE
> makes sense for those (especially Link IDE as there are no bridges, or
> are there?). Thanks,
So there are 2 use cases CXL.cache and CXL.mem, and of CXL.mem there is
general memory expansion and accelerator memory. Most of the devices in
the market and the sole focus of the CXL TSP (TEE Security Protocol)
specification is how to get CXL.mem from general memory expansion
devices (Type-3) into the TCB. From the spec:
"This CXL security content scope focuses on features that are needed for
confidential computing utilizing CXL Type 3 memory expander devices"
The TSP definition specifies that CXL.mem memory is brought into the TCB
by pre-OS software.
It goes on to say, "Transport security is optional for TSP", i.e. IDE is
optional. If you have initiator based memory encryption then you do not
also need encryption on the transport.
So, IDE is optional and any optional IDE establishment will be by pre-OS
software. There is nothing I can see from CXL-land threatening to make
the Linux IDE implementation care about Link IDE.
