linux-kernel - Re: New NTB API Issue

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] [day] [month] [year] [list]

Message-ID: <ea75d9cf-a6c6-29bc-c553-2f0a965bcaa2@deltatee.com>
Date:   Fri, 23 Jun 2017 17:06:40 -0600
From:   Logan Gunthorpe <logang@...tatee.com>
To:     Allen Hubbe <Allen.Hubbe@...l.com>, 'Jon Mason' <jdmason@...zu.us>
Cc:     linux-ntb@...glegroups.com, linux-kernel@...r.kernel.org,
        'Dave Jiang' <dave.jiang@...el.com>,
        'Serge Semin' <fancer.lancer@...il.com>,
        'Kurt Schwemmer' <kurt.schwemmer@...rosemi.com>,
        'Stephen Bates' <sbates@...thlin.com>,
        'Greg Kroah-Hartman' <gregkh@...uxfoundation.org>
Subject: Re: New NTB API Issue



On 23/06/17 04:06 PM, Allen Hubbe wrote:
> From: Logan Gunthorpe
>> But any translation can be
>> programmed by any peer.
> 
> That doesn't seem safe.  Even though it can be done as you say, would it not be better to have each specific translation under the control of exactly one driver?
> 
> If drivers can reach across and set the translation of any peer bar, they would still need to negotiate among N peers which one sets which other's translation.

Yup. In a dual host setup its not a problem seeing only the one peer
will ever set any of the memory windows. In the multi-host setup, there
has to be implicit or explicit negotiation as to which memory window
connects to which peer.

The hardware also implements locking so if two peers try to mess with
the same translation, the worst that can happen is the last peer's
settings will take effect or one peer will see an error.

Logan