I am trying to add a new system call that returns the total number of system calls made so far. I can find the count of system calls by writing the below command in terminal.
cat /proc/kallsyms |grep _x64_sys |grep -v _eil* |wc -l
But I don't know how to implement this command in my new system call's C code. Any help is appreciated.
Related
I build OpenSSL-1.0.2n with -g 386 shared --prefix=/usr option (to work with basic assembly version) to generate shared library libcrypto.so.1.0.0.
Inside crypto/aes folder, aes-x86_64.s is generated.
To perform AES encryption and decryption I used following commands in linux terminal.
/usr/bin/openssl enc -aes-128-cbc -in secrets.txt -out cipher.bin
/usr/bin/openssl enc -d -aes-128-cbc -in cipher.bin -out decrypt_cip2.txt
Using GDB, I am able to debug the execution of above command as follow
gdb openssl
gdb> set args enc -d -aes-128-cbc -in cipher.bin -out decrypt_cip2.txt
gdb> b AES_cbc_encrypt
gdb> run
Breakpoint 1, AES_cbc_encrypt () at aes-x86_64.s:1300
1300 cmpq $0,%rdx
From the above output of gdb debugging, it is verified that AES_cbc_encrypt function of aes-x86_64.s file is called.
I need to verify, if I use a C program where system call is used to execute bash script to perform AES decryption, will the AES_cbc_encrypt function of aes-x86_64.s file still called ?
//test.c
#include <stdio.h>
#include <stdlib.h>
int main()
{
char cmd[500];
sprintf(cmd, "/usr/bin/openssl enc -d -aes-128-cbc -in cipher.bin -out decrypt_cip2.txt ");
system(cmd);
return 0;
}
gcc test.c -o test
./test
Will I be wrong, if I say when I execute this C program, it indirectly call openssl library (libcrypto.so) and perform decryption. So it must call AES_cbc_encrypt function of aes-x86_64.o file.
However, when I use GDB to debug this program it is not showing any call to AES_cbc_encrypt function of aes-x86_64.o file. It simply make some calls to /sysdeps/posix/system.c, /sysdeps/unix/sysv/linux/x86_64/sigaction.c etc.
gdb test
gdb> b AES_cbc_encrypt
Function "AES_cbc_encrypt" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (AES_cbc_encrypt) pending.
So, Here is my questions
how to debug the above C code using gdb so that it will stop at breakpoint AES_cbc_encrypt of installed OpenSSL?
Should I use other than system call in C program to run those bash command which will ensure indirectly calling AES_cbc_encrypt function of aes-x86_64.s file?
Any help or link to solve this will be greatly appreciable.
I am using Ubuntu 16.04 , gcc-7.0 with debugging symbol on in OpenSSL version-1.0.2n.
However, when I use GDB to debug this program it is not showing any call to AES_cbc_encrypt function of aes-x86_64.o file. It simply make some calls to /sysdeps/posix/system.c
By default GDB will only debug one process (the test program) and that process isn't calling AES_cbc_encrypt -- rather it creates a new process -- $SHELL, which in turn creates another process -- /usr/bin/openssl, and only that grandchild process calls AES_cbc_encrypt.
Since you are debugging the grandparent of openssl, it is entirely expected that GDB does not observe AES_cbc_encrypt being linked into the process you are debugging, and that the breakpoint on AES_cbc_encrypt is never established, nor ever "fires".
how to debug the above C code using gdb so that it will stop at breakpoint AES_cbc_encrypt of installed OpenSSL?
There are a few ways:
One way is to modify test such that it invokes gdb instead of invoking openssl:
sprintf(cmd, "gdb --args /usr/bin/openssl enc -d -aes-128-cbc -in cipher.bin -out decrypt_cip2.txt");
system(cmd);
If you can't or don't want to modify the test program, you could rename /usr/bin/openssh to /usr/bin/openssl.exe and place a shell wrapper into /usr/bin/openssl:
#!/bin/sh
exec gdb --args /usr/bin/openssl.exe "$#"
If you don't want to do either of above, you could use GDB multiple inferior support. Documentation here and here.
Update:
I am little bit wondering how it will execute ..exe file
UNIX systems don't care about file extensions (they look inside the file, i.e. at the file contents, to figure out how to run it).
Thus you can rename an executable file to anything you want: openssl.foo, openssl.bar, openssl.exe, openssl.orig, etc. and it will still run correctly.
I ran dtruss on vmmap that is a process that read the virtual memory of another remote process.
I would expect that some of mach_port system calls would appear in the output of my command, but couldn't trace any (i.e. mach_vm_read, task_for_pid, etc ..)
The exact command i ran (notice that dtruss is a wrapper script of dtrace in OS-X) :
sudo dtruss vmmap <pid_of_sample_process>
The input argument for vmmap is just a pid of any running process, and the OS version i use is 10.10 (in 10.11 there's entitlement issue when running dtruss on apple products such as vmmap).
Perhaps someone can tell me how to identify the system call i'm looking for... Should I look for the explicit name in dtruss output, or just a general call number of my desired syscall (sadly, i haven't found any of them) :
./bsd/kern/trace.codes:0xff004b10 MSG_mach_vm_read
It looks to me like it's not using Mach APIs. It's using the libproc interface. I'm seeing many proc_info() syscalls, which is what's behind library calls like proc_pidinfo().
I used:
sudo dtrace -n 'pid$target::proc_*:entry {}' -c 'vmmap <some PID>'
to trace the various libproc functions being called. I see calls to proc_name(), proc_pidpath(), and proc_pidinfo() to get information about the target process and then calls to proc_regionfilename() to get information about the VM regions.
By the way, vmmap doesn't read the memory of the other process, it just reports information about the VM regions, not their contents. So, I wouldn't expect to see mach_vm_read() or the like.
I want to build a dedicated Linux system that only ever runs one binary program. This program takes control of the screen via the OpenGL driver and displays patterns. There needs to be keyboard input as well to configure the patterns. Since running this one program will be the sole purpose of the machine, I don't need any GUI, networking, etc. Also, I probably don't need any process scheduling in the kernel since only one process will ever run.
Is it possible to replace /sbin/init with my own binary to achieve this? After the kernel loads, it would then immediately execute my own binary, and that would run the entire time the machine was on. Basically, I want to emulate the way a microcontroller works, but with the benefit of being able to use an x86 CPU with different hardware devices and drivers.
Minimal init hello world program step-by-step
Compile a hello world without any dependencies that ends in an infinite loop. init.S:
.global _start
_start:
mov $1, %rax
mov $1, %rdi
mov $message, %rsi
mov $message_len, %rdx
syscall
jmp .
message: .ascii "FOOBAR FOOBAR FOOBAR FOOBAR FOOBAR FOOBAR FOOBAR\n"
.equ message_len, . - message
We cannot use sys_exit, or else the kernel panics.
Then:
mkdir d
as --64 -o init.o init.S
ld -o init d/init.o
cd d
find . | cpio -o -H newc | gzip > ../rootfs.cpio.gz
ROOTFS_PATH="$(pwd)/../rootfs.cpio.gz"
This creates a filesystem with our hello world at /init, which is the first userland program that the kernel will run. We could also have added more files to d/ and they would be accessible from the /init program when the kernel runs.
Then cd into the Linux kernel tree, build is as usual, and run it in QEMU:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
git checkout v4.9
make mrproper
make defconfig
make -j"$(nproc)"
qemu-system-x86_64 -kernel arch/x86/boot/bzImage -initrd "$ROOTFS_PATH"
And you should see a line:
FOOBAR FOOBAR FOOBAR FOOBAR FOOBAR FOOBAR FOOBAR
on the emulator screen! Note that it is not the last line, so you have to look a bit further up.
You can also use C programs if you link them statically:
#include <stdio.h>
#include <unistd.h>
int main() {
printf("FOOBAR FOOBAR FOOBAR FOOBAR FOOBAR FOOBAR FOOBAR\n");
sleep(0xFFFFFFFF);
return 0;
}
with:
gcc -static init.c -o init
You can run on real hardware with a USB on /dev/sdX and:
make isoimage FDINITRD="$ROOTFS_PATH"
sudo dd if=arch/x86/boot/image.iso of=/dev/sdX
Great source on this subject: http://landley.net/writing/rootfs-howto.html It also explains how to use gen_initramfs_list.sh, which is a script from the Linux kernel source tree to help automate the process.
Next step: setup BusyBox so you can interact with the system through a shell. Buildroot is a great way to do it.
Tested on Ubuntu 16.10, QEMU 2.6.1.
It might be possible to replace /sbin/init by your program, but you should be aware that process 1 has some specific duties. So I think it is not advisable to replace it.
Remember that a Linux kernel can also start some processes magically, outside of the usual fork from a process inherited by the init process. I'm thinking of things like /sbin/modprobe or /sbin/hotplug etc.
Also, udev (or systemd) have some special roles. On some systems, fan control was related to such things (I really forgot the details). If unlucky, you could burn your hardware if fan is not working well (but AFAIK this is no more true on recent hardware).
By seeking with string the vmlinux in a recent 3.15.3 kernel, I find that it knows about:
/bin/init
/bin/sh
/sbin/request-key
/sbin/tomoyo-init
/sbin/modprobe
/sbin/poweroff
/sbin/hotplug
I would recommend instead keeping some existing init program, and configure it to run only your program.
You can put your program to initrd, and then run it from initrd's init.
Simply use a boot paramter eg) init=/bin/bash
init is the process 1, used by kernel to start user space, which as a few specific duties like reaping children periodical to clean out zombies. Sounds like you don't even need that.
Linux Boot parameters you should know
I am trying to figure out the best way to write a cross platform kernel code/shell script to list all the kernel task {(pid/tid , name)} in a linux dis. machine. it should be the most general possible. I tried to use ps -T but it is seems to be inaccurate and some platform don't support it in their busybox. Any suggestions?
If you want to distinguish user processes from kernel tasks, then this is a previous discussion on the subject: Identifying kernel threads
My answer to that question does not require any tools, it simply reads the contents of /proc//stat, so it should work on any distribution.
You could try
ps -e -o pgrp= -o pid= -o cmd= | sed -ne 's/^ *0 *// p'
although it assumes all kernel tasks belong to process group 0.
Is it possible that I can view the line number and file name (for my program running with ltrace/strace) along with the library call/system call information.
Eg:
code section :: ptr = malloc(sizeof(int)*5); (file:code.c, line:21)
ltrace or any other tool: malloc(20) :: code.c::21
I have tried all the options of ltrace/strace but cannot figure out a way to get this info.
If not possible through ltrace/strace, do we have any parallel tool option for GNU/Linux?
You may be able to use the -i option (to output the instruction pointer at the time of the call) in strace and ltrace, combined with addr2line to resolve the calls to lines of code.
No It's not possible. Why don't you use gdb for this purpose?
When you are compiling application with gcc use -ggdb flags to get debugger info into your program and then run your program with gdb or equivalent frontend (ddd or similar)
Here is quick gdb manual to help you out a bit.
http://www.cs.cmu.edu/~gilpin/tutorial/
You can use strace-plus that can collects stack traces associated with each system call.
http://code.google.com/p/strace-plus/
Pretty old question, but I found a way to accomplish what OP wanted:
First use strace with -k option, which will generate a stack trace like this:
openat(AT_FDCWD, NULL, O_RDONLY) = -1 EFAULT (Bad address)
> /usr/lib/libc-2.33.so(__open64+0x5b) [0xefeab]
> /usr/lib/libc-2.33.so(_IO_file_open+0x26) [0x816f6]
> /usr/lib/libc-2.33.so(_IO_file_fopen+0x10a) [0x818ca]
> /usr/lib/libc-2.33.so(__fopen_internal+0x7d) [0x7527d]
> /mnt/r/build/tests/main(main+0x90) [0x1330]
> /usr/lib/libc-2.33.so(__libc_start_main+0xd5) [0x27b25]
> /mnt/r/build/tests/main(_start+0x2e) [0x114e]
The address of each function call are displayed at the end of each line, and you can paste it to addr2line to retrieve the file and line. For example, we want to locate the call in main() (fifth line of the stack trace).
addr2line -e tests/main 0x1330
It will show something like this:
/mnt/r/main.c:55