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-next>] [day] [month] [year] [list]
Date:	Wed, 21 Jan 2015 17:24:38 +0000
From:	Ben Hutchings <ben.hutchings@...ethink.co.uk>
To:	Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@...esas.com>,
	Mitsuhiro Kimura <mitsuhiro.kimura.kc@...esas.com>,
	Hisashi Nakamura <hisashi.nakamura.ak@...esas.com>,
	Yoshihiro Kaneko <ykaneko0929@...il.com>
Cc:	netdev@...r.kernel.org,
	ct-linux-kernel <linux-kernel@...ethink.co.uk>
Subject: Questions about the sh_eth driver and hardware

I found several more bugs in the sh_eth driver, but for some of them I'm
really unsure what to do.  I only have a manual for the R8A7790 (R-Car
H2) and I don't know how all the other supported chips will behave.
Maybe you can answer some of these questions.

1. When freeing packet buffers, we currently try to stop the DMA engines
by clearing EDRRR and EDTRR but we *don't* wait after that.  This seems
unsafe because in general register writes are not serialised with DMA.

The R8A7790 (R-Car H2) manual specifically says that the R bit of EDTRR
(aka CXR2) cannot be cleared by writing to it.  I think that we could
stop TX DMA by clearing the active flags of all the descriptors and then
polling the R bit until it clears.  What do you think?

As for RX DMA, I think we should wait some time after clearing the R bit
that we can be sure is long enough to transfer one packet.  Do you know
how long that could be?

2. In case of a Receive Descriptor Empty error (RDE), we currently read
the RDFAR register to find the next descriptor the DMA engine will use.
But this register is not documented for the R8A7790 and the driver does
not define an offset for it on R-Car chips.  The manual doesn't say how
to set the address of the next descriptor to use.  Maybe we should
assume that R-Car chips will never skip descriptors after RDE?

Ben.


--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ