netdev - Re: Bug report (with fix) for DEC Tulip driver (de2104x.c)

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]

Message-ID: <20190917212844.GJ9591@lunn.ch>
Date:   Tue, 17 Sep 2019 23:28:44 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Arlie Davis <arlied@...gle.com>
Cc:     netdev@...r.kernel.org, linux-parisc@...r.kernel.org
Subject: Re: Bug report (with fix) for DEC Tulip driver (de2104x.c)

On Mon, Sep 16, 2019 at 02:50:53PM -0700, Arlie Davis wrote:
> Hello. I'm a developer on GCE, Google's virtual machine platform. As
> part of my work, we needed to emulate a DEC Tulip 2104x NIC, so I
> implemented a basic virtual device for it.
> 
> While doing so, I believe I found a bug in the Linux driver for this
> device, in de2104x.c. I see in MAINTAINERS that this is an orphaned
> device driver, but I was wondering if the kernel would still accept a
> patch for it.  Should I submit this patch, and if so, where should I
> submit it?
> 
> Below is the commit text from my local repo, and the patch diffs
> (they're quite short).
> 
>     Fix a bug in DEC Tulip driver (de2104x.c)
> 
>     The DEC Tulip Ethernet controller uses a 16-byte transfer descriptor for
>     both its transmit (tx) and receive (rx) rings. Each descriptor has a
>     "status" uint32 field (called opts1 in de2104x.c, and called TDES0 /
>     Status in the DEC hardware specifications) and a "control" field (called
>     opts2 in de2104x.c and called TDES1 / Control in the DEC
>     specifications). In the "control" field, bit 30 is the LastSegment bit,
>     which indicates that this is the last transfer descriptor in a sequence
>     of descriptors (in case a single Ethernet frame spans more than one
>     descriptor).
> 
>     The de2104x driver correctly sets LastSegment, in the de_start_xmit
>     function. (The code calls it LastFrag, not LastSegment). However, in the
>     interrupt handler (in function de_tx), the driver incorrectly checks for
>     this bit in the status field, not the control field. This means that the
>     driver is reading bits that are undefined in the specification; the
>     spec does not make any guarantees at all about the contents of bits 29
>     and bits 30 in the "status" field.
> 
>     The effect of the bug is that the driver may think that a TX ring entry
>     is never finished, even though a compliant DEC Tulip hardware device (or
>     a virtualized device, in a VM) actually did finish sending the Ethernet
>     frame.
> 
>     The fix is to read the correct "control" field from the TX descriptor.
> 
>     DEC Tulip programming specification:
> 
>     https://web.archive.org/web/20050805091751/http://www.intel.com/design/network/manuals/21140ahm.pdf

Hi Arlie

Without having access to real hardware, it is hard to verify
this. Maybe the programming specification is wrong? It could be, the
hardware designer thought the control field should be write only from
the CPU side, and the status field read only from the CPU side, to
avoid race conditions. So in practice it does mirror the LastSegment
bit from control to status?

Are there any other emulators of this out there? Any silicon vendor
who produces devices which claim to be compatible?

    Andrew