【 SKATEMAN L/SL TEE 】 【 BASIC CUFF BEANIE 】 塗料染色意思是說這種水洗方法是專為經過塗料染色的服裝而設的,其作用是鞏固原來的艷麗色澤及增加手感的軟度, ... ... <看更多>
lsl意思 在 【Free Fire】蹦蹦特務,新寵登場,難道又是一隻花瓶寵物嗎 ... 的推薦與評價
![影片讀取中](/images/youtube.png)
不過這遊戲從以前到現在儲1鑽的 意思 就是至少儲100鑽...另外,戰隊招收週五愛刷分拿房卡等獎勵的新夥伴 ... 羅小力 LSL. 羅小力 LSL. 1.36K subscribers. ... <看更多>
lsl意思 在 cp品管 :: 全台大學開課課程資訊網 的推薦與評價
全台大學開課課程資訊網,cp cpk差異,cp計算公式,製程能力分析,usl lsl意思,ca cp cpk公式,USL LSL,何謂製程能力,cpk計算範例. ... <看更多>
lsl意思 在 [問題] kernel module 區域變數記憶體- 看板LinuxDev 的推薦與評價
大家好,想請問kernel module的function中array of struct與struct的記憶體配置方式
是不是不一樣(變數為函數中直接宣告,未使用kmalloc)?會這樣問是因為最近在寫作業時
遇到使用copy_to_user複製一段記憶體內容到userspace時只要複製的內容是array of
struct就會panic,log如下:
usercopy: kernel memory exposure attempt detected from 00000000e7ee16e5
(<process stack>) (16 bytes)
但只要把原本要複製的內容放到同個資料結構的struct中就可以正常copy...,以下是複
時用到的資料結構:
struct U64 {
unsigned long long msl;
unsigned long long lsl;
};
然後餵給copy_to_user的arg(size)都一樣是16 bytes。目前推測array of struct配置的
成員記憶體是不連續的,可是kernelspace的virtual address讓我在debug時看到的記憶
體都是不連續的(array of struct與struct),所以不確定這樣推測是否正確。
不知道各位前輩有什麼看法,謝謝大家!
**更新**(補上程式碼),以下為可以正常運作的程式碼,原本有問題的版本是使用fib(ar
ra
of struct)做複製(copy_to_user(buf, &fib[g - 1], size)),另外,size一直都是16
bytes:
static long long fib_sequence(long long g, char *buf, size_t size)
{
unsigned long long a;
a = 10000000000000000000;
struct U64 fib[g + 1], tmp = {0};
memset(fib, 0, sizeof(struct U64) * (g + 1));
int k;
fib[0].lsl = 1;
fib[1].lsl = 1;
for (k = 2; k <= g; k++) {
fib[k].lsl = fib[k - 1].lsl + fib[k - 2].lsl;
fib[k].msl = fib[k - 1].msl + fib[k - 2].msl;
if (fib[k].lsl > a) {
fib[k].lsl = fib[k].lsl - a;
fib[k].msl = fib[k].msl + 1;
}
}
tmp = fib[g - 1];
copy_to_user(buf, &tmp, size);
return 1;
}
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.213.161.228
※ 文章網址: https://www.ptt.cc/bbs/LinuxDev/M.1553628544.A.D7C.html
※ 編輯: dces4212 (49.213.161.228), 03/27/2019 03:40:15
要單用struct就不會出問題。會考慮kmalloc的,感謝。目前推測觸發BUG()的地方是這裡
(因為就連g很小的時候都有問題,就不太可能是#L50的檢查了)
(https://elixir.bootlin.com/linux/v4.15.18/source/mm/usercopy.c#L54),#L54做的
檢查其實看不太懂,#L50已經檢查過是否要複製的範圍在stack內,不知道這個是不是檢
查是否為stack內可存取的記憶體,註解寫的if object is safely感覺又不太像這意思,
不知道大大有啥看法。
※ 編輯: dces4212 (49.213.161.228), 03/28/2019 01:13:03
[ 4167.013170] usercopy: kernel memory exposure attempt detected from
00000000e7ee16e5 (<process stack>) (16 bytes)
[ 4167.013177] ------------[ cut here ]------------
[ 4167.013178] kernel BUG at
/build/linux-7kdHqT/linux-4.15.0/mm/usercopy.c:72!
[ 4167.013183] invalid opcode: 0000 [#1] SMP PTI
[ 4167.013184] Modules linked in: fibdrv(OE)....(已省略)
[ 4167.013262] CPU: 1 PID: 16325 Comm: client Tainted: G W OE
4.15.0-46-generic #49-Ubuntu
[ 4167.013263] Hardware name: ASUSTeK COMPUTER INC. UX430UN/UX430UN, BIOS
UX430UN.302 11/28/2017
[ 4167.013268] RIP: 0010:__check_object_size+0x123/0x1b0
[ 4167.013269] RSP: 0018:ffffbc64858f7e08 EFLAGS: 00010286
[ 4167.013271] RAX: 0000000000000064 RBX: 0000000000000010 RCX:
0000000000000006
[ 4167.013273] RDX: 0000000000000000 RSI: 0000000000000092 RDI:
ffff9ac0eec96490
[ 4167.013274] RBP: ffffbc64858f7e28 R08: 0000000000000000 R09:
0000000000001831
[ 4167.013275] R10: 0000000000000000 R11: ffffffffaff5380d R12:
0000000000000001
[ 4167.013276] R13: ffffbc64858f7e38 R14: ffffbc64858f7e28 R15:
1ffff78c90b1efc7
[ 4167.013278] FS: 00007ff1e9d3d500(0000) GS:ffff9ac0eec80000(0000)
knlGS:0000000000000000
[ 4167.013279] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4167.013281] CR2: 00007fffc3d96080 CR3: 00000003d28fe006 CR4:
00000000003606e0
[ 4167.013282] Call Trace:
[ 4167.013288] fib_read+0x159/0x197 [fibdrv]
[ 4167.013290] ? fib_read+0x34/0x197 [fibdrv]
[ 4167.013293] __vfs_read+0x1b/0x40
[ 4167.013294] vfs_read+0x8e/0x130
[ 4167.013296] SyS_read+0x55/0xc0
[ 4167.013300] do_syscall_64+0x73/0x130
[ 4167.013303] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 4167.013305] RIP: 0033:0x7ff1e9861081
[ 4167.013306] RSP: 002b:00007fffc3d51638 EFLAGS: 00000246 ORIG_RAX:
0000000000000000
[ 4167.013308] RAX: ffffffffffffffda RBX: 0000000000000000 RCX:
00007ff1e9861081
[ 4167.013309] RDX: 0000000000000010 RSI: 00007fffc3d51650 RDI:
0000000000000003
[ 4167.013310] RBP: 00007fffc3d516a0 R08: 00007ff1e9b3dd80 R09:
00007ff1e9b3dd80
[ 4167.013311] R10: 00007fffc3d51620 R11: 0000000000000246 R12:
000055f6d8e947c0
[ 4167.013313] R13: 00007fffc3d51780 R14: 0000000000000000 R15:
0000000000000000
[ 4167.013314] Code: 48 0f 45 d1 48 c7 c6 53 f2 6d af 48 c7 c1 ef ff 6e af 48
0f 45 f1 49 89 d9 49 89 c0 4c 89 f1 48 c7 c7 f8 ff 6e af e8 fd dd e7 ff <0f>
0b f3 c3 48 8b 3d 82 18 1a 01 48 8b 0d 13 99 1d 01 be 00 00
[ 4167.013369] RIP: __check_object_size+0x123/0x1b0 RSP: ffffbc64858f7e08
※ 編輯: dces4212 (49.213.161.228), 03/28/2019 21:31:09
發現有意思的地方了...,g=0的時候只要用tmp=fib[-1]再把tmp餵給copy_to_user就不會
觸發BUG(),但假如直接餵fib[-1]給copy_to_user就會panic。推測先餵給tmp這邊沒有檢
查是否非法存取所以沒事(目前在userspace測試只能往後拿到6KB左右的資料,之後就被
seg fault了,而kernel space是比較有趣的地方,只要我不把往後拿拿到的資料餵給
copy_to_user,我往後-20000 * 16 byte (struct大小為16bytes)都可以拿到,但假如要
傳到userspace我只能在stack frame(16KB)內偷資料,只要超過就會被panic,這邊很怪
的
地方是kernel怎知道我這tmp裡面偷拿了甚至超過stack frame(16KB)的資料,目前猜測是
kernel 自己有個trap之類的機制隨時在監測是否有access violation)。
另外我是用GCC編譯的。
感謝兩位大大,讓我知道根本不是array of struct跟struct記憶體配置差別,是我自己
在copy_to_user面前非法存取了哈哈。
※ 編輯: dces4212 (49.213.161.228), 03/31/2019 21:25:14
忘記補充一點,剛剛測試發現當g=0的時候我對fib[0]賦值後再使用copy_to_user會發生
copy失敗的問題(copy_to_user回傳了16 bytes),蠻怪的..,g>0後都可以正常複製。
※ 編輯: dces4212 (49.213.161.228), 03/31/2019 22:05:31
程式碼幾乎一樣,一開始是發現g=0時userspace拿到的資料是0(應為1,fib[0]=1),這時
候覺得很奇怪所以就加個if(g=0) {printk(當下的fib[0].msl, lsl 還有copy_to_user的
ret val)},然後發現fib在kernelspace是有拿到1的,還有copy_to_user的ret是16(複製
失敗大小,成功應為0),差不多是這樣。手機排版,sorry.
※ 編輯: dces4212 (101.10.82.251), 04/05/2019 16:00:31
沒錯,fib[1].lsl=1;這段每次都會執行到。剛測試了一下,發現確實是這個assigment去
改到buf的內容,會確定的原因挺詭異的,我最先是在assigment前後放printk看buf的內
容,然後只要我保留那段assigment,我新加的printk就會導致panic,而一旦我把那段
assigment 移掉,printk就正常印出位置了...,看來是非法寫入後又嘗試讀取相關記憶
體導致的,這跟之前說tmp偷到的資料只要不copy_to_user就沒事有差不多的概念..,挺
好奇kernel是怎做這個檢查的..,因為這不是直接觸發BUG(),不知道y大有什麼看法?
感謝大大!
※ 編輯: dces4212 (49.213.161.228), 04/12/2019 03:10:28
※ 編輯: dces4212 (49.213.161.228), 04/12/2019 03:11:12
用的參數是%p, &fib[1].lsl 及 &buf 都落在0x0~0xffffffff間(多次測試)
出每一項的結果,其實也可以不用VLA來實做的。
※ 編輯: dces4212 (49.213.161.228), 04/26/2019 05:02:50
※ 編輯: dces4212 (101.9.132.120), 04/26/2019 05:15:12
... <看更多>