On Wed, Dec 08, 2010 at 08:08:13AM +0800, Harald Welte wrote:
>
> Is there a list of machines (/proc/cpuinfo) on which the problem has shown up
> so far?
Yes, this is the one that's show the problem:
| -bash-4.0# cat /proc/cpuinfo
| processor : 0
| vendor_id : CentaurHauls
| cpu family
Sorry for jumping into this thread so late.
I am almost constantly on business travel (without any VIA system with me), so
I cannot try to reproduce the problem. It probably has never shown up before
since my typical test case is dm-crypt and there you will of course never see
any unaligned buffe
Hi,
On Tue, Dec 07, 2010 at 07:39:56PM +0800, Herbert Xu wrote:
> On Tue, Dec 07, 2010 at 11:41:41AM +0100, Phil Sutter wrote:
> >
> > Yes, CONFIG_PREEMPT is active in my test system's kernel.
>
> OK, can you see if the problem is still reproducible without
> preemption?
Yes, it is. I just redid
On Tue, Dec 07, 2010 at 11:41:41AM +0100, Phil Sutter wrote:
>
> Yes, CONFIG_PREEMPT is active in my test system's kernel.
OK, can you see if the problem is still reproducible without
preemption?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor
Hi,
On Thu, Dec 02, 2010 at 02:14:41PM +0800, Herbert Xu wrote:
> > Yes, it does, but triggering the bug is not really trivial. I've had
> > best results with a speed testing tool using the asynchronous interface,
> > memory corruption occured in each run. The same tool operating
> > synchronously
On Fri, Nov 05, 2010 at 03:12:38PM +0100, Phil Sutter wrote:
>
> Yes, kind of. With that trivial fix applied, the driver is stable most
> of the time.
Great.
> Yes, it does, but triggering the bug is not really trivial. I've had
> best results with a speed testing tool using the asynchronous int
Herbert,
On Thu, Nov 04, 2010 at 01:46:06PM -0500, Herbert Xu wrote:
> > On one hand, the original code is broken in padlock_xcrypt_cbc(): when
> > passing the "initial" bytes to xcryptcbc, 'count' is incorrectly used as
> > length. This may trigger prefetch-related issues, but will definitely
> >
On Thu, Nov 04, 2010 at 05:50:36PM +, Phil Sutter wrote:
> Using cryptodev-linux with it's zero-copy functionality, one is mighty
> enough to pass various misaligned/mis-sized buffers unmodified to the
> engine's driver, which occured to be an easy way to break padlock
> equipped machines:
OK.
