ディバイスドライバをハックしよう！

ディバイスドライバの改造、製作にまつわる情報交換、質問、
噂話、ぐち、政治、経済に関するスレです。できる限り生産的にいきましょーや。

>>739
Do! Do! Do!

do_fork

mmapで特定のデバイスのIOメモリを仮想空間に割り付けて，
その領域に対してユーザーからデータを書き込むことを考えています．

ユーザープログラムからその領域上に，あるデータ型の双方向リスト
を作りたいのですが，ユーザー空間の特定のアドレス範囲から空き
メモリ領域を動的に確保する方法ってないでしょうか

void *dev_malloc(start_address, end_adress, nbyte);
とすると仮想アドレスstart_address〜end_adressの範囲から
nbyteバイトの領域を確保するみたいなイメージです

>>743
かーなーり スレ違い
デバイスドライバ関係ない
汎用heap管理ライブラリがほしいってことだろ

heap-management とか ヒープ管理 でぐぐってみそ

ちなみに
void *dev_malloc(start_address, end_adress, nbyte);
ってI/Fはありえないと思うぞ
毎回 start_addressとend_adressを与えるわけ??

あげ

あげ

ドライバでCPUキャッシュのフラッシュやりたい！
どうやるの？だれかおせぇ〜てぇ〜

>>747
CPUキャッシュのフラッシュをする命令を実行すればいいんじゃない？
CPUはなに？

>>748
Xeonの5100です。
データシートとか見つからなくて。。。
ご存知でしたら教えていただけませんか？

<経緯>
Linuxマシンで、DMAでPCIeのデバイスからホストメモリにデータ転送
したときにキャッシュのせいか、2周目のリングバッファ領域が
うまく参照できていなく、フラッシュすればと思いました。。

>>ORE
ttp://www.intel.com/products/processor/manuals/index.htm

Linux 2.6.22 ARM9マシンでシリアルコンソールでデバッグするためにカーネルコマンドラインで
console=uart,mmio,0x80004600,57600n8
とすると、カーネルの初期化中に
early_uart_console_init()→register_console()→early_uart_setup()→parse_options()→ioremap()→__arm_ioremap()→__arm_ioremap_pfn()→get_vm_area()→__get_vm_area_node()→kmalloc_node()→kmalloc()→kmem_cache_alloc()
が呼ばれてkmem_cache_alloc()でこけます。
slabアロケータがまだ初期化されていないのにkmem_cache_alloc()が呼ばれているのがこける原因と思うのですが、armマシンでもearly_uart_consoleは使えるのでしょうか？

新年あげ

>750
749じゃないけど，これいいな．サンクス．
みんなチップのデータとかはどこから調べてくるの？
ちょっと想像してみたけど，「とりあえずメーカサイトを調べる」
以外の方法がわからん．
windowsのドライバから情報調べたりする人もいるの？
いたらその解析方法とかおしえてください．

>>753
メーカに電話して聞く

>>749
Intel の CPU だとその手のキャッシュのことは気にしなくていいんじゃなかったっけ?
いわゆるバススヌープ。ま、明示的にフラッシュしたきゃできるだろうけど。
（実は俺自身は x86 以外用のドライバしか書いたことがないので聞きかじりだが...）

あと、キャッシュが効いているなら1周目でも駄目な場合がありそうだがどうなん?
単にリングバッファのアリゴリズムでしくじってたりして。

って、よく見るとえらい昔の書き込みだった。もう解決したのかな。

チップの購入先の営業から入手とか
チップベンダのwebサイトからダウンロードだろ
常考

今馬本の第 3 版読んでんだけど scull のソースコードって
Web でダウンロードできるの?

あるよ

>>758
早速ありがとう．
本を斜め読みしてるんだけど URL が見当たらないです．
検索しても見付からないし，もしよろしければ教えていただけますと
うれしいです

>>759
>>80

>>759
ありがとう! 3版のは FTP で以下からダウンロードできました．

ar.linux.it/pub/ldd3/ldd3-samples-1.0.0.tar.gz

かなり感謝です ありがとう

自分にお礼ちまった

>>761の「>>759」は >>760 の間違いです
>>760さんありがとう

>>761
あれ？お馬さんの第３版それなの？
日付が気になるので、第３版翻訳本に載ってたのをこぴぺ

ftp://example.oreilly.com/pub/examples/linuxdrive3
examples.tar.gz 70 KB 2005/05/12 0:00:00

ちょいとだけ新しいかも。同じくLinuxデバドラはじめる所なので
よろしく〜。Win系でWDM書いてました〜。

kaso

ドライバでのロックの掛け方とか
その変のデザインパターンみたいなもの
ないのですか？

馬本読んでも、DualSocket　４コアとか
その辺の場合どうすればいいとかまったく
書いてなくて困ってる。

CPU毎にあるモノを意識しなければならないのか
全リソースを意識した作りなのかの判断も
ケースバイケースとかだし。WDMの方がいいよね

>>765
スピンロック様

WDMってよく知らないが、割り禁、スピン、寝る&起こす以外に
排他の方法があるの?

そもそも排他なんじゃねーの？
昔はLinuxも明示的にスケジュールよぶまで
カーネル空間は排他だったじゃん
SMPが出てきて全部直す羽目になったけど

割込みハンドラ

過疎

「新着1件ってことは、いつもの良スレ上げ厨かなぁ」と思ったらそう来たか。

基本的にPCIデバイスにデータ渡すだけのドライバを作ってるのですが、
I2Cデータ転送もしたいといわれ、苦戦中につき質問させて下さい。

カーネルリリースは2.6.11-1.1369_FC4

今のところインクルードしてるのは下記ヘッダーです。
linux/module.h
linux/kernel.h
linux/pci.h
linux/pci-dev.h
asm/uaccess.h
unistd/.h
sys/ioctl.h
sys/perm.h

I2Cのオープンのために、これにfcntl.hを加えたところ、dev_tの型などが再定義されたとエラーが出ます。


また、KERNELDIRを取得して、その場でMAKEしているため
Makefileにて、環境変数C_INCLUDE_PATHに/usr/includeを設定しているのですが
fcntl.hを除いてコンパイルしてもclose, ioctl等が未定義と警告されます。

これらエラーや警告の対応に行き詰まってしまいました。
インクルードに過不足あるのか、Makefileが悪いのか、そもそもPCIドライバからI2Cを叩く方法が悪いのか…
アドバイス等お願い出来ますでしょうか。

デバイスドライバでunistd.hなんかincludeしちゃダメだろ
fcntl.hも同様

何言ってるのかわからないなｗ
PCIデバイスとして、I2Cバスへのブリッジが載っているのか？
それとも、PCIバス/デバイスとは関係なく、全く別のI2Cバス上のデバイスをアクセスしたいだけなのか？

>>773
やっぱりダメですか。

というか、無理やり環境変数使ってコンパイラのエラーを抜けてる（unistd.h以降3ヘッダ、加えてfcntl.h）のは全部includeしちゃダメですかね。

>>774
＞PCIデバイスとして、I2Cバスへのブリッジが載っているのか？
＞それとも、PCIバス/デバイスとは関係なく、全く別のI2Cバス上のデバイスをアクセスしたいだけなのか？

PCIデバイスにI2Cバスへのブリッジが載っている、のはずです。

つーかさ
カーネルモードで動いてるデバイスドライバの中から
open()とかclose()とかioctl()みたいなシステムコールを
発行できるわけないだろ?

>>772が作りたいと思ってるのは root権限で直接I/O叩くだけの
ユーザランドで動くアプリなんじゃないのか?

>>775
じゃあ、そのPCI-I2Cブリッジのデバイスドライバを書いているんだとして、
>I2Cのオープンのために
なんで、こうなるのよｗ　
とりあえずDocumentation/i2c/summaryでも読んでくれ。

>>776
呼んじゃダメなんですね。了解しました。
先週までアプリしかやったことがなく、ついそっち寄りな考えに、と、蛇足でした。失礼しました。

>>777
あー、確かに。
教えていただいたものを読んでみます。
ありがとうございました。

>>773
そういえば、しちゃダメだ ってどこにも書いてないな
わからない奴はわからないんじゃないか？

ちょっと相談なんだが、いいかな

writeの中で長時間割り込み待ちをするような処理と、その場で終わる処理を持ったデバドラがあって、
(処理の切り替えはioctl)
まずアプリAが長時間かかる処理のためにwriteわ呼び出す。

当然割り込み待ちになるが、そのままアプリBがioctlやwriteを呼び出すとどうなる？
普通に処理出来る？

一つのデバイスを二つのアプリで同時に使うっつー事ですか？

>>781
その通りで。
ただ、1つのアプリがマルチスレッドになってるという場合もありでお願いしたい

できるかどうかは作り方次第だろうな

資源の排他処理が必要なら、ロック使わなきゃならん
その場合は、すぐ終わるはずの処理ももちろん待たされる

待たせたくなけりゃ、長時間かかるというwriteにバッファを設けて
write処理と割り込み処理とを分離するみたいな工夫したらどうだ

的外れならスマソ

>>783
資源は共有しないからロックはいらなさそうだ
writeにバッファを設けて処理を分離ってのがイマイチわからんのだけど、説明頼んでもいいかい？
デバドラの中でもスレッドとかで並列にするの？

シリアルポートを想像してみたらどうだろう
Write、Read、割り込みがそれぞれ並列に動くはずだ

Writeで割り込み使ってるかどうかは知らないけど

ブロック と ノンブロック という用語を使ってほしいところだな

んで複数プロセスから同時に使えるかどうかはデバイスドライバの作り方次第
手抜きにつくると open()されるときに競合問題を判断して
同時にひとつとかopenできないようにするよな

複数同時にopenして、ひとつがブロックしてる時に
また別のがノンブロックの処理要求してきたなんて場合は
そういう風にうまく動くようにドライバの中で考慮する必要がある

追記

呼び出し側がマルチスレッド使ってるかどうかはあまり関係ない
ふたつのプロセスがメモリを共有してようがしてまいが
ドライバにとっては関係ない話だ

それよりCPUが複数ある(いわゆるSMP)かどうかの方が重要
smp対応させるなら必要なところできっちりspinlockしないとダメ

>>787-788
ブロック=長時間処理
ノンブロック=即時処理
でおｋ？

複数からopenされるのはアリにしないといけないっぽいんで、考えてみる。

ブロック中にアプリBからもwrite自体は呼び出せる？
その時点で破綻してるなら、今のwriteをそのままスレッド化して、write自体はスレッド起動だけにするなりで対応とか…ダメかな

あとCPUは1つ前提でおｋっす。
余裕があったら後学のためにもsmp対応も抑えておきたいがｗ

> ブロック中にアプリBからもwrite自体は呼び出せる？
もちろん呼べる

ブロック処理とは、簡単にいうと処理開始をデバイス(ハードウェア)に
通知したあとスリープ状態に入り、処理完了割込が入ったら
割込ハンドラがスリープ(ブロッキング)しているプロセスを
たたき起こすって流れ。

アプリAがスリープ(ブロッキング)している間に
アプリBからreadなりwriteなりが発行されるのは当然ありうる話。
ちゃんとドライバを書いておけば問題なく動く。

linuxカーネルのソースコードそのものがいいサンプルコードだから
いろいろ読んでみるとよい。

それから、procfs(/procの下に仮想ファイルをつくる)に
状態監視・デバッグ操作用のI/Fを用意しておくと後々楽になるよ。

>>789
凄く参考になった！
ありがとう

>答えてくれた人達
いろいろありがとう

ttp://www.atmarkit.co.jp/fsecurity/rensai/rootkit03/rootkit02.html

上記を参考にシステムコールをフックするプログラムを書きました（そのままでは駄目なので必要に応じて修正しています）。
コンパイルすると、

original_sys_uname = sys_call_table[sys_uname];
sys_call_table[sys_uname] = hook_uname;

のsys_unameで　`sys_uname' undeclared (first use in this function)　とエラーがでます。
これは arch/i386/kernel/syscall_table.S をインクルードしておく必要があるのでしょうか？

使用しているカーネル：2.6.23

>>791
よく知らんけど、これよめ。
System calls replacement
ttp://kerneltrap.org/node/5793

nm -uでundefinedなシンボルが置き換えらればいいだけなら、
LD_PRELOADなりLD_AUDITをつかってどうにかしたほうがいいんじゃね？
そうなら、以後下へどうぞ。

Linuxプログラミング
http://pc11.2ch.net/test/read.cgi/linux/1118024349/

>>791
sys_call_table[NR_uname] = hook_uname;
の様な気がするわけですが。

>>792
それはユーザー空間で乗っ取る方法ですがな。

>>792-793
試してみます。
情報ありがとうございます。

>>791
乗り遅れたか！？

Linux 2.6からシステムコールのフックはできません。
パッチ当てなきゃできないようなことが
ttp://tldp.org/LDP/lkmpg/2.6/lkmpg.pdf
8章にそのようなことが書いてあったはず。

記憶が確かなら、792の示したサイトの
unsigned long **sys_call_table = find_sys_call_table();を
加えればできたと思う。

>>791
パッチを当てるのが嫌ならLSMを使ったらいい。
決まった関数で始めるとか、とかsecurity_operations構造体に登録するあたりとか
デバドラに似ているからsecurity以下を読めば使えると思う。

>>795
どうもです。
あれから色々調べたら>>795の言うとおりに2.6.xからはできないみたいですね。
下記のURLに書いてある。i386_ksyms.cに

extern void* sys_call_table[];
EXPORT_SYMBOL(sys_call_table);

を、追加・再構築してやってみようと思います。

ttp://mail.nl.linux.org/kernelnewbies/2006-05/msg00334.html

>>791
調べもせずに書いてるけどLinux版のウィルス対策ソフトのお試し版に
運がよければカーネルモジュールのソースが含まれていて、なおかつ、
それがシステムコールのフックしていたりしないか？

>>798
そのようなことはございません

あげ

init中にalloc_chrdev_regionでデバイス番号を動的確保した後で、
そのまま(関数内で)スペシャルファイルを作成する事は可能？

mknodコマンドでなく、あくまでｲﾝｽｺだけで済ませるように出来ないかと…

udevじゃダメなの?

>>801
オレならprocなりsysなりのみで済ます

>>802>>803
それだとinsmod以外にも必要になるんじゃないんですか？
関数で無いですかね
(init_moduleから呼び出す)

insmod hoge
だけ実行すればアプリから叩けるような形にしたいんですが…

shell スクリプト作ってその中で insmod、mknod すれば？
rmmod も出来るようにすれば、なお良いでしょ？

>>805
それが良さげですね。
ありがとうございました。

>>801
mknodしたくないってだけなら、device_create(9)か、手を抜きたいなら
misc_register(9)に全部にまかせれば、>>802が言ってるように、udevが勝手に
スペシャルファイルを作ってくれるんじゃないか？

ブロックデバイスのブロックサイズってどこで決まってるの？
ユーザアプリから見る方法ある？

>>808
mkfsする時に決まると思うが。
ext2/ext3 なら tune2fs -l で見るか、ファイルがあれば stat構造体の st_blksize を見る。

>>808
そのブロックデバイスドライバが制御しているハードの規格によりだね。
SCSI系ならMode Senseコマンドで取れたんじゃないっけ？

>>808
試してないけど、blktool(8)のblock-szコマンドでいけそうかもね？

>>809
フォーマットする前に最適値を知っときたい乙女心です

>>810-811
ありがとう。でもハードの規格というよりブロックデバイスとして
なんかその辺を返してくれるioctlなりなんなりがあったらいいな
とか夢想してた

>>807見て、misc_register調べてちょっと使ってみたんだけど、
これで作ったもんどうやって消すんだ？

関数自体は使い方分かったが、対になるもの無い？
misc_register込みのinsmod→rmmod→再度insmodでハングするんだが

書いた直後に自己解決しちまったorz

misc_deregisterがあるのね…
スレ汚しすまんかった

ほ？

mmapを利用して物理アドレス0x10000000に存在するデバイス(SRAM)のR/Wを
行うドライバを作成しようと思っています。
馬本の第３版のサンプルソース(simple)を参考にしながらremap_pfn_rangeで
マッピングし、ダンプをとってみたところ、0x10000000エリアのデータでは
なく、全て0のデータが読み取れました。
0x1000等の小さい物理アドレスであれば正常にリード出来ているようです。
0x10000000のように上の方のアドレスは、remap_pfn_rangeではマッピング
されないのでしょうか？

カーネルのバージョンは2.6.11です。

/dev/mem openして
memmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x10000000)
memmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x1000)
でも同じ結果でした・・・

訂正
>>817
>memmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x10000000)
>memmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x1000)
mmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x10000000)
mmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x1000)

訂正
>>817
>memmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x10000000)
>memmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x1000)
mmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x10000000)
mmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x1000)

Linux 2.6.11 使ってないしためしてないけど、
/sys/devices/pci*/*/resource? を mmap(2) って出来ないんだっけ？

とりあえず、落ち着けｗ
man mmap2

>>821
>man mmap2
↓ですよね？
http://www.pinkdragon.net/doc_lib/contents/ja/linux_man/mmap2.2.html
Linux 2.3.31 以降で使用可能とありますが、この環境では定義されていないと言われます。
組込み系だからなんでしょうか・・・

それと馬本第３版のP437　15.2.6 RAMのマッピングを変更する　に
「ramap_pfn_rangeがRAMを扱えないことは・・・」ってくだりがあります。
実際いま起きている問題はこれなんでしょうか？
ioremap_nocacheでReadする方法とダンプ比較したところ,mmapだと
0x00000000〜0x00800000 あたりまではちゃんとよめますが、
0x01000000になったとたん、0x00000000の値になってしまいます・・・
ioremap_nocacheでは0x01000000も見れるのに・・・

MTD使えばいいんじゃない?
phram.koとか
slram.koとか

タスクレットの中でsleep_on_timeoutって呼べないんですか？
なぜかカーネルパニックになってしまいます…

タスクレットからkill_fasync()呼びたいんですけど、
第一引数ってどこから持ってくればいいんでしょうか？

フリーオのデバイスドライバー書ける人が居たら神！

玄箱用のは、あるだろ

あげあげ

ttp://pc11.2ch.net/test/read.cgi/linux/1213378360/

やっぱり情報公開されてない物のドライバ造るのって無理がある？
Willcomスマートフォン端末でLinuxを動かすプロジェクト？があるのですが、
WS003SH、WSはPrismチップの無線LANを使用。
WS011SHではSharp独自のチップを使用した物のようです。
WS020SHは不明。

当方WS011SHの物の開発に興味があるのですが、難しいどころか情報の公開がされていない限りは
手すら付けられない状態でしょうか？
アドバイスよろしくお願いします。

copy_{to,from}_user()でユーザプロセスのアドレスを与えるところにカーネル空間のアドレスを与えるとどうなります？
やっぱりaccess_ok()で弾かれる？

>>831
その程度、自分で確認しろ。

あげ

Linuxデバドラ移植の質問です。
雑誌の記事でx86Linuxデバドラを他CPUのLinuxに移植する際に、デバドラのソースが
x86に依存してて移植できないことを知りました。
どうやらx86プログラマが他のCPUへの移植性を考えずに開発したことが原因みたいです。

雑誌によるとデバドラの依存箇所は以下が多いようです。
・バイトオーダ
・アライメント
・I/Oアクセス
・タイミング

皆様に質問ですが、このようなx86に依存したLinuxデバドラが落ちている場所を
ご存じないでしょうか？
また、根本的なことですがx86Linuxデバドラを移植したり、移植しようとしたが
x86に依存してて大変だったという案件は多いのでしょうか？

どうぞよろしくお願いいたします。

>>834
drivers/

直すのはそんなにめんどくないが、どこに地雷があるかわかりにくいのがのう。

>>834
というか、デバイスドライバは基本的にハードに依存して当然
という側面も否定できないと言わざるを得ないこともあるので。

カーネルソース内にあるんですね！
知りませんでした；

私は初心者でよく知らないんですが、てっきりカーネルソール内のコードって
移植性をちゃんと考えてあって（arch/以外）、管理されていると思ってました。

むしろ、カーネルソース外の開発（企業or個人）で公開されているドライバに
あるのかと思ってました。

>>834
ふつー開発者の持ってるCPUでしかテストしないよ。

tg3とかe1000とかはNEC(ia64)とかIBM(powerpc)とかが
頑張って自分とこのハードで動くようにしてるけど、
個人でハックしてるものはたいていx86だけ。

まあ、過去の経験からすると
・USBターゲット - ほとんど手を入れる必要無し
・PCI - そんなに苦労することはない
・CPU直結 - 健闘を祈る
てところですかねえ。

age