Having this:
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#define GB (1<<30)
#define N 10000L //number of virtual blocks(arrays)
int main (void) {
int *ar[N];
for(int i =0; i<N ; i++)
{
ar[i]=malloc(GB); //alloc virtually one GB
if(!ar[i]){
printf("done at %i\n",i);
return 0;
}
}
printf("allocated %li blocks\n",N);
for(int i =0; i<N ; i++)
{
memset(ar[i],2,GB); // get physical gigs for that array
printf("wrote to %i GB\n",i+1);
}
return 0;
}
But I will not get even one:
allocated 10000 blocks //virtual memory (one block==1GB)
wrote to 1 GB //real memory (not really
Command terminated
Press ENTER or type command to continue
I know I have at leaset 4 gigs on my machine and I also know OS has some limit it needs to operate, however I cannot get even 2 GB for user space? That is strange. Can someone explain please?
$uname -a:
`4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux
EDIT:
It gets stranger:
Now if I run (after an hour from the previous output):
allocated 10000 blocks
wrote to 1 GB
wrote to 2 GB
Command terminated
Press ENTER or type command to continue
so it gets through 2 time in for loop, and allocates 2GB of real memory, but before an hour, I catch only 1GB and something (not full 2GB).
addition info:
$free -h:
total used free shared buff/cache available
Mem: 3.7Gi 1.1Gi 2.2Gi 236Mi 404Mi 2.2Gi
Swap: 0B 0B 0B
How can I take advantage from these information? So it is I said -> I have 4GB (total), but can get 2GB. That is maximum for user space?
Note: This answer does not solve the problem OP was having because it's based on fake code originally in the question, and still present in the question after the first request to correct fake code was made and acted upon. It does explain the question as originally asked.
If the code you posted is accurate now, your problem is that you are attempting to call functions without valid declarations for them (I see no #include directives). This is invalid C and the compiler should warn (or ideally error out) if you do it. Always add -Werror=implicit-function-declaration to get it to do that.
The particular mechanism of your crash is likely this: memset takes a size_t (unsigned long) as its third argument, but without a prototype, the function is being called as if the type of the function matched the argument types you provided (subject to default promotions). This produces undefined behavior. 1<<30 has type int, not unsigned long, and on x86_64 ABI, int is passed in the low 32 bits of a 64-bit register, with arbitrary junk allowed in the upper bits. So rather than passing 1 GB to memset, you're passing some astronomically large number.
Possibly a memory or swap limitation.
On a 4GB Ubuntu 18 VM, I get:
$ gcc -o alloc -Wall alloc.c
$ free -h
total used free shared buff/cache available
Mem: 3.9G 154M 3.1G 23M 572M 3.5G
Swap: 2.0G 0B 2.0G
$ uname -a
Linux ub18 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$./alloc
allocated 10000 blocks
wrote to 1 GB
wrote to 2 GB
wrote to 3 GB
wrote to 4 GB
wrote to 5 GB
Killed
$ free -h
total used free shared buff/cache available
Mem: 3.9G 127M 3.7G 1.6M 60M 3.6G
Swap: 2.0G 112M 1.9G
$
syslog says:
May 30 17:57:56 ub18 kernel: [ 240.723065] alloc invoked oom-killer: gfp_mask=0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0
May 30 17:57:56 ub18 kernel: [ 240.723067] alloc cpuset=/ mems_allowed=0
May 30 17:57:56 ub18 kernel: [ 240.723072] CPU: 0 PID: 3062 Comm: alloc Not tainted 4.15.0-101-generic #102-Ubuntu
May 30 17:57:56 ub18 kernel: [ 240.723072] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
May 30 17:57:56 ub18 kernel: [ 240.723073] Call Trace:
May 30 17:57:56 ub18 kernel: [ 240.723088] dump_stack+0x6d/0x8e
May 30 17:57:56 ub18 kernel: [ 240.723094] dump_header+0x71/0x285
May 30 17:57:56 ub18 kernel: [ 240.723096] oom_kill_process+0x21f/0x420
May 30 17:57:56 ub18 kernel: [ 240.723097] out_of_memory+0x116/0x4e0
May 30 17:57:56 ub18 kernel: [ 240.723100] __alloc_pages_slowpath+0xa53/0xe00
May 30 17:57:56 ub18 kernel: [ 240.723102] __alloc_pages_nodemask+0x29a/0x2c0
May 30 17:57:56 ub18 kernel: [ 240.723104] alloc_pages_vma+0x88/0x1f0
May 30 17:57:56 ub18 kernel: [ 240.723107] __handle_mm_fault+0x8b7/0x1290
May 30 17:57:56 ub18 kernel: [ 240.723109] handle_mm_fault+0xb1/0x210
May 30 17:57:56 ub18 kernel: [ 240.723112] __do_page_fault+0x281/0x4b0
May 30 17:57:56 ub18 kernel: [ 240.723114] do_page_fault+0x2e/0xe0
May 30 17:57:56 ub18 kernel: [ 240.723115] ? page_fault+0x2f/0x50
May 30 17:57:56 ub18 kernel: [ 240.723116] page_fault+0x45/0x50
May 30 17:57:56 ub18 kernel: [ 240.723118] RIP: 0033:0x7f6d13bd7963
May 30 17:57:56 ub18 kernel: [ 240.723119] RSP: 002b:00007ffeede7e608 EFLAGS: 00010206
May 30 17:57:56 ub18 kernel: [ 240.723120] RAX: 00007f6b93b16010 RBX: 0000000000000000 RCX: 00007f6bb0993000
May 30 17:57:56 ub18 kernel: [ 240.723121] RDX: 00007f6bd3b16000 RSI: 0000000000000002 RDI: 00007f6b93b16010
May 30 17:57:56 ub18 kernel: [ 240.723122] RBP: 00007ffeede91eb0 R08: 0000000000000000 R09: 0000000000000000
May 30 17:57:56 ub18 kernel: [ 240.723122] R10: 0000000000000000 R11: 0000000000000246 R12: 0000559df7b44640
May 30 17:57:56 ub18 kernel: [ 240.723123] R13: 00007ffeede91f90 R14: 0000000000000000 R15: 0000000000000000
May 30 17:57:56 ub18 kernel: [ 240.723124] Mem-Info:
May 30 17:57:56 ub18 kernel: [ 240.723127] active_anon:780631 inactive_anon:158435 isolated_anon:0
May 30 17:57:56 ub18 kernel: [ 240.723127] active_file:13 inactive_file:10 isolated_file:1
May 30 17:57:56 ub18 kernel: [ 240.723127] unevictable:0 dirty:0 writeback:2 unstable:0
May 30 17:57:56 ub18 kernel: [ 240.723127] slab_reclaimable:4568 slab_unreclaimable:7013
May 30 17:57:56 ub18 kernel: [ 240.723127] mapped:196 shmem:364 pagetables:15033 bounce:0
May 30 17:57:56 ub18 kernel: [ 240.723127] free:21182 free_pcp:60 free_cma:0
May 30 17:57:56 ub18 kernel: [ 240.723130] Node 0 active_anon:3122524kB inactive_anon:633740kB active_file:52kB inactive_file:40kB unevictable:0kB isolated(anon):0kB isolated(file):4kB mapped:784kB dirty:0kB writeback:8kB shmem:1456kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
May 30 17:57:56 ub18 kernel: [ 240.723131] Node 0 DMA free:15736kB min:268kB low:332kB high:396kB active_anon:168kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
May 30 17:57:56 ub18 kernel: [ 240.723133] lowmem_reserve[]: 0 3421 3867 3867 3867
May 30 17:57:56 ub18 kernel: [ 240.723135] Node 0 DMA32 free:61252kB min:59536kB low:74420kB high:89304kB active_anon:2779728kB inactive_anon:629972kB active_file:20kB inactive_file:24kB unevictable:0kB writepending:48kB present:3653568kB managed:3566076kB mlocked:0kB kernel_stack:80kB pagetables:51412kB bounce:0kB free_pcp:120kB local_pcp:120kB free_cma:0kB
May 30 17:57:56 ub18 kernel: [ 240.723138] lowmem_reserve[]: 0 0 446 446 446
May 30 17:57:56 ub18 kernel: [ 240.723139] Node 0 Normal free:7740kB min:7772kB low:9712kB high:11652kB active_anon:342620kB inactive_anon:3748kB active_file:28kB inactive_file:8kB unevictable:0kB writepending:0kB present:524288kB managed:457424kB mlocked:0kB kernel_stack:2096kB pagetables:8720kB bounce:0kB free_pcp:120kB local_pcp:120kB free_cma:0kB
May 30 17:57:56 ub18 kernel: [ 240.723142] lowmem_reserve[]: 0 0 0 0 0
May 30 17:57:56 ub18 kernel: [ 240.723143] Node 0 DMA: 0*4kB 1*8kB (M) 1*16kB (M) 1*32kB (U) 3*64kB (UM) 1*128kB (U) 2*256kB (UM) 1*512kB (M) 2*1024kB (UM) 0*2048kB 3*4096kB (M) = 15736kB
May 30 17:57:56 ub18 kernel: [ 240.723149] Node 0 DMA32: 439*4kB (UME) 357*8kB (UME) 202*16kB (UME) 103*32kB (UE) 37*64kB (UME) 15*128kB (UME) 13*256kB (UME) 9*512kB (UE) 1*1024kB (E) 0*2048kB 9*4096kB (M) = 61252kB
May 30 17:57:56 ub18 kernel: [ 240.723156] Node 0 Normal: 621*4kB (UMEH) 285*8kB (UMEH) 110*16kB (UMEH) 34*32kB (UEH) 2*64kB (MH) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 7740kB
May 30 17:57:57 ub18 kernel: [ 240.723162] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
May 30 17:57:57 ub18 kernel: [ 240.723162] 3052 total pagecache pages
May 30 17:57:57 ub18 kernel: [ 240.723164] 2652 pages in swap cache
May 30 17:57:57 ub18 kernel: [ 240.723168] Swap cache stats: add 527798, delete 525146, find 859/1742
May 30 17:57:57 ub18 kernel: [ 240.723168] Free swap = 0kB
May 30 17:57:57 ub18 kernel: [ 240.723169] Total swap = 2104316kB
May 30 17:57:57 ub18 kernel: [ 240.723169] 1048462 pages RAM
May 30 17:57:57 ub18 kernel: [ 240.723170] 0 pages HighMem/MovableOnly
May 30 17:57:57 ub18 kernel: [ 240.723170] 38610 pages reserved
May 30 17:57:57 ub18 kernel: [ 240.723171] 0 pages cma reserved
May 30 17:57:57 ub18 kernel: [ 240.723171] 0 pages hwpoisoned
May 30 17:57:57 ub18 kernel: [ 240.723172] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
May 30 17:57:57 ub18 kernel: [ 240.723175] [ 396] 0 396 23715 11 217088 164 0 systemd-journal
May 30 17:57:57 ub18 kernel: [ 240.723177] [ 417] 0 417 24427 0 90112 51 0 lvmetad
May 30 17:57:57 ub18 kernel: [ 240.723178] [ 418] 0 418 11706 43 118784 590 -1000 systemd-udevd
May 30 17:57:57 ub18 kernel: [ 240.723179] [ 586] 62583 586 35483 0 184320 151 0 systemd-timesyn
May 30 17:57:57 ub18 kernel: [ 240.723181] [ 755] 100 755 20044 8 176128 176 0 systemd-network
May 30 17:57:57 ub18 kernel: [ 240.723182] [ 782] 101 782 17659 10 172032 157 0 systemd-resolve
May 30 17:57:57 ub18 kernel: [ 240.723183] [ 957] 0 957 17650 8 180224 172 0 systemd-logind
May 30 17:57:57 ub18 kernel: [ 240.723184] [ 959] 0 959 71564 14 200704 214 0 accounts-daemon
May 30 17:57:57 ub18 kernel: [ 240.723185] [ 961] 102 961 65760 0 163840 284 0 rsyslogd
May 30 17:57:57 ub18 kernel: [ 240.723186] [ 962] 0 962 7083 3 102400 49 0 atd
May 30 17:57:57 ub18 kernel: [ 240.723188] [ 963] 0 963 7507 0 102400 75 0 cron
May 30 17:57:57 ub18 kernel: [ 240.723189] [ 996] 0 996 42276 102 217088 1841 0 networkd-dispat
May 30 17:57:57 ub18 kernel: [ 240.723190] [ 997] 0 997 160115 231 233472 4850 -900 snapd
May 30 17:57:57 ub18 kernel: [ 240.723191] [ 1008] 0 1008 23885 0 77824 73 0 lxcfs
May 30 17:57:57 ub18 kernel: [ 240.723193] [ 1012] 103 1012 12571 1 139264 202 -900 dbus-daemon
May 30 17:57:57 ub18 kernel: [ 240.723194] [ 1094] 0 1094 101403 29 401408 641 0 NetworkManager
May 30 17:57:57 ub18 kernel: [ 240.723195] [ 1095] 0 1095 11308 6 122880 131 0 wpa_supplicant
May 30 17:57:57 ub18 kernel: [ 240.723196] [ 1110] 0 1110 108581 10 356352 344 0 ModemManager
May 30 17:57:57 ub18 kernel: [ 240.723197] [ 1167] 0 1167 72221 0 212992 208 0 polkitd
May 30 17:57:57 ub18 kernel: [ 240.723198] [ 1283] 0 1283 46486 96 249856 1879 0 unattended-upgr
May 30 17:57:57 ub18 kernel: [ 240.723200] [ 1450] 0 1450 3722 0 69632 33 0 agetty
May 30 17:57:57 ub18 kernel: [ 240.723201] [ 1531] 0 1531 18075 11 184320 177 -1000 sshd
May 30 17:57:57 ub18 kernel: [ 240.723202] [ 1571] 111 1571 79693 19 331776 484 -900 postgres
May 30 17:57:57 ub18 kernel: [ 240.723203] [ 1578] 111 1578 79781 4 335872 500 -900 postgres
May 30 17:57:57 ub18 kernel: [ 240.723204] [ 1603] 111 1603 79781 1 294912 500 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723205] [ 1604] 111 1604 79781 10 311296 500 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723207] [ 1605] 111 1605 79781 2 303104 507 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723208] [ 1606] 111 1606 79883 97 311296 521 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723209] [ 1607] 111 1607 43543 7 282624 509 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723210] [ 1608] 111 1608 79882 58 303104 528 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723211] [ 1611] 111 1611 79693 0 299008 501 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723212] [ 1612] 111 1612 79693 19 311296 495 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723213] [ 1613] 111 1613 79693 0 307200 506 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723214] [ 1614] 111 1614 79794 71 315392 530 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723216] [ 1615] 111 1615 43457 13 282624 511 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723217] [ 1616] 111 1616 79771 46 307200 532 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723218] [ 2896] 0 2896 26997 7 249856 245 0 sshd
May 30 17:57:57 ub18 kernel: [ 240.723219] [ 2908] 1000 2908 19166 0 180224 277 0 systemd
May 30 17:57:57 ub18 kernel: [ 240.723220] [ 2909] 1000 2909 48429 0 266240 593 0 (sd-pam)
May 30 17:57:57 ub18 kernel: [ 240.723221] [ 3026] 1000 3026 26997 11 245760 243 0 sshd
May 30 17:57:57 ub18 kernel: [ 240.723223] [ 3027] 1000 3027 5823 1 81920 461 0 bash
May 30 17:57:57 ub18 kernel: [ 240.723224] [ 3062] 1000 3062 2621451127 934324 93466624 504770 0 alloc
May 30 17:57:57 ub18 kernel: [ 240.723225] [ 3089] 111 3089 79921 271 319488 468 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723226] [ 3090] 111 3090 79921 331 319488 415 0 postgres
May 30 17:57:57 ub18 kernel: [ 240.723227] [ 3091] 0 3091 8646 38 98304 0 0 sshd
May 30 17:57:57 ub18 kernel: [ 240.723228] Out of memory: Kill process 3062 (alloc) score 951 or sacrifice child
May 30 17:57:57 ub18 kernel: [ 240.723268] Killed process 3062 (alloc) total-vm:10485804508kB, anon-rss:3737288kB, file-rss:8kB, shmem-rss:0kB
May 30 17:57:57 ub18 kernel: [ 240.916591] oom_reaper: reaped process 3062 (alloc), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
$
Related
So I have been trying to get the sys call table by brute forcing and the module keeps bringing up an error at a certain address "ffffffff81000018". The following is the code I have used:
#include<linux/kernel.h>
#include<linux/module.h>
#include<linux/dirent.h>
#include<linux/syscalls.h>
#include<linux/sysfs.h>
#include<linux/list.h>
#include<linux/proc_fs.h>
#include<linux/string.h>
#include<linux/uaccess.h>
#include<linux/fs.h>
#include<linux/unistd.h>
#include<linux/cred.h>
#if defined __x86_64__
#define START_ADDRESS 0xffffffff81000000
#define END_ADDRESS 0xffffffffa2000000
#endif
MODULE_LICENSE("GPL");
void **syscall_table;
void **find_syscall_table(void)
{
void **sctable;
void *i = (void *) START_ADDRESS;
while ( i < (void *) END_ADDRESS )
{
sctable = (void *)i;
if (sctable[__NR_close] == (void *)sys_close)
{
return sctable;
}
i += sizeof(void *);
}
return NULL;
}
int init_module(void)
{
syscall_table = (void *)find_syscall_table();
if (syscall_table != NULL)
pr_info("Found sys_call_table at %p\n", syscall_table);
return 0;
}
void cleanup_module(void)
{
pr_info("Good bye kernel!!!!");
return;
}
and the problem am get is the following
[ 1376.153652] BUG: unable to handle kernel paging request at ffffffff81000018
[ 1376.153660] IP: init_module+0x1b/0x50 [hide_file]
[ 1376.153662] PGD 1bc0e067 P4D 1bc0e067 PUD 1bc0f063 PMD 0
[ 1376.153666] Oops: 0000 [#1] SMP PTI
[ 1376.153668] Modules linked in: hide_file(O+) fuse bnep pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) binfmt_misc nls_ascii nls_cp437 vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core snd_soc_skl videodev snd_hda_codec_hdmi media intel_rapl snd_soc_skl_ipc snd_hda_ext_core x86_pkg_temp_thermal btusb intel_powerclamp snd_soc_sst_dsp coretemp snd_soc_sst_ipc btrtl btbcm snd_soc_acpi btintel snd_hda_codec_realtek snd_hda_codec_generic snd_soc_core bluetooth snd_compress kvm drbg ansi_cprng snd_hda_intel ecdh_generic i915 irqbypass snd_hda_codec snd_hda_core arc4 wmi_bmof rtsx_pci_ms intel_cstate snd_hwdep iwlmvm snd_pcm mac80211 iwlwifi intel_uncore thinkpad_acpi drm_kms_helper mei_me snd_timer memstick nvram cfg80211 efi_pstore intel_rapl_perf snd evdev
[ 1376.153706] efivars sg drm soundcore mei joydev pcspkr serio_raw rfkill wmi shpchp intel_pch_thermal iTCO_wdt iTCO_vendor_support battery ac video i2c_algo_bit button tpm_crb efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb hid_generic usbhid hid sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc rtsx_pci_sdmmc mmc_core aesni_intel aes_x86_64 crypto_simd glue_helper cryptd rtsx_pci ahci mfd_core e1000e libahci xhci_pci ptp psmouse pps_core libata xhci_hcd i2c_i801 scsi_mod usbcore usb_common thermal
[ 1376.153737] CPU: 0 PID: 2244 Comm: insmod Tainted: G O 4.15.0-kali2-amd64 #1 Debian 4.15.11-1kali1
[ 1376.153742] RIP: 0010:init_module+0x1b/0x50 [hide_file]
[ 1376.153743] RSP: 0018:ffffc0adc85cfcc8 EFLAGS: 00010246
[ 1376.153745] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 1376.153747] RDX: 000000000004e55a RSI: ffffffff81000000 RDI: ffffffffc0eea030
[ 1376.153749] RBP: ffffffffc0eea030 R08: ffff9965a2424b60 R09: ffffffffbcb0b288
[ 1376.153750] R10: ffffea3746bc08c0 R11: 0000000000000000 R12: ffff9965521f7a60
[ 1376.153752] R13: ffffffffc0eec018 R14: 0000000000000001 R15: ffff9964ff2474e0
[ 1376.153754] FS: 00007f2e082e8b80(0000) GS:ffff9965a2400000(0000) knlGS:0000000000000000
[ 1376.153755] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1376.153757] CR2: ffffffff81000018 CR3: 0000000154c84002 CR4: 00000000003606f0
[ 1376.153758] Call Trace:
[ 1376.153763] do_one_initcall+0x4e/0x18d
[ 1376.153768] ? free_unref_page_commit+0x95/0x110
[ 1376.153770] ? _cond_resched+0x15/0x40
[ 1376.153773] ? kmem_cache_alloc_trace+0x14b/0x1a0
[ 1376.153777] ? do_init_module+0x22/0x201
[ 1376.153779] do_init_module+0x5b/0x201
[ 1376.153783] load_module.constprop.54+0x2725/0x2c70
[ 1376.153786] ? vfs_read+0x113/0x130
[ 1376.153789] ? SYSC_finit_module+0xe9/0x110
[ 1376.153792] SYSC_finit_module+0xe9/0x110
[ 1376.153795] do_syscall_64+0x6e/0x130
[ 1376.153798] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 1376.153801] RIP: 0033:0x7f2e07c178f9
[ 1376.153802] RSP: 002b:00007ffd4e622498 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 1376.153804] RAX: ffffffffffffffda RBX: 00005629814157b0 RCX: 00007f2e07c178f9
[ 1376.153806] RDX: 0000000000000000 RSI: 000056297fbc9a78 RDI: 0000000000000003
[ 1376.153807] RBP: 000056297fbc9a78 R08: 0000000000000000 R09: 00007f2e07edd000
[ 1376.153809] R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000
[ 1376.153810] R13: 0000562981415760 R14: 0000000000000000 R15: 0000000000000000
[ 1376.153812] Code: c2 bc 75 ea f3 c3 31 c0 c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 48 c7 c6 00 00 00 81 eb 0d 48 83 c6 08 48 81 fe 00 00 00 a2 74 19 <48> 81 7e 18 d0 c5 c2 bc 75 e9 48 85 f6 48 89 35 e1 22 00 00 75
[ 1376.153844] RIP: init_module+0x1b/0x50 [hide_file] RSP: ffffc0adc85cfcc8
[ 1376.153845] CR2: ffffffff81000018
[ 1376.153847] ---[ end trace ec4600bb069abdd2 ]---
Could anyone please guide me on how to solve this problem so as to be able to hijack sys calls.
Thanks.
Just use the kernel function kallsyms_lookup_name("sys_call_table") in "linux/kallsyms.h". That will return the address of the system call table as found in the /proc/kallsyms file. Don't worry if the address found in
/boot/System.map-`uname -r`
is different; you still found the sys_call_table.
This is not a "certain address". close syscall number is 3, thus the very first address you are testing is START_ADDRESS + 3 * sizeof(void *) and it equals precisely to the faulting address.
This then suggests that the params you used here are wrong to begin with.
The real question is why are you looking for a system call table, let alone in this manner. In vast majority of cases you don't want to overwrite any syscall entries.
During the way to learn how to program the Keyboard interrupt handling in Kernel mode, and following the example below, I get such an error after loading the driver in kernel space.
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/workqueue.h>
#include <linux/interrupt.h>
#include <asm/io.h>
MODULE_LICENSE("GPL");
irqreturn_t irq_handler(int irq, void *dev_id, struct pt_regs *regs) {
static unsigned char scancode, status;
status = inb(0x64);
scancode = inb(0x60);
switch (scancode)
{
case 0x01: printk (KERN_INFO "! You pressed Esc ...\n");
break;
case 0x3B: printk (KERN_INFO "! You pressed F1 ...\n");
break;
case 0x3C: printk (KERN_INFO "! You pressed F2 ...\n");
break;
default: break;
}
return IRQ_HANDLED;
}
static int __init irq_ex_init(void) {
printk (KERN_INFO "DEVICE OPEN...\n");
free_irq(1,NULL);
return request_irq (1,(irq_handler_t)irq_handler,IRQF_SHARED,"test_keyboard_irq_handler",(void*)(irq_handler));
}
static void __exit irq_ex_exit(void) {
printk (KERN_INFO "!DEVICE CLOSE...\n");
free_irq(1,(void*)(irq_handler));
}
module_init(irq_ex_init);
module_exit(irq_ex_exit);
The unloading also work fine, but after loading by insmod, I get such an error. I was wondering if somebody can explain it.
I use Ubuntu 16.04.2 LTS.
Dec 5 12:02:01 iman kernel: [ 502.506500] ------------[ cut here ]------------
Dec 5 12:02:01 iman kernel: [ 502.506510] WARNING: CPU: 1 PID: 4240 at /build/linux-hwe-zOpU13/linux-hwe-4.10.0/kernel/irq/manage.c:1484 __free_irq+0xa4/0x290
Dec 5 12:02:01 iman kernel: [ 502.506511] Trying to free already-free IRQ 1
Dec 5 12:02:01 iman kernel: [ 502.506512] Modules linked in: DDriver(OE+) Driver(OE) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat libcrc32c nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables snd_hda_codec_hdmi eeepc_wmi asus_wmi sparse_keymap intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel cryptd intel_cstate intel_rapl_perf joydev input_leds snd_seq_midi snd_seq_midi_event snd_hda_codec_realtek snd_hda_codec_generic snd_rawmidi snd_hda_intel snd_hda_codec lpc_ich snd_seq snd_hda_core snd_hwdep snd_seq_device snd_pcm snd_timer snd soundcore mei_me shpchp mei mac_hid kvm binfmt_misc
Dec 5 12:02:01 iman kernel: [ 502.506560] irqbypass parport_pc ppdev lp parport autofs4 hid_cherry hid_generic usbhid hid nouveau mxm_wmi i2c_algo_bit ttm drm_kms_helper ahci syscopyarea libahci sysfillrect r8169 sysimgblt mii fb_sys_fops drm wmi fjes video [last unloaded: DDriver]
Dec 5 12:02:01 iman kernel: [ 502.506584] CPU: 1 PID: 4240 Comm: insmod Tainted: G W OE 4.10.0-40-generic #44~16.04.1-Ubuntu
Dec 5 12:02:01 iman kernel: [ 502.506585] Hardware name: ASUSTeK Computer INC. V-P8H67E/V-P8H67E, BIOS 1401 12/12/2011
Dec 5 12:02:01 iman kernel: [ 502.506586] Call Trace:
Dec 5 12:02:01 iman kernel: [ 502.506593] dump_stack+0x63/0x90
Dec 5 12:02:01 iman kernel: [ 502.506596] __warn+0xcb/0xf0
Dec 5 12:02:01 iman kernel: [ 502.506598] warn_slowpath_fmt+0x5f/0x80
Dec 5 12:02:01 iman kernel: [ 502.506602] __free_irq+0xa4/0x290
Dec 5 12:02:01 iman kernel: [ 502.506604] free_irq+0x39/0x90
Dec 5 12:02:01 iman kernel: [ 502.506607] ? 0xffffffffc0183000
Dec 5 12:02:01 iman kernel: [ 502.506611] irq_ex_init+0x26/0x1000 [DDriver]
Dec 5 12:02:01 iman kernel: [ 502.506614] do_one_initcall+0x53/0x1c0
Dec 5 12:02:01 iman kernel: [ 502.506619] ? kmem_cache_alloc_trace+0x152/0x1c0
Dec 5 12:02:01 iman kernel: [ 502.506624] do_init_module+0x5f/0x1ff
Dec 5 12:02:01 iman kernel: [ 502.506629] load_module+0x1825/0x1bf0
Dec 5 12:02:01 iman kernel: [ 502.506632] ? __symbol_put+0x60/0x60
Dec 5 12:02:01 iman kernel: [ 502.506636] ? ima_post_read_file+0x7d/0xa0
Dec 5 12:02:01 iman kernel: [ 502.506640] ? security_kernel_post_read_file+0x6b/0x80
Dec 5 12:02:01 iman kernel: [ 502.506644] SYSC_finit_module+0xdf/0x110
Dec 5 12:02:01 iman kernel: [ 502.506648] SyS_finit_module+0xe/0x10
Dec 5 12:02:01 iman kernel: [ 502.506652] entry_SYSCALL_64_fastpath+0x1e/0xad
Dec 5 12:02:01 iman kernel: [ 502.506655] RIP: 0033:0x7f0f6a2a3499
Dec 5 12:02:01 iman kernel: [ 502.506656] RSP: 002b:00007fff1b8c96f8 EFLAGS: 00000202 ORIG_RAX: 0000000000000139
Dec 5 12:02:01 iman kernel: [ 502.506659] RAX: ffffffffffffffda RBX: 00007f0f6a566b20 RCX: 00007f0f6a2a3499
Dec 5 12:02:01 iman kernel: [ 502.506661] RDX: 0000000000000000 RSI: 000055649bd65246 RDI: 0000000000000003
Dec 5 12:02:01 iman kernel: [ 502.506663] RBP: 0000000000001011 R08: 0000000000000000 R09: 00007f0f6a568ea0
Dec 5 12:02:01 iman kernel: [ 502.506664] R10: 0000000000000003 R11: 0000000000000202 R12: 00007f0f6a566b78
Dec 5 12:02:01 iman kernel: [ 502.506665] R13: 00007f0f6a566b78 R14: 000000000000270f R15: 00007f0f6a5671a8
Dec 5 12:02:01 iman kernel: [ 502.506668] ---[ end trace 4b89a13407b08cea ]---
free_irq() should never be called with NULL, you should pass the unique handler that you have used during registering the IRQ.
free_irq(1,(void*)(irq_handler)); //In your case
You should not free the IRQ in init function, free_irq() should be called after register_irq() call has been made in the same module.
Even if you call free_irq(1,(void*)(irq_handler)); in init function the kernel will taint as the handler was not previously registered.
You need to let the kernel know which handler you want to remove.
As you don't know which module has already registered the same IRQ so the logic is to use a shared IRQ in your module which you have already implemented in your code.
In short, do not free the IRQ in init function.
I have an array of ranges in Perl and need a way to loop through each range in the array, search a number and print the min..max indexes for each range. I am able to do this in bash shell scripting but having some trouble in Perl.
My code:
#!/usr/bin/perl
use List::Util qw(max min);
$search_num = 95;
#ranges = (73..80, 92..107, 941..1000, 3000..3170);
foreach $num (#ranges) {
$range_min = min(#ranges);
$range_max = max(#ranges);
if ($search_num == $n) {
print "$search was found in range $range_min..$range_max\n";
}
}
Desired output:
95 was found in range 92..107
The following works fine for indicating per hard coded range
but need a way to have a series of ranges in an array to loop, search and display where found. The following works:
#range = (92..107);
foreach $num (#range) {
$range_min = min(#range);
$range_max = max(#range);
if ($search_num == $num){
print "$search_num was found in range $range_min..$range_max\n";
}
}
Output:
95 was found in range 92..107
thanks for any advice.
#ranges=(73..80, 92..107, 941..1000, 3000..3170);
You seem to be under the impression that this will put separate range objects in #ranges. Instead, #range contains the following flat list:
$ perl -E '#ranges=(73..80, 92..107, 941..1000, 3000..3170); say "#ranges"'
73 74 75 76 77 78 79 80 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170
You can insert references to anonymous arrays in #ranges:
#ranges = ([73..80], [92..107], [941..1000], [3000..3170]);
However, since you already know the upper and lower limits of each range, why are you wasting memory?
#ranges=([73, 80], [92, 107], [941, 1000], [3000, 3170]);
Here is one way to implement that:
#!/usr/bin/env perl
use strict;
use warnings;
my #ranges=([73, 80], [92, 107], [941, 1000], [3000, 3170]);
my $search = 95;
my $found = search_in_ranges($search, \#ranges);
for my $r ( #$found ) {
printf "%d was found in [%d, %d]\n", $search, $r->[0], $r->[1];
}
sub search_in_ranges {
my ($n, $ranges) = #_;
return [ grep $n >= $_->[0] && $n <= $_->[1], #$ranges ];
}
See also perldoc perlreftut which is installed along with your Perl distribution.
I am trying to create a kernel module which needs to find whether a specific USB device is attached or not namely a USB Keyboard and whether It has DMA access or not.
To achieve this I am traversing through all the URB structures (linux/usb.h) present in the RAM. When I find a struct that is not null, I am trying to access the device information via struct usb_device *dev pointer declared inside URB structure.
However access to any information inside the *dev results in an OOPS condition with the bug stating Unable to handle kernel paging request at ffffe00121160800. The address remains constant every time.
The following is just a snippet of my whole kernel module.
#define x(y) ((void *)((uint32_t)(y)+PAGE_OFFSET))
static int __init check(void)
{
unsigned long long i;
for(i = 0; i < ULLONG_MAX; i += 0x10)
{ struct urb *urbptr = (struct urb *)x(i);
if((((unsigned long)urbptr->dev) % 0x400) == 0)
{
if ((((unsigned long)urbptr->transfer_dma) % 0x20) == 0)
{
if (urbptr->transfer_buffer_length ==8)
{
if (urbptr->transfer_buffer_length ==8)
{
if (urbptr->transfer_buffer !=NULL)
{
if(urbptr->dev !=NULL)
{
printk("\n%s\n",urbptr->dev->product);
}
}
}
}
}
}
}
The error occurs each time I try to access any value of a usb_device structure (not just char * product). After a lot of debugging I was able to identify that the error occurs only at the printk statement i.e the *dev is not null, the pagefault occurs only when I am trying to access its data members.
Source of struct usb_device
Source of struct urb
Here is the dmesg output:
[ 93.925232] BUG: unable to handle kernel paging request at ffffe00121160800
[ 93.925287] IP: [<ffffffffc01320f0>] check+0xf0/0x1000 [check]
[ 93.925334] PGD 0
[ 93.925350] Oops: 0000 [#1] SMP
[ 93.925375] Modules linked in: check(POE+) ctr ccm nvram msr pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) bnep rfcomm binfmt_misc nls_iso8859_1 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media rtsx_usb_ms memstick btusb bluetooth 6lowpan_iphc fglrx(POE) ip6t_REJECT xt_hl ip6t_rt nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT xt_LOG xt_limit xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables wl(POE) arc4 iwldvm mac80211 dell_wmi sparse_keymap dell_laptop dcdbas snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_controller snd_hda_codec crct10dif_pclmul crc32_pclmul snd_hwdep ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul snd_pcm glue_helper ablk_helper cryptd snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq joydev serio_raw iwlwifi cfg80211 snd_seq_device snd_timer snd lpc_ich soundcore mei_me mei amd_iommu_v2 mac_hid shpchp parport_pc ppdev lp parport rtsx_usb_sdmmc rtsx_usb i915 psmouse ahci libahci i2c_algo_bit drm_kms_helper drm r8169 mii wmi video
[ 93.926369] CPU: 3 PID: 3410 Comm: modprobe Tainted: P OE 3.16.0-41-generic #57~14.04.1-Ubuntu
[ 93.926439] task: ffff88008b7fd180 ti: ffff880221114000 task.ti: ffff880221114000
[ 93.926448] RIP: 0010:[<ffffffffc01320f0>] [<ffffffffc01320f0>] scan_start+0xf0/0x1000 [check]
[ 93.926449] RSP: 0018:ffff880221117d28 EFLAGS: 00010282
[ 93.926450] RAX: 0000000000000005 RBX: 0000000000207f40 RCX: 0000000000004c00
[ 93.926451] RDX: 000000000000e76a RSI: 0000000000000046 RDI: 0000000000000246
[ 93.926453] RBP: ffff880221117d40 R08: 0000000000000092 R09: 0000000000061bd7
[ 93.926454] R10: 0000000000000000 R11: ffff880221117ac6 R12: ffffe00121160800
[ 93.926455] R13: ffff880000000000 R14: ffffffffc0132000 R15: ffffffffc1c42000
[ 93.926457] FS: 00007f3eb6c9e740(0000) GS:ffff88025f2c0000(0000) knlGS:0000000000000000
[ 93.926459] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.926460] CR2: ffffe00121160800 CR3: 00000002210c3000 CR4: 00000000001407e0
[ 93.926461] Stack:
[ 93.926464] ffffffff81c1a020 ffff8802371db940 0000000000000000 ffff880221117db8
[ 93.926466] ffffffff81002144 0000000000000001 0000000000000001 0000000000000002
[ 93.926468] ffff8802502e4140 0000000000000001 ffff880221117da0 ffffffff8119d672
[ 93.926469] Call Trace:
[ 93.926479] [<ffffffff81002144>] do_one_initcall+0xd4/0x210
[ 93.926488] [<ffffffff8119d672>] ? __vunmap+0xb2/0x100
[ 93.926498] [<ffffffff810edc91>] load_module+0x13c1/0x1b80
[ 93.926505] [<ffffffff810e9840>] ? store_uevent+0x40/0x40
[ 93.926510] [<ffffffff810ee5c6>] SyS_finit_module+0x86/0xb0
[ 93.926519] [<ffffffff8176de4d>] system_call_fastpath+0x1a/0x1f
[ 93.926631] Code: 24 68 00 74 38 31 c0 48 c7 c7 4b 10 c4 c1 e8 b2 c5 62 c1 4d 8b 64 24 48 4d 85 e4 74 20 48 c7 c7 50 10 c4 c1 31 c0 e8 9a c5 62 c1 <41> 8b 34 24 48 c7 c7 56 10 c4 c1 31 c0 e8 88 c5 62 c1 48 c7 c7
[ 93.926636] RIP [<ffffffffc01320f0>] check+0xf0/0x1000 [check]
[ 93.926639] RSP <ffff880221117d28>
[ 93.926641] CR2: ffffe00121160800
[ 93.940769] ---[ end trace f2349a61d7dd6264 ]---
Is there any reason for the kernel not being able to access this particular structure? Even if that kernel space is write protected I am only trying to read it. commands like lsusb access the same struct while in userspace so I believe there should be no reason that this kernel is over stepping its bounds.
I'm experiencing some very odd behavior with the code segment pointed to by task->mm and I hope someone out there can help me out. What I'm doing is pulling the code segment out and putting it in a buffer and then generating an HMAC from it. Occasionally I'll get an Ooops! saying that the can't with the call stack terminating at memcpy(). What appears to be happening is that the data goes away in the middle of the copy process and it causes a page fault and then the Ooops. I've searched far and wide for references to this seemingly ephemeral nature of the memory used in mm_struct, but have found nothing. I don't believe I'm doing anything controversial in the code; here it is with comments etc removed for brevity.
struct mm_struct* __mm;
...
__mm = get_task_mm(__task);
if(likely(__mm))
{
__buflen = (__mm->end_code - __mm->start_code);
if(likely(__buflen > 0))
{
__buf = (unsigned char*)__get_buffer(__buflen);
if(likely(__buf))
{
preempt_disable();
memcpy(__buf, (uint8_t*)__mm->start_code, __buflen);
preempt_enable();
mmput(__mm);
if(unlikely(!__do_ntru_hmac(__buf, __buflen, __hmac)))
{
__retcode = 0;
}
__release_buffer(__buf, __buflen);
}
else
{
printk(KERN_ERR "[%s] Buffer allocation failure [%d]\n", __task->comm, __buflen);
__retcode = 0;
}
...
The memory allocation routines are simple and aimed at being able to allocate large blocks of memory at once. They look like this:
void* __get_buffer(unsigned long __buflen)
{
if(likely(__buflen <= KMALLOC_MAX_SIZE))
{
return kmalloc(__buflen, GFP_KERNEL);
}
else
{
return (void*)__get_free_pages(GFP_KERNEL, get_order(__buflen));
}
return NULL;
}
void __release_buffer(void* __buffer, unsigned long __buflen)
{
if(likely(__buflen <= KMALLOC_MAX_SIZE))
{
kfree(__buffer);
}
else
{
free_pages((unsigned long)__buffer, get_order(__buflen));
}
return;
}
The error seems to occur randomly and I can't tie it to a task, parent or any other components of struct task_struct. I've tried mutexes and spinlocks to protect the memory during memcpy, I've tried stopping the task altogether using set_task_state() and restarting it after the copy, but nothing seems to stop the problem.
UPDATE: I'm still hammering away at this problem and though I'd toss in some more data. Here's the Oops dump.
Mar 16 09:39:27 ubuntu kernel: [ 324.229195] BUG: unable to handle kernel paging request at 0804b000
Mar 16 09:39:27 ubuntu kernel: [ 324.229199] IP: [<c1312dfd>] memcpy+0x1d/0x40
Mar 16 09:39:27 ubuntu kernel: [ 324.229221] *pdpt = 000000002cf4c001 *pde = 000000003b72c067
Mar 16 09:39:27 ubuntu kernel: [ 324.229223] Oops: 0000 [#1] SMP
Mar 16 09:39:27 ubuntu kernel: [ 324.229225] Modules linked in: aerolock(OF) vmhgfs(OF) vmw_balloon psmouse snd_ens1371 serio_raw gameport snd_ac97_codec ac97_bus snd_pcm snd_seq_midi btusb snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device vmwgfx snd ttm drm bnep rfcomm soundcore mac_hid bluetooth snd_page_alloc vmw_vmci i2c_piix4 parport_pc ppdev shpchp lp parport hid_generic usbhid hid pcnet32 mptspi ahci libahci mptscsih mptbase floppy mii vmw_pvscsi vmxnet3
Mar 16 09:39:27 ubuntu kernel: [ 324.229256] CPU: 0 PID: 2880 Comm: aerolockd Tainted: GF O 3.11.0-17-generic #31~precise1-Ubuntu
Mar 16 09:39:27 ubuntu kernel: [ 324.229258] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
Mar 16 09:39:27 ubuntu kernel: [ 324.229259] task: f1816700 ti: ed774000 task.ti: ed774000
Mar 16 09:39:27 ubuntu kernel: [ 324.229262] EIP: 0060:[<c1312dfd>] EFLAGS: 00010202 CPU: 0
Mar 16 09:39:27 ubuntu kernel: [ 324.229264] EIP is at memcpy+0x1d/0x40
Mar 16 09:39:27 ubuntu kernel: [ 324.229266] EAX: ecc80000 EBX: 00011cd0 ECX: 00003b34 EDX: 08048000
Mar 16 09:39:27 ubuntu kernel: [ 324.229268] ESI: 0804b000 EDI: ecc83000 EBP: ed775e74 ESP: ed775e68
Mar 16 09:39:27 ubuntu kernel: [ 324.229269] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Mar 16 09:39:27 ubuntu kernel: [ 324.229271] CR0: 80050033 CR2: 0804b000 CR3: 2d9d5000 CR4: 001407f0
Mar 16 09:39:27 ubuntu kernel: [ 324.229345] Stack:
Mar 16 09:39:27 ubuntu kernel: [ 324.229347] 00011cd0 f1816700 f33703b4 ed775eb0 f9ba3a1b 0000063b 00000000 00000000
Mar 16 09:39:27 ubuntu kernel: [ 324.229353] 0000063c c1b80e4c f1816700 ed775ee0 08048000 ecc80000 00000000 f1816700
Mar 16 09:39:27 ubuntu kernel: [ 324.229358] f9baa952 f1816700 ed775f08 f9ba3b6e 00000000 00000000 00000000 c1b9d642
Mar 16 09:39:27 ubuntu kernel: [ 324.229364] Call Trace:
Mar 16 09:39:27 ubuntu kernel: [ 324.229370] [<f9ba3a1b>] __generate_hmac+0x8b/0x190 [aerolock]
Mar 16 09:39:27 ubuntu kernel: [ 324.229373] [<f9ba3b6e>] __validate_hmac+0x4e/0x220 [aerolock]
Mar 16 09:39:27 ubuntu kernel: [ 324.229377] [<f9ba3da0>] ret_do_fork+0x60/0x70 [aerolock]
Mar 16 09:39:27 ubuntu kernel: [ 324.229384] [<c167f12a>] trampoline_handler+0x11a/0x1c0
Mar 16 09:39:27 ubuntu kernel: [ 324.229390] [<c10839a4>] ? wake_up_new_task+0xe4/0x150
Mar 16 09:39:27 ubuntu kernel: [ 324.229394] [<c1054bf5>] ? SyS_clone+0x25/0x30
Mar 16 09:39:27 ubuntu kernel: [ 324.229397] [<c1054bf5>] ? SyS_clone+0x25/0x30
Mar 16 09:39:27 ubuntu kernel: [ 324.229400] [<c167efee>] kretprobe_trampoline+0x16/0x38
Mar 16 09:39:27 ubuntu kernel: [ 324.229404] [<c167efd8>] ? kretprobe_trampoline_holder+0x8/0x8
Mar 16 09:39:27 ubuntu kernel: [ 324.229406] [<c167c937>] syscall_call+0x7/0xb
Mar 16 09:39:27 ubuntu kernel: [ 324.229408] Code: c3 90 8d 74 26 00 e8 33 fe ff ff eb e8 90 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 cb 89 c7 c1 e9 02 89 d6 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 8b 5d f4 8b 75 f8 8b 7d fc 89
Mar 16 09:39:27 ubuntu kernel: [ 324.229439] EIP: [<c1312dfd>] memcpy+0x1d/0x40 SS:ESP 0068:ed775e68
Mar 16 09:39:27 ubuntu kernel: [ 324.229444] CR2: 000000000804b000
Mar 16 09:39:27 ubuntu kernel: [ 324.229447] ---[ end trace 3c014cb0223fa59a ]---
I've tried a lot of different tacks but have met with failure on all. copy_from_user() for example fails every time; sometimes not reading the whole request and sometimes returning a partial. Every time it fails on a partial it does so on a page boundary--again making it seem like the memory is being taken away mid-copy.
Given that I'm hooking do_fork(), could the process just be transitioning from kernel space to user space while I'm trying to capture it? As I mentioned before, I've tried stopping the current task and restarting post copy, but it has no effect.
Also interesting to note; I've had the same (memcpy()) code running for six weeks straight under varying loads without a failure on a single processor ARM BeagleBoard Black running Ubuntu 12.04 (3.8.13-bone28). The problem only seems to happen on my x86 box running Ubuntu 12.04 and then only when I put a heavy load on it like starting Chromium.
Sorry to be so long winded here, I'm stumped.
Any ideas?
Thanks again in advance,
Pete
You can't reliably copy memory directly from userspace, as you've discovered.
Use copy_from_user() instead of memcpy(). And don't disable preemption, there's no point.