linux-kernel - Re: [PATCH 3/3] cnic,bnx2,bnx2x: use UIO_MEM_DMA

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:   Sun, 1 Oct 2023 12:44:05 +0200
From:   Hannes Reinecke <hare@...e.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Chris Leech <cleech@...hat.com>
Cc:     Christoph Hellwig <hch@....de>, Rasesh Mody <rmody@...vell.com>,
        Ariel Elior <aelior@...vell.com>,
        Sudarsana Kalluru <skalluru@...vell.com>,
        Manish Chopra <manishc@...vell.com>,
        Nilesh Javali <njavali@...vell.com>,
        Manish Rangankar <mrangankar@...vell.com>,
        Jerry Snitselaar <jsnitsel@...hat.com>,
        John Meneghini <jmeneghi@...hat.com>,
        Lee Duncan <lduncan@...e.com>,
        Mike Christie <michael.christie@...cle.com>,
        Hannes Reinecke <hare@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] cnic,bnx2,bnx2x: use UIO_MEM_DMA_COHERENT

On 9/30/23 20:28, Greg Kroah-Hartman wrote:
> On Sat, Sep 30, 2023 at 11:19:20AM -0700, Chris Leech wrote:
>> On Sat, Sep 30, 2023 at 09:06:51AM +0200, Greg Kroah-Hartman wrote:
>>> On Fri, Sep 29, 2023 at 10:00:23AM -0700, Chris Leech wrote:
>>>> Make use of the new UIO_MEM_DMA_COHERENT type to properly handle mmap
>>>> for dma_alloc_coherent buffers.
>>>
>>> Why are ethernet drivers messing around with UIO devices?  That's not
>>> what UIO is for, unless you are trying to do kernel bypass for these
>>> devices without anyone noticing?
>>>
>>> confused,
>>
>> It's confusing. The bnx2 driver stack included a cnic (converged nic?)
>> module that sits between the ethernet drivers (bnx2, bnx2x) and protocol
>> offload drivers (iscsi, fcoe, rdma).
>>
>> The iscsi module (bnx2i) uses a passthrough interface from cnic to
>> handle some network configuration that the device firmware doesn't do.
>> It uses a uio device and a userspace component called iscsiuio to do
>> that.
> 
> That's horrible, and not what the UIO api is for at all.  Configure the
> device like any other normal kernel device, don't poke at raw memory
> values directly, that way lies madness.
> 
> Have a pointer to the userspace tool anywhere?  All I found looks like a
> full IP stack in userspace under that name, and surely that's not what
> this api is for...
> 
But that's how the interface is used, in particular for the bnx2i 
driver. Problem is that the bnx2i iSCSI offload is just that, an iSCSI 
offload. Not a TCP offload. So if the iSCSI interface is configured to
acquire the IP address via DHCP, someone has to run the DHCP protocol.
But the iSCSI offload can't, and the bnx2i PCI device is not a network
device so that the normal network stack can't be used.
And so the architects of the bnx2i card decided to use UIO to pass
the network traffic to userspace, and used the userspace 'iscsiuio'
application to run DHCP in userspace.

But's been that way for several years now; so long, in fact, that
the card itself has been out of support from Marvell (since quite some 
years, too, IIRC). And even the successor of that card (the qedi driver)
is nearing EOL. Mind you, the qedi driver is using the same interface 
(by using UIO to run DHCP in userspace), so singling out the bnx2i for 
bad design can be construed as being unfair :-)

I agree, though, that the design is a mess.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@...e.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman