From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27D07C2D0E2 for ; Tue, 22 Sep 2020 11:49:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D484023600 for ; Tue, 22 Sep 2020 11:49:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="muDDi0pT" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727020AbgIVLtq (ORCPT ); Tue, 22 Sep 2020 07:49:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727004AbgIVLtl (ORCPT ); Tue, 22 Sep 2020 07:49:41 -0400 Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C6DEC061755 for ; Tue, 22 Sep 2020 04:49:41 -0700 (PDT) Received: by mail-qk1-x743.google.com with SMTP id w16so18644267qkj.7 for ; Tue, 22 Sep 2020 04:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=1D8ju+sMCrprb+0b/yOahK+eYVzPNlNBaX9NLNExdtI=; b=muDDi0pTHyd9JBABm8RyGLvWbVcMxru6wlVrHBiDJUY0jrq7Ma6mMxfMSYqQR2sE7S n6oWDLWu5dVTDb7iJrAWfjxmSdDqSDAJJW9NGZCBpfYbdyI9g1jOOFjEAzn7/UzcB7vf 6kHbhNt0CKfpSocliMKcT3ueUyylf+kgqxUPyKzVGLicVzXOW+EPcdqsXV6Z51wTI+Lq mFn1Jmghmfz+QaX+PmjcpkzNu4kwAmbrY1iH3ow2hdHyCneXpKtLqwPJ9kIdYF1wt1Fy 7Ad6pYgKKRqILeVv4+7BbG5JUDTj8gXQYUqzkQ2twtMOgHE/dr3KehrG6Q9VeF5IoCH0 WnTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1D8ju+sMCrprb+0b/yOahK+eYVzPNlNBaX9NLNExdtI=; b=ryZthdcfyySxfsT+3e1ItfVp9htiRcf+MG3JhP9gVVhJem+wXrnKPCSGHXr6F5+Kja 4hLhp9yG0fCDooWZ9lLABwAHmzmuny1UGwDLeFEm6FRotmPnKTGiCQ5Dds37Ejr5bDCq 31JEyRwg/mUIATwrRbCaEyT6nxXeE3HcyBLe59lprjhECo56/W34GmmFyqQBT6O2eda7 t+u46yMkPGdcBzh0On3hcGBrPzM7l2qivnbDfJEIjL0O7WdWhtiP45047CM0Z7NtQ0Yn Kax9LwgeWQq0fZm3fSxZhwp6muJdCx1UeaAxoKr2NtYxeGKlcm5gc9C6bmaamSUc+xV9 qkyA== X-Gm-Message-State: AOAM533ABkeu0t4AyEOr2WsWzJ4RaaGAz3aXglNBTx9smv4StomYaMw9 Ri6A6CL71QtB+utuKLMvzI7fVQ== X-Google-Smtp-Source: ABdhPJynCuK8vUTw9DbgSp3TWPoe/lJE1NnbKoGAO/to47jv50SynIh4q+Mrv7MDzz74la/2EhiNeA== X-Received: by 2002:a37:c203:: with SMTP id i3mr4203326qkm.155.1600775380815; Tue, 22 Sep 2020 04:49:40 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id q142sm11081340qke.48.2020.09.22.04.49.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Sep 2020 04:49:40 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kKgnj-0030YZ-N6; Tue, 22 Sep 2020 08:49:39 -0300 Date: Tue, 22 Sep 2020 08:49:39 -0300 From: Jason Gunthorpe To: Jakub Kicinski Cc: Oded Gabbay , Greg Kroah-Hartman , Leon Romanovsky , Gal Pressman , "Linux-Kernel@Vger. Kernel. Org" , netdev@vger.kernel.org, SW_Drivers , "David S. Miller" , Andrew Lunn , Florian Fainelli , linux-rdma@vger.kernel.org Subject: Re: [PATCH v3 00/14] Adding GAUDI NIC code to habanalabs driver Message-ID: <20200922114939.GF8409@ziepe.ca> References: <20200918121905.GU869610@unreal> <20200919064020.GC439518@kroah.com> <20200919082003.GW869610@unreal> <20200919083012.GA465680@kroah.com> <20200919172730.GC2733595@kroah.com> <20200919192235.GB8409@ziepe.ca> <20200920084702.GA533114@kroah.com> <20200921115239.GC8409@ziepe.ca> <20200921142053.1d2310f6@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200921142053.1d2310f6@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 21, 2020 at 02:20:53PM -0700, Jakub Kicinski wrote: > I'd wager the only reason you expose the netdevs at all is for link > settings, stats, packet capture and debug. You'd never run TCP traffic > over those links. And you're fighting against using Linux APIs for the > only real traffic that runs on those links - RDMA(ish) traffic. The usual working flow is to use something like TCP to exchange connection information then pivot to RDMA for the actual data flow. This is why a driver like this could get away with such a low performance implementation for a 100G NIC, it is just application boot metadata being exchanged. Sniffing probably won't work as typically the HW will capture the RoCE traffic before reaching Linux - and the Linux driver couldn't handle a 100G flow anyhow. Stats might not work either. As far as the "usual rules" we do require that accelerator devices sharing a netdev are secure in the concept of netdev userspace security. They can access the assigned RoCEv2 UDP port but cannot do things like forge src IP/MAC addresses, violate VLANs, reach outside net namespaces, capature arbitary traffic, etc. This stuff is tricky and generally requires HW support. Someone has to audit all of this and ensure it meets the netdev security requirements too, otherwise it will need CAP_NET_RAW to function. Obviously this requires seeing enough of a userspace implementation to understand how the design approaches verbs 'Address Handles' and so forth. RDMA HW has had errors before and when discovered it was blocked with CAP_NET_RAW until new chip revs came out, this is something I take very seriously. Jason