Kernel related pages

slashdot.jp linux kernel — WebM Project、VP8動画コーデックSDK「Duclair」バージョン1.0を公開

The WebM Projectは1月27日、動画コーデックVP8のSDK「VP8 Codec SDK（libvpx） 1.0」（開発コードDuclair）をリリースした。パフォーマンスの改善やバグ修正などが含まれている。

slashdot.jp linux kernel — Javaでモバイルアプリ開発、独Eclipse Sourceが「RAP Mobile」プロジェクトを発表

独EclipseSourceは1月31日、新プロジェクト「RAP Mobile」を発表した。JavaでiOSやAndroidといった複数のプラットフォームに対応するモバイルアプリを開発できるという。

slashdot.jp linux kernel — mod_proxy_ajpなどに含まれる脆弱性を修正したApache HTTP Server 2.2.22リリース

Apache HTTP Server Projectは1月31日、「Apache HTTP Server 2.22.2」を公開した。セキュリティ問題およびバグ修正がメインのリリースで、重要なセキュリティ問題6件の修正も含まれている。

slashdot.jp linux kernel — 米Twitter、同社発のCSS/HTMLフレームワーク「Bootstrap 2.0」を公開

米Twitterは1月31日、CSS/HTMLフレームワーク「Bootstrap 2.0」をリリースしたと発表した。画面を格子状に分割して要素を配置する「グリッドレイアウト」を容易に実装できるほか、WebサイトやWebアプリケーション開発に向けたUIコンポーネントが多く含まれている。

slashdot.jp linux kernel — Firefox 10と同じGecko 10を採用、統合インターネットスイートSeaMonkey 2.7がリリース

SeaMonkey開発チームは1月31日、統合インターネットアプリケーションスイートの最新版「SeaMonkey 2.7」を公開した。1月31日にリリースされたFirefox 10と同じプラットフォームを採用、アドオン互換性や開発ツールなどが強化されている。

slashdot.jp linux kernel — 米Google、自社のWeb用言語「DART」とJavaScriptを比較する「Dart Synonym」を公開

米Googleは1月30日、同社が公開したWebアプリケーション向けプログラミング言語「Dart」とJavaScriptとを比較するWebサイト「Dart Synonym」を公開した。Dart利用において有用な情報となるだけでなく、JavaScriptからDartへの移行を促進する目的もありそうだ。

slashdot.jp linux kernel — Apache CouchDBに高可用性機能を加えた「BigCouch」、バージョン0.4が登場

米Cloudantは1月26日、「BigCouch 0.4」を発表した。ドキュメント指向データベースの「Apache CouchDB」にクラスタ機能を加えたもので、API互換もあるという。

slashdot.jp linux kernel — PR: シスコ製サーバ導入チャンス！ 3月30日受注分まで

UCS Cシリーズお手軽導入パック。ネットワールドの特別価格にご注目。

kosaki-san — gcc 4.7 だとカーネルがまともに動かないんじゃないの？という話 Jan Karaがなかなか素敵なバグを報告している。

bitfieldいじるときに、64bit load/store使えうように、となりのbitfieldも合わせて read-modify-write
するから全然関係ないフィールド更新時に別のフィールドがlostするって・・・

でいつものようにGCC界隈から「Cの規格書にはやっちゃダメとは書いてない」という声が飛んできて
カーネル界隈から「そんなんソフトが書けるか。あほー」という怒号が飛び交う展開に
だって、普通たまたま隣り合ってるだけの全然関係ないフィールドってロックも別だよねえ(-_-;)

From:	 Jan Kara jack@suse.cz vger.kernel.org
To:	 LKML 
Cc:	 linux-ia64@vger.kernel.org,
 Linus Torvalds ,
 dsterba@suse.cz,
 ptesarik@suse.cz,
 rguenther@suse.de,
 gcc@gcc.gnu.org
日付:	 2012年2月1日10:19
件名:	 Memory corruption due to word sharing

Hello,

 we've spotted the following mismatch between what kernel folks expect
from a compiler and what GCC really does, resulting in memory corruption on
some architectures. Consider the following structure:
struct x {
   long a;
   unsigned int b1;
   unsigned int b2:1;
};

We have two processes P1 and P2 where P1 updates field b1 and P2 updates
bitfield b2. The code GCC generates for b2 = 1 e.g. on ia64 is:
  0:   09 00 21 40 00 21       [MMI]       adds r32=8,r32
  6:   00 00 00 02 00 e0                   nop.m 0x0
  c:   11 00 00 90                         mov r15=1;;
 10:   0b 70 00 40 18 10       [MMI]       ld8 r14=[r32];;
 16:   00 00 00 02 00 c0                   nop.m 0x0
 1c:   f1 70 c0 47                         dep r14=r15,r14,32,1;;
 20:   11 00 38 40 98 11       [MIB]       st8 [r32]=r14
 26:   00 00 00 02 00 80                   nop.i 0x0
 2c:   08 00 84 00                         br.ret.sptk.many b0;;

Note that gcc used 64-bit read-modify-write cycle to update b2. Thus if P1
races with P2, update of b1 can get lost. BTW: I've just checked on x86_64
and there GCC uses 8-bit bitop to modify the bitfield.

We actually spotted this race in practice in btrfs on structure
fs/btrfs/ctree.h:struct btrfs_block_rsv where spinlock content got
corrupted due to update of following bitfield and there seem to be other
places in kernel where this could happen.

I've raised the issue with our GCC guys and they said to me that: "C does
not provide such guarantee, nor can you reliably lock different
structure fields with different locks if they share naturally aligned
word-size memory regions.  The C++11 memory model would guarantee this,
but that's not implemented nor do you build the kernel with a C++11
compiler."

So it seems what C/GCC promises does not quite match with what kernel
expects. I'm not really an expert in this area so I wanted to report it
here so that more knowledgeable people can decide how to solve the issue...

                                                               Honza

slashdot.jp linux kernel — SambaにDoS攻撃を可能にする脆弱性が発覚、これを修正した「Samba 3.6.3」リリース

Samba Teamは1月29日、最新安定版「Samba 3.6.3」を公開した。25日にSamba 3.6.2がリリースされたばかりだが、Samba 3.6系にDoS攻撃を受ける脆弱性があることが発覚、これに対応するセキュリティリリースとなる。

slashdot.jp linux kernel — PR: シスコ製サーバ導入チャンス！ 3月30日受注分まで

UCS Cシリーズお手軽導入パック。ネットワールドの特別価格にご注目。

kosaki-san — load averageのアンダフローバグ ぜんぜん別件だけど

むかし誰かに load averageがアンダーフローして数億になってる。というバグ報告をいただいたのだが誰から聞いたのか思い出せん。たぶん一年ぐらいまえ。とりあえず、sched_setscheduler()にレースがあることが分かって、治したので今後はおきないはず。

ではではJanuary 30, 2012 09:27 PM

kosaki-san — 3.1からRLIMIT_NPROCの挙動が変わった件について 小ネタ

3.1からLinux の RLIMIT_NPROC のあつかいがちょっと変わります。端的にいうとNetBSDちっくな動きになりました。

まずバックグランドを説明すると、NPROCはユーザあたりのプロセス数を制限する機能であると。端的にいうとプロセス数超過するとforkがEAGAIN返して失敗する。プロセスを作る方法は１つしかないから一見自明に見える。

ところが「ユーザあたりのプロセス数」というのがキモで、プロセスの所有ユーザを変えてしまうという手がある。set*uid() 族と setuidされたプログラムに対するexec()族である。

余談。従来Linuxはset*uid()族はNPROCチェックをしてEAGAINを返していたが、execではチェックしていなかった。ついでにいうとforkでのチェックもちゃんとロックされてなかったので、プロセス数の厳密な保証はもとから無かった。NPROCなんてしょせんforkbomb対策のオモチャだから適当でいいんだよ。というのはLinusの弁。まあ、それは置く。

set*uid()でチェックすると何が問題かというと、POSIX的にはset*uid()は正しい引数を与える限りにおいて失敗しないので、かなり著名なソフトでも誰も返値をチェックしてない。ついでにいうとLinuxはmanページからしてEAGAINの記載がないというていらくで（※ごめん、いま見直したらmanにはちゃんと書いて有ったわ）エスパーでもない限り失敗するケースを思いつく人はいないという状況だった。

さて、set*uid()を使う場面というのは（ごく一部の例外を除いて）端的に言えばrootが非rootに変身して権限を落とすということであるので、ここで失敗してかつエラーチェックを怠るとroot権限をもったまま信頼できないプログラムをexecするアホdaemonが出来上がる。

で、権限を落とすシステムコールを失敗させるのはセキュリティ的にたいへん危険なので、権限昇格させるほう、つまりexec族で失敗させるのが正しいんじゃね？という意見が提出された。普通のデーモンは fork - setuid - exec の３つをつづけて呼ぶのでチェックがsetuidからexecに変わっても、実質の動きはかわらんでしょう、と。

で、いつものように互換性がにゃーにゃー、戻り値をチェックしないプログラムがワンワンと騒いでいたのだが、たまたまtwitterでsodaさんがNは何年も前からexecでチェックしてるとつぶやいていたのでLinusに転送してみたら採用されてしまった。

そのあと互換性議論が復活して、setuid使ってないプロセスはexec失敗しないよう仕様が若干変更され、現在の使用は
・set*uid()時にNPROC超過を検出し、かつ
・その後のexecでも再びNPROC超過を検出したとき
のみexecがEAGAINを返す。となっている

というわけで、この件でなにか困った事にぶちあたった人がいたらsodaさんをdisるといいと思うよ。

・・・という免責事項を軽くジャブしたあとでいうのもなんですけど、NetBSDのみなさんはRLIMIT_NPROCのコメントやドキュメントで「Linuxと違ってNetBSDはhogehoge」などと説明してるところをいちいち治して回る刺身たんぽぽの作業をするといいと思うよ。ではでは


以下はLinus treeに入ってるコミットログ

commit 72fa59970f8698023045ab0713d66f3f4f96945c
Author: Vasiliy Kulikov 
Date:   Mon Aug 8 19:02:04 2011 +0400

    move RLIMIT_NPROC check from set_user() to do_execve_common()
    
    The patch http://lkml.org/lkml/2003/7/13/226 introduced an RLIMIT_NPROC
    check in set_user() to check for NPROC exceeding via setuid() and
    similar functions.
    
    Before the check there was a possibility to greatly exceed the allowed
    number of processes by an unprivileged user if the program relied on
    rlimit only.  But the check created new security threat: many poorly
    written programs simply don't check setuid() return code and believe it
    cannot fail if executed with root privileges.  So, the check is removed
    in this patch because of too often privilege escalations related to
    buggy programs.
    
    The NPROC can still be enforced in the common code flow of daemons
    spawning user processes.  Most of daemons do fork()+setuid()+execve().
    The check introduced in execve() (1) enforces the same limit as in
    setuid() and (2) doesn't create similar security issues.
    
    Neil Brown suggested to track what specific process has exceeded the
    limit by setting PF_NPROC_EXCEEDED process flag.  With the change only
    this process would fail on execve(), and other processes' execve()
    behaviour is not changed.
    
    Solar Designer suggested to re-check whether NPROC limit is still
    exceeded at the moment of execve().  If the process was sleeping for
    days between set*uid() and execve(), and the NPROC counter step down
    under the limit, the defered execve() failure because NPROC limit was
    exceeded days ago would be unexpected.  If the limit is not exceeded
    anymore, we clear the flag on successful calls to execve() and fork().
    
    The flag is also cleared on successful calls to set_user() as the limit
    was exceeded for the previous user, not the current one.
    
    Similar check was introduced in -ow patches (without the process flag).

slashdot.jp linux kernel — Mozilla Labsが新プロジェクト「Pancake」発表、Webの進化に即したツールの開発目指す

Mozilla Labsは1月27日、新プロジェクト「Pancake」を発表した。検索、ブラウズなどWebの利用をより効果的にするという野心的なプロジェクトで、まずはiOSとAndroidで動く新しいモバイルアプリを開発する。

slashdot.jp linux kernel — PR: シスコ製サーバ導入チャンス！ 3月30日受注分まで

UCS Cシリーズお手軽導入パック。ネットワールドの特別価格にご注目。

slashdot.jp linux kernel — 「GNOME 3.3.4」リリース、次期安定版GNOME 3.4に向けた開発版

The GNOME Release Teamは1月26日、オープンソースのデスクトップ環境「GNOME 3.3.4」を公開した。バージョン3.4に向けた開発者向けの不安定版リリースとなり、多数のモジュールが強化・改善されている。