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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <95c8a200842de2a78af89ad2d5c051db0577fdfe.camel@redhat.com>
Date:   Tue, 04 Dec 2018 14:02:01 -0500
From:   Doug Ledford <dledford@...hat.com>
To:     Leon Romanovsky <leon@...nel.org>,
        Jason Gunthorpe <jgg@...lanox.com>
Cc:     Leon Romanovsky <leonro@...lanox.com>,
        RDMA mailing list <linux-rdma@...r.kernel.org>,
        Artemy Kovalyov <artemyko@...lanox.com>,
        Yishai Hadas <yishaih@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        linux-netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH rdma-next 0/7] Enrich DEVX support

On Mon, 2018-11-26 at 08:28 +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@...lanox.com>
> 
> From Yishai,
> -----------------------------------
> This series enriches DEVX support in few aspects: it enables interoperability
> between DEVX and verbs and improves mechanism for controlling privileged DEVX
> commands.
> 
> The first patch updates mlx5 ifc file.
> 
> Next 3 patches enable modifying and querying verbs objects via the DEVX
> interface.
> 
> To achieve that the core layer introduced the 'UVERBS_IDR_ANY_OBJECT' type
> to match any IDR object. Once it's used by some driver's method, the
> infrastructure skips checking for the IDR type and it becomes the driver
> handler responsibility.
> 
> The DEVX methods of modify and query were changed to get any object type via
> the 'UVERBS_IDR_ANY_OBJECT' mechanism. The type checking is done per object as
> part of the driver code.
> 
> The next 3 patches introduce more robust mechanism for controlling privileged
> DEVX commands. The responsibility to block/allow per command was moved to be
> done in the firmware based on the UID credentials that the driver reports upon
> user context creation. This enables more granularity per command based on the
> device security model and the user credentials.
> 
> In addition, by introducing a valid range for 'general commands' we prevent the
> need to touch the driver's code any time that a new future command will be
> added.
> 
> The last patch fixes the XRC verbs flow once a DEVX context is used. This is
> needed as XRCD is some shared kernel resource and as such a kernel UID (=0)
> should be used in its related resources.
> 
> Thanks
> 
> Yishai Hadas (7):
>   net/mlx5: Update mlx5_ifc with DEVX UCTX capabilities bits
>   IB/core: Introduce UVERBS_IDR_ANY_OBJECT
>   IB/core: Enable getting an object type from a given uobject
>   IB/mlx5: Enable modify and query verbs objects via DEVX
>   IB/mlx5: Enforce DEVX privilege by firmware
>   IB/mlx5: Update the supported DEVX commands
>   IB/mlx5: Allow XRC usage via verbs in DEVX context
> 
>  drivers/infiniband/core/rdma_core.c   |  27 +++--
>  drivers/infiniband/core/rdma_core.h   |  21 ++--
>  drivers/infiniband/core/uverbs_uapi.c |  10 +-
>  drivers/infiniband/hw/mlx5/devx.c     | 142 ++++++++++++++++++++++----
>  drivers/infiniband/hw/mlx5/main.c     |   4 +-
>  drivers/infiniband/hw/mlx5/mlx5_ib.h  |   6 +-
>  drivers/infiniband/hw/mlx5/qp.c       |  12 +--
>  drivers/infiniband/hw/mlx5/srq.c      |   2 +-
>  include/linux/mlx5/mlx5_ifc.h         |  26 ++++-
>  include/rdma/uverbs_ioctl.h           |   6 ++
>  include/rdma/uverbs_std_types.h       |  12 +++
>  11 files changed, 215 insertions(+), 53 deletions(-)
> 
> --
> 2.19.1
> 

Hi Leon,

I've put this into my wip/dl-for-next branch.  Because it pulled in the
mlx5-next tree (which was significant because the patch we wanted was at
the tip and a whole slew of other patches were before it), the changeset
for this patch looks much bigger.  And it had the merge conflict you
mentioned.  You might want to double check my work before it gets moved
over to the official for-next branch.

-- 
Doug Ledford <dledford@...hat.com>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ