netdev - Re: [PATCH net-next 4/5] tsnep: Add TSN endpoint Ethernet MAC driver

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: <CANr-f5y7eVbAf_NK3puJa3AcnkLXMbhzfwwmZ+r2KuWMbDhhsA@mail.gmail.com>
Date:   Wed, 28 Jul 2021 00:05:54 +0200
From:   Gerhard Engleder <gerhard@...leder-embedded.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH net-next 4/5] tsnep: Add TSN endpoint Ethernet MAC driver

> > This driver provides a driver specific interface in tsnep_stream.c for
> > direct access to all but the first TX/RX queue pair. There are two
> > reasons for this interface. First: It enables the reservation or direct use
> > of TX/RX queue pairs by real-time application on dedicated CPU cores or
> > in user space.
>
> Hi Gerhard

Hi Andrew,

> I expect you will get a lot of push back with a character device in
> the middle of an Ethernet driver. One that mmap the Tx/Rx queue is
> going to need a lot of review to make sure it is secure. Maybe talk to
> the XDP/AF_XDP people, there might be a way to do it through that?

I also expect some discussion about this feature. Mapping device specific
TX/RX queues to user space is not done in mainline Linux so far. It is done
out-of-tree for real-time communication since years. It enables interrupt free
(hard and soft IRQ) zero copy communication without any context switch
between kernel space and user space. This is ideal for real-time. It is similar
to UIO, but with DMA support and only for some TX/RX queues and not for
the whole device.

If the mmap of TX/RX queue can be done by any user space program, then
it might not be secure. The mmap of TX/RX queue will be done by the
real-time application and the real-time application needs to be privileged
anyway (SCHED_FIFO, mlock, ...). So for the real-time use case I don't see
any security problem.

There are some reasons for not using XDP/AF_XDP:
- XDP/AF_XDP does not support timed transmission and this device has
  a very special style of timed transmission (schedule with relative timings
  for DMA start and transmit time within descriptor ring, the relative timings
  define the timing of the _next_ descriptor/frame)
- XDP/AF_XDP requires Linux and the additional TX/RX Queues of this
  device are designed to be used also by other CPU cores which do not run
  Linux
- XDP/AF_XDP needs hard and/or soft IRQ processing

> So i strongly suggest your drop tsnep_stream.c for the moment. Get the
> basic plain boring Ethernet driver merged. Then start a discussion
> about a suitable API for exporting rings to user space.

I will follow your suggestion and drop tsnep_stream.c for the moment.
Any early comments about this feature are welcome, because the direct
use of additional TX/RX queues for real-time communication is the main
feature of this device.

Gerhard