linux-kernel - Re: [RFC PATCH net-next v4 0/9] net/smc: Introduce SMC-D-based OS internal communication acceleration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 06 Apr 2023 16:27:29 +0200
From:   Niklas Schnelle <schnelle@...ux.ibm.com>
To:     Alexandra Winter <wintera@...ux.ibm.com>,
        Wen Gu <guwen@...ux.alibaba.com>, kgraul@...ux.ibm.com,
        wenjia@...ux.ibm.com, jaka@...ux.ibm.com, davem@...emloft.net,
        edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com
Cc:     linux-s390@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH net-next v4 0/9] net/smc: Introduce SMC-D-based OS
 internal communication acceleration

On Thu, 2023-04-06 at 13:14 +0200, Alexandra Winter wrote:
> 
> On 05.04.23 19:04, Niklas Schnelle wrote:
> > 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?
> > 
> > Thanks,
> > Niklas
> 
> Niklas,
> in the initial SMC CLC handshake the client and server exchange the SEID (one per peer system)
> and up to 8 proposals for SMC-D interfaces.
> Wen's current proposal assumes that smc-d loopback can be one of these 8 proposed interfaces,
> iiuc. So on s390 the proposal can contain ISM devices and a smc-d loopback device at the same time.
> If one of the peers is e.g. an older Linux version, it will just ignore the loopback-device
> in the list (Don't find a match for CHID 0xFFFF) and use an ISM interface for SMC-D if possible.
> Therefor it is important that the SEID is used in the same way as it is today in the handshake.
> 
> If we decide for some reason (virtio-ism open issues?) that a protocol change/extension is
> required/wanted, then it is a new game and we can come up with new identifiers, but we may
> lose compatibility to backlevel systems.
> 
> Alexandra

Ok that makes sense to me. I was looking at the code in patch 4 of this
series and there it looks to me like SMC-D loopback as implemented
would always use the newly added SMCD_DEFAULT_V2_SEID might have
misread it though. From your description I think that would be wrong,
if a SEID is defined as on s390 it should use that SEID in the CLC for
all SMC variants. Similarly on other architectures it should use the
same SEID for SMC-D as for SMC-R, right? Also with partially match I
was actually wrong the SMCD_DEFAULT_V2_SEID.seid_string starts with
"IBM-DEF-ISMSEID…" while on s390's existing ISM we use "IBM-SYSZ-
ISMSEID…" so if SMC-D loopback correctly uses the shared SEID on s390
we can already only get GID.DMB collisions only on the same mainframe.

Thanks,
Niklas