Re: Passing kernel space data buffer where userspace is expected.
Hi Prasad,
On Wed, Aug 6, 2008 at 6:50 PM, Prasad Joshi [EMAIL PROTECTED] wrote:
Hi All,
I want to encrypt the data before it is written to the disk and decrypt is
after it is being read from the disk. so copied the ext2 source code in my
directory.
Then modified the ext2 file_operations structure to invoke my read and write
functions instead of do_sync_read/write
const struct file_operations ext2_file_operations = {
.llseek = generic_file_llseek,
.read = my_read, /* do_sync_read */
.write = my_write, /* do_sync_write */
.aio_read = generic_file_aio_read,
.aio_write = generic_file_aio_write,
.unlocked_ioctl = ext2_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = ext2_compat_ioctl,
#endif
.mmap = generic_file_mmap,
.open = generic_file_open,
.release= ext2_release_file,
.fsync = ext2_sync_file,
.splice_read= generic_file_splice_read,
.splice_write = generic_file_splice_write,
};
For time being i used simplest encryption XOR 5
int encrypt_data(char *data, size_t len)
{
int i;
for(i=0; i len; i++)
data[i] ^= 5;
return 0;
}
int decrypt_data(char *data, size_t len)
{
int i;
for(i=0; i len; i++)
data[i] ^= 5;
return 0;
}
ssize_t my_read(struct file *filp, char __user *buf, size_t len, loff_t
*ppos)
{
size_t ret;
char *data = kmalloc(sizeof(char)*len, GFP_KERNEL);
ret = do_sync_read(filp, data, len, ppos);
decrypt_data(data, len);
copy_to_user(buf, data, len);
kfree(data);
return ret;
}
In write I am supposed to encrypt the data before it is written to the disk,
ie encrypt the data before it is passed to the do_sync_write.
But, the data is in the buf which is passed from the user process and has
the type const char *buf so I can't modify the
buf
I thought of copying data from the (userland) buf to some
variable in the kernelspace and then encrypt it and pass to do_sync_write()
This is what I did
ssize_t my_write(struct file *filp, const char __user *buf, size_t len,
loff_t *ppos)
{
size_t ret;
char *data = kmalloc(sizeof(char)*len, GFP_KERNEL);
copy_from_user(data, buf, len);
encrypt_data(data, len);
ret = do_sync_write(filp, data, len, ppos);
kfree(data);
return ret;
}
After running the code and writing data to the file using echo test
/mnt_pt/fileI am getting bad address error
Is it because do_sync_write() also expects buf pointer from the userspace?
ssize_t do_sync_write(struct file *filp, const char __user *buf, size_t len,
loff_t *ppos)
You are right. Thats exactly the reason for this.
But, the only thing do_sync_write should be concerned with whether it can
access the data pointer or not. So, if the data pointer is valid and kernel
is able to access the location why so worry about userspace pointer?
These are internl kernel functions(do_sync_read/write) and they expect
__user user space pointer. Often it has been said that __user is just
a documentation thing so that programmer is careful about copying it
to kernel space. And same is done when you pass such user space
pointer to these functions. For this case :
do_sync_read - filp-f_op-aio_read - generic_file_aio_read
- generic_segment_checks -- access_ok -- __range_not_ok
If you closing look at __range_not_ok macro, it is checking is address
is with reach of current thread's segment limit (I am not good at
reading assembly code), which is not the case in your code as it is a
kernel pointer. Hence it says bad address.
What you can do ?
ssize_t my_write(struct file *filp, const char __user *buf, size_t len,
loff_t *ppos)
{
size_t ret;
mm_segment_t oldfs;
char *data = kmalloc(sizeof(char)*len, GFP_KERNEL);
copy_from_user(data, buf, len);
encrypt_data(data, len);
oldfs = get_fs(); /* Read comments in include/asm-x86/uaccess_64.h */
set_fs (KERNEL_DS);
ret = do_sync_write(filp, data, len, ppos);
set_fs(oldfs);
kfree(data);
return ret;
}
I wonder why you got that error for just write and not read. You are
passing kernel pointer to do_sync_read also.
Hope this helps,
Sachin
Thanks and Regards,
Prasad
--
To unsubscribe from this list: send an email with
unsubscribe kernelnewbies to [EMAIL PROTECTED]
Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Location of syscall wrappers
On Feb 7, 2008 1:35 AM, Rajat Jain [EMAIL PROTECTED] wrote: Hi, If I remember correctly, there used to be syscall wrappers (_syscall3() etc) in the kernel that could be used to make system calls without any library support. I'm not able to locate them for i386. Where are they? Use syscall(SYSTEM_CALL_NUMBER, arg1, arg2, arg3); _syscall3() macro are are not supported nowadays. http://lkml.org/lkml/2007/7/5/314 Sachin Thanks, Rajat -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Upgrading datastructures between different filesystem versions
On 9/26/07, Andreas Dilger [EMAIL PROTECTED] wrote: On Sep 25, 2007 23:40 -0600, Jim Cromie wrote: kernel learner wrote: ext3 filesystem has 32-bit block address and ext4 filesystem has 48-bit block address. If a user installs ext4, how will the file system handle already existing block with 32 bit values? Why should it ? thats what ext3 is for. Bzzt. Wrong answer. The ext4 code will be able to read existing ext3 (and ext2) filesystems just fine. Otherwise there wouldn't be much of an upgrade path. Id expect ext4 drivers handling ext3 filesystems is a distant, secondary goal to getting a fast, reliable, clean 48bit filesystem working. Far from the truth. One of the main goals of ext4 is that it is a drop-in replacement for ext3. The code is mostly incremental improvements over ext3, and that IS one of the reasons that it is reliable. We didn't throw away 10 years of bug fixes in the ext2/ext3 code when adding the ext4 features. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ Is it not the case that VFS takes care of all filesystems available ? VFS will see if a particular file belongs to ext3 or ext4 and call that FS's drivers to access information ?? Correct me if I am wrong. I am a newbie! Sachin -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
file_operations
Hi all, For kernel 2.6.22.6 : I can see that tyoe of 2nd arg for read function in strucy file_operations is changed is little bit changed from 2.4 kernel. ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); For 2.4 it used to be: ssize_t (*read) (struct file *, char *, size_t, loff_t *); So what does extra __user specify here. If I have to use this function of reading file inside the kernel, then shall I pass kernel buffer to it or user space buffer ? I know that it is VERY BAD idea to read from kernel. But how are we suppposed to do it if at all. Sachin -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
Inserting module into running kernel
Hi all, I have built my kernel from source, installed and booted in it. Now I have written a small module. Can I insert this module into the runningn kernel ? Is there anything which I should take care of while compiling this module, as we have to insert it into the running kernel ? Thanks in advance, Sachin -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
Hi
Hi all, I have built my kernel from source, installed and booted in it. Now I have written a small module. Can I insert this module into the runningn kernel ? Is there anything which I should take care of while compiling this module, as we have to insert it into the running kernel ? Thanks in advance, Sachin -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
