On Tue, 2008-01-08 at 18:58 +0100, Jan de Groot wrote:
> I think it's wise to disable the padlock engine in libgcrypt. I took a
> look at the code, this is what I found:
>
> --disable-padlock-support
> Disable support for the PadLock engine of VIA
> processors. The default is to use PadLock if
> available. Try this if you get problems with
> assembler code.
>
> So this is all about VIA chips. How many users do we have with VIA chips
> and how many of them use the padlock engine?
>
> Then looking at the valgrind reports, there's a bug in
> _gcry_detect_hw_features. This function sets hw_features to 0 and then
> has some ifdef code that will check for __i386__. If it's __i386__
> (which is not true on amd64), the detect_ia32_gnuc() function is called.
> This function only tests for a VIA processor with padlock engine.
>
> I might have tracked down the bug though. According to bugreports, the
> invalid read of size 1 is at line 95 in that file, which is a strcmp
> operation on a variable that has been terminated by a 0 sign instead of
> a NULL character. I'll upload a package with the fix so people can test.
> If I have one report of the package fixing the problem, I'd like to have
> it moved to i686 core.

Ok, though my theory sounds plausible to people who don't program C
frequently, I can't crash applications by doing exactly the same as this
function from my i686 chroot.

I disabled padlock support and uploaded it to testing. There's a package
at http://www.archlinux.org/~jgc/libgcrypt-1.4.0-1.1-i686.pkg.tar.gz for
people who want to test without waiting for their mirror to pickup the
new package from testing.

Please test and signoff in case it fixes the problems.