linux-kernel - Re: i686 quirk for AMD Geode

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]

Date:	Fri, 13 Nov 2009 16:23:01 +0000
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Pavel Machek <pavel@....cz>
Cc:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
	"H. Peter Anvin" <hpa@...or.com>,
	Matteo Croce <technoboy85@...il.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: i686 quirk for AMD Geode

On Thu, Nov 12, 2009 at 01:18:05PM +0100, Pavel Machek wrote:
> Interesting...geode gx being buggy? I know pentium was famous for the
> fdiv bug, but never heard of geode gx problems...
> 
> Are they something kernel can work around, or do those chips just have
> to be avoided? Anything malicious user can use to crash the system?
> Anything malicious user can use to gain extra priviledge?

Well the one problem I have encountered is in the jsm driver (exar pci
uart driver).

On a typical PC with a P3, P4, Core 2, athlong, etc, it works perfectly.
It works perfectly on a Geode LX as well.  On a Geode SC1200 (which
is a GX with companion chip in one) it transmits out of order in a
consistent way.

If you transmit a chunk of data that looks like this:

0123456789abcdef

The data that comes out of the UART is:

123056749ab8defc

The fix to avoid the problem is:

-               memcpy_toio(&ch->ch_neo_uart->txrxburst, ch->ch_wqueue + tail, s);
+               for(i=0;i<s;i++) {
+                       memcpy_toio(&(ch->ch_neo_uart->txrxburst[i]), ch->ch_wqueue + tail + i, 1);
+               }

Calling memcpy_toio on the Geode SC1200 on anything larger than 1 byte
causes the data to be delivered (at least on the PCI bus) reordered in
that very consistent manner.

The alignment doesn't affect it (I tested that).  Simply doing more than
1 byte at a time with memcpy_toio to the pci device messes up.

So as a result we run with this patch applied even though it certainly
is less efficient, but at least it works.

Every other CPU works fine that I have ever tried the driver on.

-- 
Len Sorensen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/