netdev - Re: 8139cp: set ring address before enabling receiver

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: <50AD3C51.9070105@pobox.com>
Date:	Wed, 21 Nov 2012 15:40:49 -0500
From:	Jeff Garzik <jgarzik@...ox.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	David Woodhouse <dwmw2@...radead.org>,
	Jason Wang <jasowang@...hat.com>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: 8139cp: set ring address before enabling receiver

On 11/21/2012 03:18 PM, Ben Hutchings wrote:
> On Wed, 2012-11-21 at 19:51 +0000, David Woodhouse wrote:
>> On Wed, 2012-11-21 at 13:12 -0500, Jeff Garzik wrote:
>>>
>>> What sticks out at me from the commit message?
>>>
>>> It was not tested on the famously quirky 8139 hardware at all.
>>>
>>> While I have not looked at the 8139C+ data sheet in a while, sometimes
>>> the hardware _did_ have a strange init order.
>>>
>>> As this works in a simulator but fails on real hardware, it seems like
>>> an obvious regression caused by an untested [on read hardware] patch.
>>
>> The data sheet (v1.6, from http://realtek.info/pdf/rtl8139cp.pdf ) says
>> in §6.33 (C+ Command Register):
>>   "Enable C+ mode functions in C+CR register first,
>>   => Enable transmit/receive in Command register (offset 37h),
>>   => Configure other related registers (ex. Descriptor start address,
>>      TCR, RCR, ...)."
>>
>> I understand the concern expressed in the offending commit message about
>> DMA happening to invalid addresses, and I'll look at the data sheet
>> harder to see when the DMA actually starts happening. But it definitely
>> seems that our current code isn't doing what the data sheet says.
>>
>> I wonder if I can find one of these lying around and stick it in a
>> machine with an IOMMU...
>
> You might be able to avoid disaster by doing:
>
> 1. Set MAC filter to drop everything
> 2. Enable RX DMA
> 3. Set RX DMA ring address
> 4. Set MAC filter according to current flags & multicast list
>
> I'm assuming, knowing nothing about this particular hardware, that the
> MAC filter register(s) will accept writes before RX DMA is enabled.

A larger point is that the commit was created to avoid imagined disaster 
on simulated hardware...

  ...and wound up creating behavior that is (a) contra to the data sheet 
and (b) breaks real hardware.

	Jeff




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html