Orz日記 by Akio Morita

_ [SAD][YaSAI]PEGパーサーバグ修正

PEGのメモの状態やルールの適用順をダンプしながら調べることで 左再帰の実装のバグを特定＆修正出来た。

左再帰マークの付いたルールが、左再帰のループの根元のルールが 終了した後に再評価される際に、既に存在しない根元のルールを 探して再帰スタックをたどってしまうのが原因だった。 左再帰実装の元ネタ論文では考慮されていないケースと思われる。

おそらく、文法の書き方によっては避けられる(左再帰に含まれるルール集合 の上位ルールに唯一性が成り立つ場合とか)と思うが、パーサーの性能で 文法記述が制約されるのは気にくわないので修正。 左再帰の根元となるルールが適用中かどうかを記録するフラグを増設して、 根元のルールの適用が終了後に左再帰マークの付いたメモを見つけたら メモから削除するようにして解決した。

修正済みのパーサーで、Map演算子の左オペランドが Function演算子や Unset演算子で終端される構文が正しく解析できるようになった。

構文解析の進捗解析用に生成されるログは、約113MB、285万行に及んだ。 もう少し文法記述を改良してダイエットしたほうが良いのかもしれない。 もちろん、正しく動作する文法記述を完成させてからの話ではあるが...

_ [SAD]探し物はバグですか？

IRデザインの裏番組でFit[]回りのバグを探しているのだが、 見つけにくいバグのようです。

一匹目を潰したけど、問題となっている症状は解決していない...

やはり、ブレークポイント仕掛けてgdbか？

_ [FreeBSD]9.1-PRERELEASE不調

9.1-BETA1は問題なく動いていたのだが、9.1-PRERELEASE r238996で make worldしたら不調に...

X11環境で、fvwmがcore dumpやらmalloc failureで落ちるのは 致命的 orz

こいつらは、rebuildしていないので/usr/lib側の共有ライブラリか カーネルのVM回りが腐っているような気がする

一応、/と/usrをzfs rollbackして復旧させたが暫く freebsd-stable ML見ながら様子見

zfs rollback後に rebootしたら unmount中に kernel panicしたうえに swap deviceである GEOM MIRRORのメタデータが壊れたっぽい (GEOM MIRRORが deviceの importに失敗する)ので、 GEOM MIRRORは labelしなおした

_ [FreeBSD]libX11をアップデートするとXIM回りが死ぬ

x11/libX11 1.6.9_3,1以降に更新すると、XIMの初期化処理でlibX11にてSEGVする

セキュリティー目的で追加した境界チェックコードでエンバグしている模様

例えば、XIM経由で動く ktermやemacsが該当例

2020-08-04追記 libX11-1.6.10_1,1で修正された

ktermのSEGVの場合、XGetIMValues(im, XNQueryInputStyle, &im_styles, NULL)によるQuery要求に対して、libX11のmodules/im/ximcp/imRmAttr.c内 _XimAttributeToValue関数の XimType_XIMStyles型に対する処理が、if ((sizeof(num) + (num * sizeof(XIMStyle))) > data_len) return Falseで失敗するための模様

手元の事例では、num=6, data_len=28bytesで XimType_XIMStylesに対するQueryが渡ってきており、先頭のunit16_t 2語がヘッダー部なのでXIMStyleの引数列は計 24bytesとなり、6引数とすると1語 4bytesの構成となるのだが、X11/Xlib.hのXIMStyle型の定義はunsigined longなので、LP64環境では1語 8bytesの定義になっている

当該if節は、data_lenの検証をXIMStyle型 num語が渡っているとして検査しているが、読み出し側に使っている配列ポインタは、uint32_t相当のCARD32型なので 4bytesずつ舐めている計算になる。

処理している入力バッファは、XIMプロトコルでX Serverから渡されたunibyte streamと思われるので、検査コードのバグっぽぃ

あと、類似の検査を行っているXimType_XIMHotKeyTriggersのケースと比較すると、CARD16型のパディング1語分をカウントし忘れているのも、検査に成功した条件で未割り当てのメモリアクセスを許す点でバグの模様

XimType_XIMHotKeyTriggersの検査も、CARD32型の三つ組をnumセット読み出しているようなので、比較すべきコンテンツボディ長は、num * 3 * sizeof(CARD32)で定義すべきと思われる (一応、XIMHotKeyTrigger型は、KeySymとint 2個からなる構造体なので、KeySymが 32bitなら辻褄はあっているが…)

--- modules/im/ximcp/imRmAttr.c.orig    2020-07-31 22:46:13.000000000 +0900
+++ modules/im/ximcp/imRmAttr.c 2020-08-03 17:56:02.608498000 +0900
@@ -265,8 +265,8 @@

            if (num > (USHRT_MAX / sizeof(XIMStyle)))
                return False;
-           if ((sizeof(num) + (num * sizeof(XIMStyle))) > data_len)
-               return False;
+           if ((sizeof(data[0]) + sizeof(data[1]) + (num * sizeof(style_list[0]))) > data_len)
+               return False;
            alloc_len = sizeof(XIMStyles) + sizeof(XIMStyle) * num;
            if (alloc_len < sizeof(XIMStyles))
                return False;
@@ -379,7 +379,7 @@

            if (num > (UINT_MAX / sizeof(XIMHotKeyTrigger)))
                return False;
-           if ((sizeof(num) + (num * sizeof(XIMHotKeyTrigger))) > data_len)
+           if ((sizeof(num) + (num * 3 * sizeof(key_list[0]))) > data_len)
                return False;
            alloc_len = sizeof(XIMHotKeyTriggers)
                      + sizeof(XIMHotKeyTrigger) * num;

_ [IPv6]WindowsのIPv6アドレス

Windowsではインターフェースアドレス部は、MACアドレスベースのEUI64ではなく使い捨ての匿名アドレスが採用されるので、RAによる自動設定+AAAAレコードでの運用がうまくいかない

匿名アドレスがデフォルトなのはプライバシーのためだが、個人でプロバイダー経由の接続では、プロバイダーが配布する48bit prefixがほぼ固定なので、48bit prefixで契約者が特定されてしまう現実があり、LAN上の固定端末にはあまり意味が無い(複数端末がある場合の使用端末を特定させない効果や移動端末でネットワークを越えた特定を避ける効果はある)

で、匿名アドレスをoffにする方法を調べてみた

netsh interface ipv6 set privacy state=disabled

で無効にできる模様

PowerShellからだと、

Set-NetIPv6Protocol -UseTemporaryAddresses Disabled

らしい

ホスト部ランダム化(2021/08/10追記)

匿名アドレスをOFFにしても、Global Unicast Addressのホスト部はランダム化されているので、MACから誘導されるEUI64アドレスを使わせるにはこれをoffする必要がある

netsh interface ipv6 set global randomizeidentifiers=disabled