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.