PCG-SRX7S/Pに入れたXubuntu 12.10上で
gnome-keyring 3.6.1-0Ubuntu1のソースのmake checkがFAILになる件で進展がありました。

glib2.0-2.34.1のソースを最適化を切ってコンパイルしたら、今までFAILで落ちていたテストがOKになりました。

やったこと:

$cd  ~/src/gnome-keyring/gnome-keyring-3.6.1/
$make -k check | tee make-k-check.txt
$ egrep FAIL make-k-check.txt
  /wrap-layer/create-credential/ok_password:                           FAIL
  /secret-store/collection/load_unlock_encrypted:                      FAIL
  /xdg-store/trust/create_assertion_complete_on_token:                 FAIL
  /gnome2-store/gnome2-file/write_private_with_login:                  FAIL
    →4つのテストがFAILとなっていることを確認。

$cd /build/buildd/glib2.0-2.34.1
$vi Makefile
CFLAGS = -g -O2 -Wall
を
CFLAGS = -g -O0 -Wall
に変更。

$cd glib
$vi Makefile
CFLAGS = -g -O2 -Wall
を
CFLAGS = -g -O0 -Wall
に変更。
$make clean
$cd ..
$make
$sudo make install    → /usr/local/lib に glibがインストールされる。

$ls -lt /usr/local/lib
合計 13332
-rwxr-xr-x 1 root root     1135  1月 20 21:00 libgio-2.0.la
lrwxrwxrwx 1 root root       22  1月 20 21:00 libgio-2.0.so -> libgio-2.0.so.0.3400.1
lrwxrwxrwx 1 root root       22  1月 20 21:00 libgio-2.0.so.0 -> libgio-2.0.so.0.3400.1
-rwxr-xr-x 1 root root  5677040  1月 20 21:00 libgio-2.0.so.0.3400.1
-rwxr-xr-x 1 root root     1065  1月 20 20:59 libgobject-2.0.la
lrwxrwxrwx 1 root root       26  1月 20 20:59 libgobject-2.0.so -> libgobject-2.0.so.0.3400.1
lrwxrwxrwx 1 root root       26  1月 20 20:59 libgobject-2.0.so.0 -> libgobject-2.0.so.0.3400.1
-rwxr-xr-x 1 root root  1165448  1月 20 20:59 libgobject-2.0.so.0.3400.1
-rwxr-xr-x 1 root root     1026  1月 20 20:59 libgthread-2.0.la
lrwxrwxrwx 1 root root       26  1月 20 20:59 libgthread-2.0.so -> libgthread-2.0.so.0.3400.1
lrwxrwxrwx 1 root root       26  1月 20 20:59 libgthread-2.0.so.0 -> libgthread-2.0.so.0.3400.1
-rwxr-xr-x 1 root root     9128  1月 20 20:59 libgthread-2.0.so.0.3400.1
-rwxr-xr-x 1 root root     1031  1月 20 20:59 libgmodule-2.0.la
lrwxrwxrwx 1 root root       26  1月 20 20:59 libgmodule-2.0.so -> libgmodule-2.0.so.0.3400.1
lrwxrwxrwx 1 root root       26  1月 20 20:59 libgmodule-2.0.so.0 -> libgmodule-2.0.so.0.3400.1
-rwxr-xr-x 1 root root    41632  1月 20 20:59 libgmodule-2.0.so.0.3400.1
-rwxr-xr-x 1 root root      978  1月 20 20:59 libglib-2.0.la
lrwxrwxrwx 1 root root       23  1月 20 20:59 libglib-2.0.so -> libglib-2.0.so.0.3400.1
lrwxrwxrwx 1 root root       23  1月 20 20:59 libglib-2.0.so.0 -> libglib-2.0.so.0.3400.1
-rwxr-xr-x 1 root root  2541284  1月 20 20:59 libglib-2.0.so.0.3400.1
drwxr-xr-x 2 root root     4096  1月 20 20:59 pkgconfig
drwxr-xr-x 3 root root     4096  1月 14 07:39 gio
drwxr-xr-x 3 root root     4096  1月 14 07:39 gdbus-2.0
drwxr-xr-x 3 root root     4096  1月 14 07:39 glib-2.0
-rw-r--r-- 1 root root   443550  1月 13 19:03 libbreakpad_client.a
-rw-r--r-- 1 root root  3704712  1月 13 19:03 libbreakpad.a
drwxr-xr-x 3 root root     4096  1月  7 17:29 site_ruby
drwxrwsr-x 3 root staff    4096  1月  7 17:01 python3.2
drwxrwsr-x 4 root staff    4096  1月  7 17:01 python2.7
drwxr-xr-x 2 root root     4096  1月  2 08:57 xrdp

$cd /etc/ld.so.conf.d
$sudo vi 0local.conf
/usr/local/lib と記述
$sudo ldconfig

$cd ~/src/gnome-keyring/gnome-keyring-3.6.1/pkcs11/wrap-layer/tests
$ldd ./test-create-credential
        linux-gate.so.1 =>  (0xb7783000)
        libgcrypt.so.11 => /lib/i386-linux-gnu/libgcrypt.so.11 (0xb76db000)
        libgcr-base-3.so.1 => /usr/lib/libgcr-base-3.so.1 (0xb7657000)
        libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0xb74f6000)
        libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0xb74a8000)
        libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0xb736e000)
        libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7352000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb71a8000)
        libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0xb71a3000)
        libgck-1.so.0 => /usr/lib/libgck-1.so.0 (0xb716c000)
        libp11-kit.so.0 => /usr/lib/i386-linux-gnu/libp11-kit.so.0 (0xb7158000)
        libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0xb7152000)
        libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb7139000)
        libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb711a000)
        libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb7103000)
        libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xb70fc000)
        librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb70f2000)
        /lib/ld-linux.so.2 (0xb7784000)
        libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb70ed000)

    →/usr/local/lib のlibglib-2.0.so.0が読まれていることを確認。
$cd  ~/src/gnome-keyring/gnome-keyring-3.6.1/
$make -k check | tee make-k-check2.txt
$egrep FAIL make-k-check2.txt
  /gnome2-store/import/pkcs12:                                         FAIL
$egrep wrap-layer make-k-check2.txt
Making check in wrap-layer
make[2]: ディレクトリ `/home/mitsutos/src/gnome-keyring/gnome-keyring-3.6.1/pkcs11/wrap-layer' に入ります
make[3]: ディレクトリ `/home/mitsutos/src/gnome-keyring/gnome-keyring-3.6.1/pkcs11/wrap-layer' に入ります
make[3]: ディレクトリ `/home/mitsutos/src/gnome-keyring/gnome-keyring-3.6.1/pkcs11/wrap-layer' から出ます
make[3]: ディレクトリ `/home/mitsutos/src/gnome-keyring/gnome-keyring-3.6.1/pkcs11/wrap-layer/tests' に入ります
make[4]: ディレクトリ `/home/mitsutos/src/gnome-keyring/gnome-keyring-3.6.1/pkcs11/wrap-layer/tests' に入ります
make[4]: ディレクトリ `/home/mitsutos/src/gnome-keyring/gnome-keyring-3.6.1/pkcs11/wrap-layer/tests' から出ます
make[4]: ディレクトリ `/home/mitsutos/src/gnome-keyring/gnome-keyring-3.6.1/pkcs11/wrap-layer/tests' に入ります
  /wrap-layer/create-credential/ok_password:                           OK
  /wrap-layer/init-pin/ok_password:                                    OK
  /wrap-layer/login-auto/specific:                                     OK
  /wrap-layer/login-auto/user_token:                                   OK
  /wrap-layer/login-auto/unlock_keyring:                               OK
  /wrap-layer/login-hints/did_unlock_fail:                             OK
  /wrap-layer/login-keyring/is_usable:                                 OK
  /wrap-layer/login-keyring/usable_fail_open_session:                  OK
  /wrap-layer/login-keyring/usable_fail_not_trusted:                   OK
  /wrap-layer/login-keyring/usable_fail_locked:                        OK
  /wrap-layer/login-keyring/lookup_secret_no_match:                    OK
  /wrap-layer/login-keyring/lookup_secret_and_match:                   OK
  /wrap-layer/login-keyring/lookup_store_secret:                       OK
  /wrap-layer/login-keyring/lookup_store_secret_overwrite:             OK
  /wrap-layer/login-keyring/lookup_store_null_secret:                  OK
  /wrap-layer/login-keyring/lookup_store_no_attributes_not_stored:     OK
  /wrap-layer/login-keyring/lookup_remove_present:                     OK
  /wrap-layer/login-keyring/lookup_remove_no_attributes:               OK
  /wrap-layer/login-specific/ok_password:                              OK
  /wrap-layer/login-specific/bad_password_then_cancel:                 OK
  /wrap-layer/login-specific/cancel_immediately:                       OK
  /wrap-layer/login-user/fail_unsupported_so:                          OK
  /wrap-layer/login-user/skip_prompt_because_pin:                      OK
  /wrap-layer/login-user/ok_password:                                  OK
  /wrap-layer/login-user/bad_password_then_cancel:                     OK
  /wrap-layer/login-user/cancel_immediately:                           OK
  /wrap-layer/login-user/fail_get_session_info:                        OK
  /wrap-layer/login-user/fail_get_token_info:                          OK
  /wrap-layer/set-pin/ok_passwords:                                    OK
make[4]: ディレクトリ `/home/mitsutos/src/gnome-keyring/gnome-keyring-3.6.1/pkcs11/wrap-layer/tests' から出ます
make[3]: ディレクトリ `/home/mitsutos/src/gnome-keyring/gnome-keyring-3.6.1/pkcs11/wrap-layer/tests' から出ます
make[2]: ディレクトリ `/home/mitsutos/src/gnome-keyring/gnome-keyring-3.6.1/pkcs11/wrap-layer' から出ます
    →今までFAILだった/wrap-layer/create-credential/ok_passwordがOKになっていることを確認。


というわけで、考えにくいのですが、glib2.0-2.34.1の最適化によるバグのように見えます。
この後わたしはどう動けばよいでしょうか?

とりあえず、残り1つのFAILである
  /gnome2-store/import/pkcs12:                                         FAIL
を追いかけてみます。

make-k-check.txt https://dl.dropbox.com/u/86335040/make-k-check.txt
make-k-check2.txt https://dl.dropbox.com/u/86335040/make-k-check2.txt
をDropboxに上げて置きます。

2013-01-22 17:56:27 に奇妙な動作報告をさせていただきましたが、たった今、さらに奇妙な動作に気が付きました。

double r = rand();
    r *= 1000;
    r /= (RAND_MAX + 1.0);
    iterations = (int) r;
    iterations += 1000;

の「rand()」を「(int) 1」に変えたところ

double r = (int) 1;
    r *= 1000;
    r /= (RAND_MAX + 1.0);
    iterations = (int) r;
    iterations += 1000;

1回目にこの関数に飛び込んだ時には

(gdb) print r
$1 = 1

と、コード通りに1が入っているのですが、2回目にこの関数に飛び込んで、「double r = (int) 1」を通り過ぎたとき

(gdb) print r
$6 = -nan(0x8000000000000)

と-nanが入ってきました。

正直何が起こっているのか理解に苦しんでいるのですが、
1) このような奇妙な現象に遭遇されたことのある方はいらっしゃらないでしょうか?
2) バグシュートしたいのですが、このような現象の場合どこを追いかけていくべきでしょうか?

とても困っています。そして困惑しています。

一部の環境で
gnome-keyring-3.6.1/pkcs11/gnome2-store/gkm-gnome2-file.cのencrypt_buffer()の

iterations = 1000 + (int) (1000.0 * rand() / (RAND_MAX + 1.0));

で、とんでもない値が返ってくる件について、報告と、皆さんへのお願いです。

1． *** 報告 ***

1.1. x87 FPUデータレジスタを使い切っている個所を特定しました。

gnome-keyring-3.6.1/pkcs11/gnome2-store/gkm-gnome2-file.cのencrypt_buffer()の

gcry = gcry_cipher_encrypt (cipher, dest, input->len, input->buf, input->len);

という個所を通り過ぎたときに問題の起こるPCではデータレジスタを8つすべて使い切った状態になることを確認しました。
これはlibgcrypt11:i386 1.5.0-3ubuntu1というパッケージの/lib/i386-linux-gnu/libgcrypt.so.11.7.0という共有オブジェクトで定義されている関数です。
現在このパッケージの中を追いかけて、さらに問題を起こしている個所を突き止めようとしています。
またできれば、問題の起こるPCと起きない環境の違いを特定したいと考えています。

参考までに私のBLOGのURLを載せておきます。
http://d.hatena.ne.jp/Itisango/searchdiary?word=%2A%5Bgnome-keyring%5D



1.2. 再現プログラムを書きました。

encrypt_buffer()でやっていることを見よう見まねで再現プログラムを書きました。
私のPC上で問題を確認しました。
また別のPC上に構築したVirtualBox上の環境では問題が再現しないことも確認しました。
皆さんの環境でも再現するか否かを調べていただきたいと思っています。


1.3. バグレポートを書く予定です。

http://packages.ubuntu.com/quantal/libgcrypt11
http://packages.ubuntu.com/quantal/gnome-keyring

を調べて、同様のバグが報告されていなければバグ報告するつもりです。

いや、まだ早い、と考える方は是非一報願います。


2. *** 皆さんへのお願い ***

この問題が起こる環境の条件を調べたいと思います。
再現プログラムを下記へ置きました。
https://dl.dropbox.com/u/86335040/bug.tar.gz

皆さんの環境で、このプログラムを実行して、現象が再現するか否かを確認し、レポートをくださるようお願いいたします。
2.1. レポートはこのトピックへ投稿するか、または私へメールをいただけるようお願いいたします。
  (メールアドレスはREADME.txtの中に記述しました。)
2.2. レポートには以下の情報を記述してください。
1) 再現の可否
2) 皆さんの環境の詳細
    ・PCの機種・CPU・チップセット・マザーボード・メモリの情報
    (メーカー製PCの場合、SPEC表へのURLがあると嬉しいです)
    ・lsb_release -aの情報
    ・uname -aの情報(ホスト名を除いて)
    等々

また、ご意見のある方はご連絡ください。
皆さんのご協力をお願いいたします。

一部の環境で
gnome-keyring-3.6.1/pkcs11/gnome2-store/gkm-gnome2-file.cのencrypt_buffer()の

iterations = 1000 + (int) (1000.0 * rand() / (RAND_MAX + 1.0));

で、とんでもない値が返ってくる件について、経過報告です。

1． 問題個所を特定しました。

/build/buildd/libgcrypt11-1.5.0/cipher/rijndael.cの_gcry_aes_cbc_enc ()でaesni_cleanup() を呼び出しているところで、全てのx87 FPUデータレジスタが使用されていました。

void
_gcry_aes_cbc_enc (void *context, unsigned char *iv,
                   void *outbuf_arg, const void *inbuf_arg,
                   unsigned int nblocks, int cbc_mac)
{
  /* 略.  */
  aesni_cleanup (); /* <- ここ.  */

  _gcry_burn_stack (48 + 2*sizeof(int));
}

aesni_cleanup()はマクロで以下のようにMMX命令であるpxorを呼び出していました。

/* Two macros to be called prior and after the use of AESNI
   instructions.  There should be no external function calls between
   the use of these macros.  There purpose is to make sure that the
   SSE regsiters are cleared and won't reveal any information about
   the key or the data.  */
#ifdef USE_AESNI
# define aesni_prepare() do { } while (0)
# define aesni_cleanup()                                                \
  do { asm volatile ("pxor %%xmm0, %%xmm0\n\t"                          \
                     "pxor %%xmm1, %%xmm1\n\t" :: );                      \
  } while (0)
  /* 略  */
#else
# define aesni_prepare() do { } while (0)
# define aesni_cleanup() do { } while (0)
#endif

http://www.intel.co.jp/content/dam/www/public/ijkk/jp/ja/documents/developer/IA32_Arh_Dev_Man_Vol1_Online_i.pdf によれば

9.5.1. MMXR 命令とx87 FPU タグワードの関係
MMXR 命令の実行後は、必ずx87 FPU タグワード全体がValid（00B）に設定されてい
る。EMMS命令（MMXテクノロジ・ステートのクリア命令）を実行すると、x87 FPU
タグワード全体がEmpty（11B）に設定される。

とのことなので、ここでx87 FPUデータレジスタ全体が使用されてしまい、その後のdouble型データの処理でx87 FPUデータレジスタの「スタック・オーバーフロー例外」が発生したのだと思われます。

2. パッチを書きました。

そこで以下のパッチを書き、EMMS命令を呼び出すように変更しました。
$diff -u rijndael.c.orig rijndael.c >rijndael.c.diff

--- rijndael.c.orig     2013-01-26 18:55:44.731570123 +0900
+++ rijndael.c  2013-01-27 07:49:58.110132242 +0900
@@ -140,7 +140,7 @@
# define aesni_prepare() do { } while (0)
# define aesni_cleanup()                                                \
   do { asm volatile ("pxor %%xmm0, %%xmm0\n\t"                          \
-                     "pxor %%xmm1, %%xmm1\n" :: );                      \
+                     "pxor %%xmm1, %%xmm1\n\t" "emms\n" :: );                      \
   } while (0)
# define aesni_cleanup_2_4()                                            \
   do { asm volatile ("pxor %%xmm2, %%xmm2\n\t"                          \

これを適用して

$make
$make check
$sudo make install

してた結果/gnome2-store/import/pkcs12のテストは通りました。

結論として
1) glibcのコンパイル最適化のOff
2) 上記パッチの適応
でgnome-keyringの全てのテストはFAILにならなくなりました。
また https://forums.ubuntulinux.jp/viewtopic.php?pid=96074#p96074 で述べた「Chrome・Chromium」が異常終了する件も再現しなくなりました。

3． 気がかりなこと

ですが気がかりなことがいくつかあります。

1) この修正は正しいのか?
2) 漏れはないのか?
3) そもそもi386アーキテクチャでMMX命令を呼び出すのは正しいのか?

「1)」について、私はアセンブリ言語の経験がないし、IA-32についても詳しくないので正直自信がありません。
本当はこうすべきだというあるべき姿があれば、教えてください。
「2)」について、私はコードの全てを読んだわけではなく、またその技能もないので他に類似の処理があっても見つけ出すことができません。
gnome-keyringやlibgcrypt11:i386に詳しい方のアドバイスをお願いします。
「3)」についてlibgcrypt11:i386はその名の通りi386アーキテクチャのライブラリだと思うのですが、MMXは「Pentium II」や「MMXテクノロジPentium プロセッサ」で導入された技術だと聞いております。
そもそもi386の付くパッケージでMMXの命令を呼び出すことはありなのでしょうか?

これらのことについて皆さんのご見解を聞かせてください。


4. 今後について

4.1． とりあえず報告

とりあえず以上のようなことを簡単な英語にして、パッチも含めて https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1105758 に報告しようと思います。

4.2. glibcのコンパイル最適化の再開

glibcのコンパイル最適化のOffはトリッキーな操作だと考えていますので、時間があればコンパイル最適化を復活させて、処理を追いかけたいと思います。


長文をお読みくださりありがとうございます。何かご意見ございましたらコメントお願いいたします。

2. パッチを書きました。

パッチの件について gcrypt-devel ML ( http://lists.gnupg.org/mailman/listinfo/gcrypt-devel ) で、この修正は正しくない、と指摘されました。

# define aesni_cleanup()                                                \
  do { asm volatile ("pxor %%xmm0, %%xmm0\n\t"                          \
                     "pxor %%xmm1, %%xmm1\n\t" :: );                      \
  } while (0)

のpxorの箇所を私はMMX命令の呼び出しとみて、EMMS命令の呼び忘れかと思いパッチを書いたのですが、これはMMX命令ではなくSSE2の命令だとのことです。
SSE2をサポートしていない古いCPU(Pentium II やIII)でMMX命令と解釈されてx87 FPUレジスタが使われてしまうそうです。
正しいpatchがML上に流れたので、そのうちパッケージが更新されると思います。私のように古いPCを動かしている方はもうしばらくお待ちください。
またはソースにパッチを当てるかですね。

http://www.ring.gr.jp/pub/net/gnupg/libgcrypt/ にアクセスしてlibgcrypt-1.4.6.tar.gzとlibgcrypt-1.5.0.tar.gzをダウンロードしてソースを見比べてみました。
問題のマクロaesni_cleanup()は1.4.6には定義されておらず、1.5でエンバグしたのだと思われます。
https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bugs を見るに

Raring (1.5.0-3ubuntu2.1): main/libs
Lucid-updates (1.4.4-5ubuntu2.1): main/libs
Precise-updates (1.5.0-3ubuntu0.1): main/libs
Oneiric-proposed (1.5.0-1ubuntu0.1): main/libs
Quantal (1.5.0-3ubuntu1): main/libs
Precise (1.5.0-3): main/libs
Oneiric (1.5.0-1): main/libs
Lucid (1.4.4-5ubuntu2): main/libs
Hardy (1.2.4-2ubuntu7): main/libs

とありますので、1.5系列のlibgcryptを使っているUbuntuに影響が出るはずです。(特にPentium II&IIIマシンに)

https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1105758 は「In Progress」にステータスが変わりました。