青木@名古屋です。 On Fri, 12 Aug 2016 15:42:58 +0900 "ke...@kens.fm" <ke...@kens.fm> wrote:
> > 念の為確認ですが、brandelf -t Linuxした状態のバイナリを実行する際は > > linux_enable="YES"(かつlinux.koをロード済)で試していますよね? > > はい > kldload linux.ko して > kldstat で確認してテスト後 > kldunload linux.ko しました まずは本当にLinuxバイナリで【ない】ことは確認できましたね。 > svnlite checkout https://svn.FreeBSD.org/base/stable/10 -r r286665 /usr/src > > stable/10 の r286665〜r297262 までを試して > r293448 まではOK > r293449 以降がNG > と言う事がわかりました > r293448とr293449の間で変更されているのは > > sys/kern/imgact_elf.c > https://svnweb.freebsd.org/base/stable/10/sys/kern/imgact_elf.c?r1=293318&r2=293449 > だけのようです。 私の頭に引っ掛かっていたのは多分その次のr295366だったと思いますが、 それはさておき、 ・r293499をbackoutするとどうなるか? ※上記で引用頂いたURLの画面上方の「patch」をクリックすると パッチが手に入りますので、これをファイルに落とし、 /usr/srcで patch -p2 -R -i パッチファイル名 で当てれば大丈夫です。 ※パッチ内のパスのうち「stable/10/」の部分を無視させる 必要があるので -p2 が必須です。 ・上記だけで駄目な場合、さらにr295366もbackoutするとどうなるか? を試してみてはどうでしょうか? もしこれで動くなら、POLA violationと してBugzillaにPR登録してfreebsd-stable MLにもその旨報告すると、認め られれば次のSAのタイミングでENとして対応してもらえるかもしれません。 ※POLA violationをまともに考慮するのはstableブランチからですので、 今回のように「従来動いていたものが動かなくなった」というケースは freebsd-currentで報告してもとりあって貰えないかもしれません。 なお、素直にこのファイルだけr293448以前に戻せと言わないのは、さらに次の r295454がシステムの他の部分の更新と絡んでいるため、迂闊にこのファイル だけ戻すと何が起こるか不安だからです。 > 10.2-RELEASE-p8 と stableの 10.2p8 は全く別物ですか? > revision番号は各ブランチ共通みたいですが portsは別管理ですが、base(OS本体部分)はご察しのとおり、共通です。 また、stableブランチにはp8やp10のようなパッチレベルは無く、ただただ リビジョンが進むのみです。 一応説明すると、*.0-RELEASEまでの流れは割と知られていると思いますので 置いておいて、その後の更新に絞ると、 ・開発はhead(所謂-current)で進む。 ・headである程度以上の有効性・安全性が確認され、K[P|B]I・A[P|B]I を壊さないものがstableにマージされる。(MFC 乃至 MFH) ・stableブランチで新たな問題が発生しなかった【SA/EN関連】の修正が relengブランチにマージされる。(MFS) ・必要な更新が出揃い、relengブランチでの動作検証をパスしたところで relengブランチのバージョン情報を更新し、freebsd-update用のバイナリ をビルド、提供開始(10.2-p18や10.3-p4等)。 という流れになります。 そのため、正式にSAやENが出るより少しでも早く セキュリティ修正を取り込みたい(リスク覚悟)場合、relengブランチを 追いかけてソースからビルドして更新するのがお薦めです。 ※特殊な環境や一部のアーキティクチャでのみ不具合が発生し、SAの 発行が大幅に遅れるケースもありますので。 手間や検証未完の リスクとのトレードオフですが。 さらに早くというならさらに リスクは上がりますがstableブランチの追いかけです。 > > SA-16:25 > これとの関係は判りませんが SA-16:25 の反映済みと思われる > 10.3-RELEASE-p7 でも例の古いバイナリは動きませんでした。 上述のとおり、今回発見して頂いた変化点を含む全てのリビジョンが アウトと考えるのが自然です。 今回は問題のリビジョンでの変更が 1ファイルのみ・1箇所のみ(もう1件も変更箇所は増えるものの1ファイル のみで個々の変更は小さい)ため、それだけを外してみるのを提案させて 頂きました。 stable/10で今回のトライアルがうまく行ったら、そのままstable/10を 使うのも一手ですし、基本10.3-RELEASEからfreebsd-updateでuserlandを 更新しつつカーネルだけソースで更新(今回同様、patch -p2 -Rで手動 backout)するのも可でしょう。 いずれにせよ、これで駄目ならもう私の現状では白旗を上げざるを得ません。 > > > -- > けんずふぁみりー > _______________________________________________ > freebsd-users-jp@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-users-jp > To unsubscribe, send any mail to "freebsd-users-jp-unsubscr...@freebsd.org" > -- 青木 知明 [Tomoaki AOKI] <junch...@dec.sakura.ne.jp> _______________________________________________ freebsd-users-jp@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-users-jp To unsubscribe, send any mail to "freebsd-users-jp-unsubscr...@freebsd.org"