On 4/3/25 11:57, Dan Williams wrote:
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:
(self educating now)
So CXL.io is not a thing, or not going to support TSP?
Wiki mentions IO registers and DMA, not relevant here why? Thanks,
"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.
--
Alexey
