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]
Message-ID: <20090802220819.GB22237@elf.ucw.cz>
Date:	Mon, 3 Aug 2009 00:08:19 +0200
From:	Pavel Machek <pavel@....cz>
To:	Harald Welte <HaraldWelte@...tech.com>
Cc:	"Michael S. Zick" <lkml@...ethan.org>, linux-kernel@...r.kernel.org
Subject: Re: [VIA Support]  Instruction timing and cache coherency issues

On Sun 2009-08-02 21:08:51, Harald Welte wrote:
> On Thu, Jul 30, 2009 at 11:08:04AM +0200, Pavel Machek wrote:
> 
> > > Diddling with the things I have found that either "fix" or "work around"
> > > the various timing / cache coherency issues - - -
> > > Aw, so - found how to affect the timing issues sufficiently so that Linux
> > > would panic dump rather than deadlock on the troublesum combination - -
> > > *Functionally the same* panic backtrace that FreeBSD is showing.
> > > 
> > > @H.W.  Download the FreeBSD-8.0-beta2 and try running it on your Cloudbook
> > > and HP-2133, you can see what is happening.  Then you might have a word or
> > > two with the silicon growers.
> > > 
> > So... you believe you have pinpointed bug in their cpu design?
> 
> I would not preclude that, but I think what might be more likely is that there
> is some difference between how Intel and how VIA/Centaur behaves in a certain
> situation, or the compiler making a wrong assumption about what it can do or
> cannot do (remember e.g. for the VIA C3 there was no cmpxchg8, but gcc uses
> it in case you compile with i686 optiomization).

I'd expect any difference in behaviour (modulo timing, extensions, and
cpuid) between Intel 486 and VIA C3 to be VIA bug, because VIA is
supposed to be Intel 486 compatible, no?

If not, where is behaviour of VIA cpus specified? Will we have to
compare 1000s of pages of instruction manuals to see where the traps lie?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ