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:   Mon, 11 Jun 2018 09:19:14 +0300
From:   jackm <jackm@....mellanox.co.il>
To:     Jason Gunthorpe <jgg@...lanox.com>
Cc:     Leon Romanovsky <leon@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        hans.westgaard.ry@...cle.com, Doug Ledford <dledford@...hat.com>,
        Matthew Wilcox <mawilcox@...rosoft.com>,
        linux-rdma@...r.kernel.org,
        HÃ¥kon Bugge <haakon.bugge@...cle.com>,
        Parav Pandit <parav@...lanox.com>,
        Pravin Shedge <pravin.shedge4linux@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs

On Sun, 10 Jun 2018 22:42:03 -0600
Jason Gunthorpe <jgg@...lanox.com> wrote:

> Er, the spec has nothing to do with this. In Linux the TID is made
> unique because the core code provides 32 bits that are unique and the
> user provides another 32 bits that are unique. The driver cannot
> change any of those bits without risking non-uniquenes, which is
> exactly the bug mlx4 created when it stepped outside its bounds and
> improperly overrode bits in the TID for its own internal use.

Actually, the opposite is true here.
When SRIOV is active, each VM generates its *own* TIDs -- with 32 bits
of agent number and 32 bits of counter.

There is a  chance that two different VMs can generate the same TID!
Encoding the slave (VM) number in the packet actually guarantees
uniqueness here.
There is nothing wrong with modifying the TID in a reversible way in
order to:
a. guarantee uniqueness
b. identify the VM which should receive the response packet

The problem was created when the agent-id numbers started to use the
most-significant byte (thus making the MSB slave-id addition
impossible).

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ