革命の日々！ Kees Cook の symlink restrictions on sticky directories が -mm入り
ようするに /tmp に symlink があるときに、ownerが自分じゃないときはrootであってもsymlinkたどれないようにするよ。というパッチである 背景なんですが、Unixの古典的なセキュリティーホールにrootが O_EXCL つけずに/tmp以下のファイルを開くとアタッカーに利用されて脆弱性になるというものがありまして、古典的には以下のストーリー １．悪意のあるユーザ Bob が ln -s /etc/passwd /tmp/app-A-tmpfile とかリンクを貼る ２．root権限をもったデーモンアプリが /tmp/app-A-tmpfile を O_EXCL なしで開く（そして成功する） ３．そのアプリが今開いたtmpファイルに適当にデータを書く ４．なぜか /etc/passwdが破壊される ← イマココ O_EXCL以外の方法、たとえばstat(2)とかで確認
革命の日々！ 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, ptesa
革命の日々！ 3.1からRLIMIT_NPROCの挙動が変わった件について
小ネタ 3.1からLinux の RLIMIT_NPROC のあつかいがちょっと変わります。端的にいうとNetBSDちっくな動きになりました。 まずバックグランドを説明すると、NPROCはユーザあたりのプロセス数を制限する機能であると。端的にいうとプロセス数超過するとforkがEAGAIN返して失敗する。プロセスを作る方法は１つしかないから一見自明に見える。 ところが「ユーザあたりのプロセス数」というのがキモで、プロセスの所有ユーザを変えてしまうという手がある。set*uid() 族と setuidされたプログラムに対するexec()族である。 余談。従来Linuxはset*uid()族はNPROCチェックをしてEAGAINを返していたが、execではチェックしていなかった。ついでにいうとforkでのチェックもちゃんとロックされてなかったので、プロセス数の厳密な保証はもとから無かった。NP
革命の日々！ relatimeがどこで実装されているのか調べてみた
ITProのLinuxチューニングの記事がひどい事になっている件について http://mkosaki.blog46.fc2.com/blog-entry-535.html という数本前の記事について、id:shiumachiさんが追試してくれました。 つ http://d.hatena.ne.jp/shiumachi/20080605 むむむ、すばらしいです。 特にrelatimeのあたりが秀逸です。relatimeの性能測定って他にあんまりないのではないかしら。 複数の方からご指摘いただいておりますが、noatimeはあの記事のなかで数少ない、現在でも意味のあるオプションです。 せっかくなので、お礼がてら、relatimeについてちょいと追記してみます。 まず、atimeまわりのオプションの意味から デフォルト： 常にatimeを更新する noatime： 常にatimeを更
革命の日々！ RHEL6 S390用チューニングパラメタ推奨値解説
RHEL6のドキュメントページ（※）みてたのだけど ※ http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/ Technical Notes: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Technical_Notes/index.html に面白いチューニングパラメタの記述をみつけたので解説してみる。S390向けのチューニング推奨値の部分だ ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー System z Performance Some of the default tunables in Red Hat Enterprise Linux 6 are curr
革命の日々！ XFS on x86_64
XFS on x86_64はまったく実用的ではないとかなんとかいう議論をLKMLでしている。XFSって１ページ 書き出すだけでもスタック3.5Kも使うのよね。カーネルスタックはページサイズx2なので8Kしかない。 よって なんか色々処理 +- kmalloc +- メモリ不足なので回収 +- pageout +- writepage + kmalloc +- このへんでさらに割り込み とか考えるとあきらかに突き破っていて、LVMやMDやNFSを使うとそんな複雑なパターンを 考えなくても正常系で普通に突き破るという。David Chinnerが既知の問題で直せないと 言っているからには、本当にダメなんだろう。 世間の人がどうやって回避しているのか知りたいものである。
革命の日々！ Get a better CPU
KVMでEPTだと従来よりもTLB missのコストが上がってるからページテーブルサイズを 大きくするメリットが大きくて、だから透過的hugepageが必要で、実際に性能向上が あって・・・とか説明してる。 で、6%なんてたいした改善じゃないというLinusに「ちがうちがう。hostは+50%以上改善していて その影響でゲストが何も変更しないでも6%改善するって言ってるんだよ」とAndreaが 説明している On Tue, 6 Apr 2010, Andrea Arcangeli wrote: > > In short I first measured the page fault improvement in host (~+50% > faster, sure that has nothing to do with pmd_huge or the tlb miss, I > said
革命の日々！ sched_getaffinity()の修正が入った
忙しくて二週間ぐらい気づいていなかったが、一ヶ月ぐらい前に直した sched_getaffinity()の非互換対処バグがマージされたようだ。 非互換といってもカーネルがバグを入れたわけではなく、 あるディストリ（Fedora?)がカーネルをNR_CPUS=4096に変えた にもかかわらず、glibcはABI互換のためcpuset_tがNR_CPUSが 1024(or それ以下）だと決めうったコードから変えられないので、 結果として引数矛盾で常にEINVALがかえってしまっていた。 ところが、笑えることに世界唯一の4096CPUを持っているSGIは SUSEを使っていて、SUSEは独自パッチをglibcにあてて、glibc側の cpuset_tを4096bitに拡張しているので被害０． 被害にあっているのは小さいマシンを使っている しもじものユーザーだという。 あまりにも馬鹿らしいのでsc
革命の日々！ OpenSSL 1.0.0 released
http://news.slashdot.org/story/10/03/29/1952215/OpenSSL-100-Released?art_pos=5 リリースされちゃったみたい。0.9系と色々と非互換があるので中の人にはもうちょっと頑張って欲しかったのだが。
革命の日々！ 今日のstable tree reviewすごいな
革命の日々！ Home ＞ 今日のstable tree reviewすごいな プロフィール Author:kosaki 連絡先はコチラ ブログ検索 最近の記事 引っ越しました (12/30) THPの記事にちょっと追記した (09/10) Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？ の件について (09/09) transparent hugepage considered harmful (09/02) sosreportで OpenStackのログ (07/20) robocopy の使い方 (12/12) Windows 再インストールした (11/20) RHELのO_SYNCって面白い事になってるんだなあという話 (10/21) RHEL7でスクリーンセーバー無効化 (09/03) commit 直前にChangeLogの日付を変更する (08/15
革命の日々！ reverseパッチの簡単な作り方
革命の日々！ Home ＞ reverseパッチの簡単な作り方 プロフィール Author:kosaki 連絡先はコチラ ブログ検索 最近の記事 引っ越しました (12/30) THPの記事にちょっと追記した (09/10) Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？ の件について (09/09) transparent hugepage considered harmful (09/02) sosreportで OpenStackのログ (07/20) robocopy の使い方 (12/12) Windows 再インストールした (11/20) RHELのO_SYNCって面白い事になってるんだなあという話 (10/21) RHEL7でスクリーンセーバー無効化 (09/03) commit 直前にChangeLogの日付を変更する (08/15) 最近のコメン
革命の日々！ Is 7 years of RHEL support still sufficient ?
LWNの記事(http://lwn.net/Articles/351298/)経由で知ったのだがRHELのサポート期間が７年というのに不満の声があるようだ。 元発言Blog： http://dag.wieers.com/blog/is-7-years-of-rhel-support-still-sufficient 要約すると ・現在のRHEL5は2014年3月までしかサポートされない ・ハードウェアの切り替えサイクルは平均で４年（米国での話の気がするな） ・2010年時点でRHEL6はまだ出荷されていない(or 管理者が評価中で実運用に投入できない） と、考えると、2010年はRHEL環境でビジネスがしにくい。RHEL5のEOL(End of Life)がハードウェアの切り替えより先に来てしまう。 という感じらしい。たしかに問題だなー やっぱ１０年ぐらい欲しいよね。サポート期間。欲しいと
革命の日々！ A new GCC runtime library license snag?
http://lwn.net/Articles/343608/rss 新しいgccで、GPLv2のプログラムをコンパイルすると再配布不可能になるよ。という話。よく知られているように、gccはコンパイル時に（勝手に）libgccをリンクする。これは除算のサポート等が含まれている。うろ覚えだけどC++の例外の補助コード等もここ。 んで、勝手にリンクされる都合上、あんまりきつい制約に出来ないのでGPLなんだけど、特別免除としてプロプラなライセンスとリンクしてもOKということにしてあげるよ。ということになっている。 で、このGCC runtimeのライセンスが、gcc 4.4からGPLv3になった。で、プロプラなライセンスは従来の特赦条項で救われるのでOKだけど、GPLv2は再配布時にライセンス変更しちゃダメ条項があり、かつ、GPLv2とGPLv3はincompatibleなので、自動的にライセン
革命の日々！ prelink 死ね
という議論があるようだ。 http://lwn.net/Articles/341244/ ・なんか、失敗するとシステムがブートしなくなるのでリスキー ・二週間に一回しか、ライブラリアドレスが変わらなくなるので、セキュリティが落ちる ・最近の32bit x86だとVDSOがランダムなアドレスに配置されるので、 prelinkが前提としている、ライブラリのロードアドレスは事前に計算できるはず。という仮定は くずれている。 よく、glibc と VDSOが衝突してるよ ・だいたいSELinuxが受け入れられてるぐらいなんだから、たいていのユーザは そこまで、パフォーマンス気にしてないんだよ ・結局、体感できるほど効果あるのってOOo使った時だけだよね。システム全体に 手を入れる話なのかなぁ？
革命の日々！ @ITのmeminfoの見方の説明が完全に間違っている件について
http://www.atmarkit.co.jp/flinux/rensai/tantei01/bangai01c.html Activeはページキャッシュや無名ページ（注3）のうち、最近利用したり、まだストレージとの同期が取れていない「捨てられない」ページです。Inactiveは、同じくページキャッシュや無名ページのうち、最後にアクセスされてからある程度時間がたち、ストレージとの同期も完了していて、すぐに捨てられるページです。よって、/proc/meminfoの出力でいうところの MemFreeとInactiveを足すことで確実に利用可能なメモリ量を算出することができます。 （実際に利用可能なメモリ量）≒（MemFree＋Inactive） この値を利用し、一定量を下回らないようにするのが、簡単・確実なメモリ利用率監視法といえます。 間違ってる。完全に。 たぶんNTT OSSセンタとい
革命の日々！ Reiser4なんて誰も使ってないから-mmから落としましょう
革命の日々！ Home ＞ Reiser4なんて誰も使ってないから-mmから落としましょう プロフィール Author:kosaki 連絡先はコチラ ブログ検索 最近の記事 引っ越しました (12/30) THPの記事にちょっと追記した (09/10) Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？ の件について (09/09) transparent hugepage considered harmful (09/02) sosreportで OpenStackのログ (07/20) robocopy の使い方 (12/12) Windows 再インストールした (11/20) RHELのO_SYNCって面白い事になってるんだなあという話 (10/21) RHEL7でスクリーンセーバー無効化 (09/03) commit 直前にChangeLogの日付を変更する
革命の日々！ 連載中止するかも
ジェットコースター的展開 某連載の編集者様から、不況だから原稿料下げますというメールが来た。むーん、そんなに不人気だったのか。しかも割合がでかい。 元々、執筆にはかなり時間を取られていたので時給閑散では最低賃金を大幅に下回っており、時給閑散では被害がすくないのだが、これって自己欺瞞だよな。とかとか LKMLを全部読むというのはヨガの賢者も真っ青の苦行だったので、やめるなら今がチャンスでもある。 現在、関係者と鋭意協議中。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
革命の日々！ git のsha1は何桁あれば安全か
革命の日々！ phoronix.com に飛ばし記事をくらった件について
革命の日々！ top(1)のSWAPフィールドは何を表示しているか