a user submitted a bug-report, where my application segfaults in "__fortify_fail()".
i understand that this is related to building my application with Debian's "hardening" flags -D_FORTIFY_SOURCE=2 -fstack-protector.
unfortunately the backtrace of the user does not tell me much yet, and the user is not super responsive (right now).
in order to understand better what is going on, i would like to know, what __fortify_fail actually does.
This function is normally just an error reporter. Sample code from glibc is:
extern char **__libc_argv attribute_hidden;
void
__attribute__ ((noreturn))
__fortify_fail (msg)
const char *msg;
{
/* The loop is added only to keep gcc happy. */
while (1)
__libc_message (2, "*** %s ***: %s terminated\n",
msg, __libc_argv[0] ?: "<unknown>");
}
libc_hidden_def (__fortify_fail)
It may be called here and there where sources is preferred to be fortified. "Fortification" itself is just a couple of run-time checks. Sample usage in openat function from io/openat.c is:
int
__openat_2 (fd, file, oflag)
int fd;
const char *file;
int oflag;
{
if (oflag & O_CREAT)
__fortify_fail ("invalid openat call: O_CREAT without mode");
return __openat (fd, file, oflag);
}
Without fortification, O_CREAT is acceptable without mode (still this case is highly suspicious, it is legal).
Think about __fortify_fail like about printf+abort.
Turning telepathy on about your question, I may suggest that user have some problems with using libc in user code. /lib/x86_64-linux-gnu/libc.so.6(+0xebdf0)[0x7f75d3576df0] is a place inside libc where some runtime-check fails, so pd[0x49b5c0] is a place where libc incorrectly called from.
Related
I wrote a character device driver. Now I want to use python to read from it when there is data.
However, I found that the modules "io" as well as "os" do not block upon reading. The latter even when I set os.set_blocking(fd,true).
Is there a way to access the device in blocking mode?
Or do I miss something in the device driver (tail works fine)?
f=io.open("/dev/tstty0","r")
while (1)
data=str(f.read(32))
print("mark") # <--- endless list of marks
#do somthing
The read function of the device driver:
static ssize_t tstty_read(
struct file *filp,
char *buffer,
size_t length,
loff_t *offset)
{
unsigned char b;
unsigned long ofs=0;
devConfig* dev=filp->private_data;
if (dev)
{
while (fifoGet(&dev->tcp2dev,&b) && (ofs<length))
{
if (put_user(b,buffer+ofs))
{
printk(KERN_ERR "Could not copy user data");
return -EINVAL;
}
ofs++;
}
//printk(KERN_INFO "Reading device");
return ofs;
}
printk(KERN_ERR "Unknown device: %s",filp->f_path.dentry->d_iname);
return -EINVAL;
};
The read function reads any bytes available from a fifo. I none is available 0 is returned.
Kudos to Ian Abbott. A character device has to implement the ability to block a read request. The read file operation has to evaluate filp->f_flags & O_NONBLOCK to check if a client has requested blocking I/O.
This link helped me with an example:
simple linux driver code for blocking and non-blocking read
This example works but one has to consider two more things not covered in the example: a) What to do when you want to unload the driver while in read operation (just dont do it or wake up and abort)?
b) How to abort a client caught in blocking I/O?
Currently, i want to call execvp from kernel side.
My program is programmed to go to halt mode.
So i have tried to setup below code:
char *argv[] = { "/sbin/halt", "-f", NULL };
char * envp[] = {
"SHELL=/bin/sh",
"HOME=/",
"PATH=.:/sbin:/usr/sbin:/bin:/usr/bin",
"PWD=/",
NULL };
rc = call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
It seems that the code can execute halt command well.
But it does not meet the requirement about the electric signal.
I have checked, when i call execvp from the user space:
execvp ("halt", argv);
It worked well as expected.
I know that execvp will replace the current running programming by the new one specified in passing argument. When i use call_usermodehelper, that does not happen, i think it could be the difference.
Anyone know how can i solved this problem? How to make execvp work in driver similar to user space.
Thanks!
I am trying to write a module for nodeJS which wraps libspotify. The goal is to write a webapp that allows the remote control of a device playing music from spotify.
I have decided to go along the spshell example to ensure thread safety and write a "Spotify Service" in plain C that starts a seperate thread which calls all the API functions.
The nodeJS module then just calls a few provided functions to interact with spotify. The code for the service can be found here: http://pastebin.com/KB6uwSC8 The new thread gets started at the bottom.
Now, if i call this in a simple program like this (the fget is just to have a simple way for the login to complete). I used c++ to get as close to as node-gyp compiles the code.
#include <stdio.h>
extern "C" {
#include "objects/SpotifyService.h"
}
int main(int argc, char** argv) {
login();
char string[100];
fgets(string, 100, stdin);
fprintf(stdout, "Got: %s", string);
logout();
fgets(string, 100, stdin);
fprintf(stdout, "Got: %s", string);
return 0;
}
It works fine. I can't get this to crash.
If I use the same exact "Service" in nodeJS (meaning I just call login() and logout() and do nothing else), it crashes sometimes when logging out, like 7-8/10 times. I've tried lots of stuff, including:
Copying the compiler flags from node-gyp to my small example
fiddling with the thread attributes of the spotify thread
compiling on OSX and Debian
using libuv instead of plain pthreads
compiling my "service" to a shared library and call this from node
to no avail. It just crashes. It seems to crash less when called from within gdb, but that could be random.
A stack trace from gdb shows the following:
Thread 3 (Thread 0x7ffff65fd700 (LWP 21838)):
#0 0x00007ffff678f746 in ?? () from /usr/local/lib/libspotify.so.12
#1 0x00007ffff6702289 in ?? () from /usr/local/lib/libspotify.so.12
#2 0x00007ffff6702535 in ?? () from /usr/local/lib/libspotify.so.12
#3 0x00007ffff6703b5a in ?? () from /usr/local/lib/libspotify.so.12
#4 0x00007ffff6703c86 in ?? () from /usr/local/lib/libspotify.so.12
#5 0x00007ffff66c5c8b in ?? () from /usr/local/lib/libspotify.so.12
#6 0x00007ffff679a5b3 in sp_session_process_events () from /usr/local/lib/libspotify.so.12
#7 0x00007ffff6aa7839 in spotifyLoop (nervNicht=<value optimized out>) at ../src/SpotifyService.c:103
#8 0x00007ffff70118ca in start_thread () from /lib/libpthread.so.0
#9 0x00007ffff6d78b6d in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()
(In OSX gdb showed that the function called in libspotify is called "process_title".)
Since nothing has helped so far i just don't have any idea if i can get this to work or if it is something in libspotify that's just incompatible with nodeJS. I don't understand how node-gyp links the .o files, maybe there something goes wrong?
I found two other projects on github that try to do this, but one of them puts the spotify main loop actually in Javascript and the other one uses node 0.1.100 and libspotify 0.0.4 and hasn't been updated in 2 years. I couldn't learn anything from both of them.
OK, i've played around some more. I just ignored the logout error and continued to implement other features.
I added a new sp_playlist_container creation in the logged_in callback and apparently that helped. After that, the node module does not crash anymore (or hasn't yet).
static sp_playlistcontainer_callbacks pc_callbacks = {
.container_loaded = &rootPlaylistContainerLoaded,
};
static void rootPlaylistContainerLoaded(sp_playlistcontainer* pc, void* userdata) {
int numPlaylists = sp_playlistcontainer_num_playlists(pc);
fprintf(stdout, "Root playlist synchronized, number of Playlists: %d\n", numPlaylists);
}
static void loggedIn(sp_session* session, sp_error error) {
if(SP_ERROR_OK != error) {
fprintf(stderr, "Error logging in: %s\n", sp_error_message(error));
} else {
fprintf(stdout, "Service is logged in!\n");
}
//This is absolutely necessary here, otherwise following callbacks can crash.
sp_playlistcontainer *pc = sp_session_playlistcontainer(spotifySession);
sp_playlistcontainer_add_callbacks(pc, &pc_callbacks, NULL);
}
But the sp_playlist_container creation must be in the logged_in callback, if i called it in another function (say, "getPlaylistNames") the program crashed, too.
I'll see if it continues to work and hope this answer can help others.
What is the proper way of sending some data to a loaded and running kernel module, without using netlink and without using features that may not be in place (e.g. debugfs)?
I'd like to see a clean and safe way of doing this which should work on most kernels (or preferably all modern ones), or at best an approximation of that.
The user who wants to send data to the module is the root user, the amount of data is probably under 64 kiB and consists of a series of strings.
I've already looked into trying to read files from the module, which is not only highly frowned upon for various reasons but also hard to do.
I've looked at netlink, which socket() tells me on my kernel is not supported.
I've looked at debugfs, which is not supported either on my kernel.
Obviously I could use a different kernel but as I mentioned I'd like a proper way of doing this. If someone could show me a simple example of a module that will just do a printk() of a string sent from user space that would be great.
... a simple example of a module that will just do a printk() of a string sent from user space, printkm.c:
#include <linux/module.h>
#include <linux/proc_fs.h>
MODULE_DESCRIPTION("printk example module");
MODULE_AUTHOR("Dietmar.Schindler#manroland-web.com");
MODULE_LICENSE("GPL");
static
ssize_t write(struct file *file, const char *buf, size_t count, loff_t *pos)
{
printk("%.*s", count, buf);
return count;
}
static struct file_operations file_ops;
int init_module(void)
{
printk("init printk example module\n");
struct proc_dir_entry *entry = proc_create("printk", 0, NULL, &file_ops);
if (!entry) return -ENOENT;
file_ops.owner = THIS_MODULE,
file_ops.write = write;
return 0;
}
void cleanup_module(void)
{
remove_proc_entry("printk", NULL);
printk("exit printk example module\n");
}
Example use:
root#kw:~# insmod printkm.ko
root#kw:~# echo a string >/proc/printk
root#kw:~# dmesg|tail -1
[193634.164459] a string
I think you can use a char device. Take a look at Linux Device Driver 3th Chapter 3. With the function *copy_to_user* and *copy_from_user* you can copy data safely to and from userspace.
I am overloading "malloc" by pre-loading a library. In this custom "malloc", i am using environment variable to distinguish my program to use my custom "malloc" from the general "malloc".
The problem is that, after several "mallocs" the program gets stuck inside getenv() call. I am not able to figure out why the program is getting stuck inside it.
The code is the following:
void* PerfTrackMallocInterposition::Malloc(size_t size) {
// Malloc with statistics
pthread_mutex_lock(&fgPTMutex);
char *checkCDBEnd=NULL;
static const char* CDBEndEnv = "checkCDBEnd";
checkCDBEnd = getenv(CDBEndEnv); //program gets stuck here
if(checkCDBEnd!=NULL)
{
if(checkCDBEnd[0]=='1')
{
if(size>1024)
{
void *result = Alloc(size); //Call to custom malloc
pthread_mutex_unlock(&fgPTMutex);
return result;
}
}
}
void* result = (*fPMalloc)(size); //call to normal malloc
pthread_mutex_unlock(&fgPTMutex);
return result;
}
I also get a bus error at same position while using this library with vim editor.
Please help me.
Thank You
Are you sure the program gets stuck on the getenv() call? I would be more suspicious of the mutexes: pthread_mutex_lock(&fgPTMutex); will block if another thread holds the mutex