linux-kernel - Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

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]

Message-ID: <20180514210200.GN21531@ziepe.ca>
Date:   Mon, 14 May 2018 15:02:00 -0600
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Håkon Bugge <haakon.bugge@...cle.com>
Cc:     Hal Rosenstock <hal@....mellanox.co.il>,
        Doug Ledford <dledford@...hat.com>,
        Don Hiatt <don.hiatt@...el.com>,
        Ira Weiny <ira.weiny@...el.com>,
        Sean Hefty <sean.hefty@...el.com>,
        OFED mailing list <linux-rdma@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and
 check eligibility of the pkeys

On Thu, May 10, 2018 at 05:16:28PM +0200, Håkon Bugge wrote:

> We are talking about two things here. The PKey in the BTH and the
> PKey in the CM REQ payload. They differ.
> 
> I am out of office, but if my memory serves me correct, the PKey in
> the BTH in the MAD packet will be the default PKey. Further, we have
> per IBTA:

This sounds like a Linux bug.

Linux does not do a PR to get a reversible path dedicated to the GMP,
so it always uses the data flow path, thus the GMP path paramenters
and those in the REQ should always exactly match.

Where is Linux setting the BTH.PKey and how did it choose to use the
default pkey? Lets fix that at least for sure.

Once that is fixed the rest of the series makes no sense since a REQ
with invalid PKey will never arrive.

However...

This series seems inconsistent with the spec.

IIRC the spec doesn't say if a full or limited pkey should be placed
in the REQ (Hal?). It is designed so that the requestor can get a
single reversible path and put that results into the REQ without
additional processing, however the PR returns only one PKey and again,
itis not really specified if it should be the full or limited pkey
(Hal?).

Basically this means that any pkey in the REQ could randomly be the
full or limited value, and that in-of-itself has not bearing on the
connection.

So it is quite wrong to insist that the pkey be limited or full when
processing the REQ. The end port is expected to match against the
local table.

The real answer to your trap problem is to fix the SM to not create
paths that are non-functional, that is just flat out broken SM
behavior.

Jason