Messages in this thread | | | Date | Mon, 10 Apr 2023 22:30:45 +0800 | Subject | Re: [RFC PATCH net-next v4 0/9] net/smc: Introduce SMC-D-based OS internal communication acceleration | From | Wen Gu <> |
| |
Hi Niklas,
On 2023/4/6 01:04, Niklas Schnelle wrote:
> > Let me just spell out some details here to make sure we're all on the > same page. > > You're assuming that GIDs are generated randomly at cryptographic > quality. In the code I can see that you use get_random_bytes() which as > its comment explains supplies the same quality randomness as > /dev/urandom so on modern kernels that should provide cryptographic > quality randomness and be fine. Might be something to keep in mind for > backports though. > > The fixed CHID of 0xFFFF makes sure this system identity confusion can > only occur between SMC-D loopback (and possibly virtio-ism?) never with > ISM based SMC-D or SMC-R as these never use this CHID value. Correct?
Yes, CHID of 0xFFFF used for SMC-D loopback ensures the GID collision won't involve ISM based SMC-D or SMC-R.
> > Now for the collision scenario above. As I understand it the > probability of the case where fallback does *not* occur is equivalent > to a 128 bit hash collision. Basically the random 64 bit GID_A > concatenated with the 64 bit DMB Token_A needs to just happen to match > the concatenation of the random 64 bit GID_B with DMB Token_B.
Yes, almost like this.
A very little correction: Token_A happens to match a DMB token in B's kernel (not necessary Token_B) and Token_B happens to match a DMB token in A's kernel (not necessary Token_A).
With > that interpretation we can consult Wikipedia[0] for a nice table of how > many random GID+DMB Token choices are needed for a certain collision > probability. For 128 bits at least 8.2×10^11 tries would be needed just > to reach a 10^-15 collision probability. Considering the collision does > not only need to exist between two systems but these also need to try > to communicate with each other and happen to use the colliding DMBs for > things to get into the broken fallback case I think from a theoretical > point of view this sounds like neglible risk to me. > Thanks for the reference data.
> That said I'm more worried about the fallback to TCP being broken due > to a code bug once the GIDs do match which is already extremely > unlikely and thus not naturally tested in the wild. Do we have a plan > how to keep testing that fallback scenario somehow. Maybe with a > selftest or something? >
IIUC, you are worried about the code implementation of fallback when GID collides but DMB token check works? If so, I think we can provide a way to set loopback device's GID manually, so that we can inject GID collision fault to test the code.
> If we can solve the testing part then I'm personally in favor of this > approach of going with cryptograhically random GID and DMB token. It's > simple and doesn't depend on external factors and doesn't need a > protocol extension except for possibly reserving CHID 0xFFFF. > > One more question though, what about the SEID why does that have to be > fixed and at least partially match what ISM devices use? I think I'm > missing some SMC protocol/design detail here. I'm guessing this would > require a protocol change?
SEID related topic will be replied in the next e-mail. > > Thanks, > Niklas > > [0] https://en.wikipedia.org/wiki/Birthday_attack >
Thanks! Wen Gu
| |