netdev - Re: net: netcp: regarding commit 899077: netcp: try to reduce type confusion in descriptors

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] [day] [month] [year] [list]

Date:	Wed, 24 Feb 2016 13:47:02 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Murali Karicheri <m-karicheri2@...com>
Cc:	"open list:TI NETCP ETHERNET DRIVER" <netdev@...r.kernel.org>
Subject: Re: net: netcp: regarding commit 899077: netcp: try to reduce type confusion in descriptors

On Monday 22 February 2016 18:09:45 Murali Karicheri wrote:
> On 02/22/2016 05:13 PM, Arnd Bergmann wrote:
> > On Monday 22 February 2016 16:48:14 Murali Karicheri wrote:
> >> Keystone can have SoC configured to be in big endian mode for peripherals and DSP.
> > 
> > I'm not entirely sure what this means
> 
> This means, ARM core can be using LE/BE and rest of the system can be configured through a pin
> (to SOC) to operate in BE/LE. So need to take care of all mixed endian configuration 
> properly. Refer to http://www.ti.com/lit/ds/symlink/tci6636k2h.pdf for more details if interested.

Ah, that is unfortunate. For the moment, let's hope that nobody ever uses that pin,
so we can support both big-endian and little-endian kernels without having
to do any runtime detection of the board settings.

If anyone is misguided enough to flip that configuration pin to the opposite
setting, then we will require extra DT properties to list for each device
what endianess the hardware uses, and check that flag at runtime, which causes
a little extra overhead.

If you are able to provide any feedback to the hardware designers, please
ask them to never do configurable endianess again: it solves no actual
problems but creates endless nightmares if anyone ever uses that.

> > And this is another one of the same sort.
> > 
> > Not my best patch ever obviously, but at least I understand where I went
> > wrong now, and see that it was only me being sloppy in the conversion rather
> > than a more fundamental misdesign.
> > 
> 
> So do you plan to re-spin the patch again with the above change?

I probably won't bother at this point, but if you could send a patch to get back
to my version with your fixes, I'll send an Ack.

	Arnd