copy_from_user problem

copy_from_user problem

[V MURAHARI]

[-- Attachment #1: Type: text/html, Size: 3645 bytes --]

Re: copy_from_user problem

[Clemens Koller]

Hi, Murahari!

> I am working on a character driver for reading and writing the registers to FPGA 
> in our system.

You didn't tell much about your system.
But checkout the examples in the book "Linux Device Drivers, 3rd Edition".
(http://lwn.net/images/pdf/LDD3/)
which is worth buying, too!

You might be missing some simple __user casts for your data
structures you want to copy...
And you might need to ioremap the memory area of your fpga or whatever
you need to access.

> epc  : 8011f774    Tainted: GF
                     ^^^^^^^^^^^
And you might end up with less support here if you use a tainted Kernel.

Greets,

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19

RE: copy_from_user problem

[T Michael Turney]

[-- Attachment #1: Type: text/plain, Size: 3324 bytes --]

Samsung Enterprise Portal mySingleMurahari,
I always start simple and work up to the harder things.  Try to access a
single
long word in the ioctl, e.g.,

int

chr1_ioctl(struct inode *ino, struct file *filp, unsigned int cmd, unsigned
long arg)

{

   int ret = 0;

  unsigned int userdata;



   switch(cmd)

   {

      case IOCTL_WIN_DEBUG_READ_CODE:

      {

        ret = get_user(userdata, (unsigned int *)arg);

        ......

         }

}

}



The two O'Reilly books, Linux Device Drivers and Understanding the Linux
Kernel are also good

references for how to use the get_user and copy_from_user macros.

Hope this helps.

Cheers,

T.mike

  -----Original Message-----
  From: linuxppc-dev-bounces@ozlabs.org
[mailto:linuxppc-dev-bounces@ozlabs.org]On Behalf Of V MURAHARI
  Sent: Wednesday, August 10, 2005 7:53 PM
  To: linuxppc-dev@ozlabs.org
  Subject: copy_from_user problem



  Hello,

  I am working on a character driver for reading and writing the registers
to FPGA in our system.

  I am using driver ioctl to read/write to these registers of FPGA. As the
function call to the ioctl is being made, the printk trace shows that the
call goes to switch->copy_from_user. As soon as the call is made to
copy_from_user, the kernel crashes

  Can someone help me with this problem?




****************************************************************************
***********************

   Unhandled kernel unaligned access in
unaligned.c::emulate_load_store_insn, line 483

  :

  $0 : 00000000 10001f00 8fbf0034 02a01021 801157a0 8fe8e000 10001f00
ffff00ff

  $8 : 8fe8ffe0 00001f00 00000000 00000003 74652053 8fe9fed8 0000000a
50434942

  $16: 10001f01 00000001 801157a0 0000000f 8fe8fee8 00000104 00000000
0000000f

  $24: 00000000 2ac0fdb0                   8fe8e000 8fe8fe38 00000001
8012010c

  Hi : 00000000

  Lo : 00000000

  epc  : 8011f774    Tainted: GF

  Status: 10001f02

  Cause : 00800014

  Process rsgbm (pid: 317, stackpage=8fe8e000)

  Stack:    802d920a 0000000a 10001f01 0000003c 10001f01 0000003c 8012010c

   80120104 caa8f356 8fe82008 8fe82000 0000000f 00000000 7fff7d00 7fff7d00

   0000c001 00000003 10012808 ffffffff caa8e548 00004000 8fe9e272 00000150

   7fff7d00 ffffffea 00000000 00000240 8fe82000 00000000 00000001 00000001

   7ebff310 00000000 0000000f 8fef24e0 00000004 7ebff3e8 00000000 0000002e

   80159c6c ...

  Call Trace:   [<8012010c>] [<80120104>] [<caa8f356>] [<caa8e548>]
[<80159c6c>]

   [<8010a5c4>] [<80271dc4>]



  Code: 8c820004  24110001  ac430000 <ac620004> ac800000  ac800004  ac800000
ac800004

    8f820004



  Unit Fault Handler !!! (INDEX=10)


****************************************************************************
**********************

  int

  chr1_ioctl(struct inode *ino, struct file *filp, unsigned int cmd,

        unsigned long arg)

  {

     int ret = 0;

     n2_debug_rw_reg *dw;



     switch(cmd)

     {

        case IOCTL_WIN_DEBUG_READ_CODE:

        {

     n2_debug_rw_reg test;

          printk("%s %d\n", current->comm, current->pid);

          printk("%lx\n", arg);

          copy_from_user(&test, (n2_debug_rw_reg*)arg,
sizeof(n2_debug_rw_reg));

          printk("%lx %lx\n", ((n2_debug_rw_reg*)arg)->data,
((n2_debug_rw_reg*)arg)->

  addr);

           }

  }

  }



  Thanks & Regards,

  --Murahari

[-- Attachment #2: Type: text/html, Size: 7237 bytes --]

copy_from_user problem

[Maynard Johnson]

Hi,
I'm developing a kernel module that needs to parse the in-memory ELF 
objects for a shared library (libc, to be specific).  When running my 
test on a 32-bit library, it works fine, but for a 64-bit library, the 
very first copy_from_user() fails:
    Elf64_Ehdr ehdr;
    copy_from_user(&ehdr, location_of_lib, sizeof(Elf64_Ehdr);

I talked this over a bit with Will Schmidt.  He determined that 
access_ok (being done as a result of copy_from_user) was failing, but we 
don't know why.  I have 32-bit and 64-bit testcases that start up and 
then pause, waiting for input.  We look at the entry for libc in 
/proc/<pid>/maps, and the permissions are the same for both 32-bit and 
64-bit.

I've run this test on both a stock SLES 10 SP1 kernel and on 2.6.24. 
I'm sure this is a user error, but for the life of me, I don't know what 
I'm doing wrong.

Can anyone out there help?

Thanks.
Maynard Johnson
LTC POWER Toolchain

Re: copy_from_user problem

[Benjamin Herrenschmidt]

On Mon, 2008-02-25 at 19:47 -0600, Maynard Johnson wrote:
> Hi,
> I'm developing a kernel module that needs to parse the in-memory ELF 
> objects for a shared library (libc, to be specific).  When running my 
> test on a 32-bit library, it works fine, but for a 64-bit library, the 
> very first copy_from_user() fails:
>     Elf64_Ehdr ehdr;
>     copy_from_user(&ehdr, location_of_lib, sizeof(Elf64_Ehdr);
> 
> I talked this over a bit with Will Schmidt.  He determined that 
> access_ok (being done as a result of copy_from_user) was failing, but we 
> don't know why.  I have 32-bit and 64-bit testcases that start up and 
> then pause, waiting for input.  We look at the entry for libc in 
> /proc/<pid>/maps, and the permissions are the same for both 32-bit and 
> 64-bit.
> 
> I've run this test on both a stock SLES 10 SP1 kernel and on 2.6.24. 
> I'm sure this is a user error, but for the life of me, I don't know what 
> I'm doing wrong.
> 
> Can anyone out there help?

I would have to look at the code.

Ben.

Re: copy_from_user problem

[Paul Mackerras]

Maynard Johnson writes:

> I'm developing a kernel module that needs to parse the in-memory ELF 
> objects for a shared library (libc, to be specific).  When running my 
> test on a 32-bit library, it works fine, but for a 64-bit library, the 
> very first copy_from_user() fails:
>     Elf64_Ehdr ehdr;
>     copy_from_user(&ehdr, location_of_lib, sizeof(Elf64_Ehdr);

Should be OK provided location_of_lib is a user address.  I assume you
know that copy_from_user returns the number of bytes *not* copied,
hence a 0 return means success.

> I talked this over a bit with Will Schmidt.  He determined that 
> access_ok (being done as a result of copy_from_user) was failing, but we 

I suggest you print out the value of location_of_lib just to
sanity-check it.

Paul.

Re: copy_from_user problem

[Maynard Johnson]

[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]

Benjamin Herrenschmidt wrote:
> On Mon, 2008-02-25 at 19:47 -0600, Maynard Johnson wrote:
>> Hi,
>> I'm developing a kernel module that needs to parse the in-memory ELF 
>> objects for a shared library (libc, to be specific).  When running my 
>> test on a 32-bit library, it works fine, but for a 64-bit library, the 
>> very first copy_from_user() fails:
>>     Elf64_Ehdr ehdr;
>>     copy_from_user(&ehdr, location_of_lib, sizeof(Elf64_Ehdr);
>>
>> I talked this over a bit with Will Schmidt.  He determined that 
>> access_ok (being done as a result of copy_from_user) was failing, but we 
>> don't know why.  I have 32-bit and 64-bit testcases that start up and 
>> then pause, waiting for input.  We look at the entry for libc in 
>> /proc/<pid>/maps, and the permissions are the same for both 32-bit and 
>> 64-bit.
>>
>> I've run this test on both a stock SLES 10 SP1 kernel and on 2.6.24. 
>> I'm sure this is a user error, but for the life of me, I don't know what 
>> I'm doing wrong.
>>
>> Can anyone out there help?
> 
> I would have to look at the code.
Ben,
I've pared down the code to a minimal testcase and attached the source 
file.  Here are the makefile rules to build it:

----------------------------------------------
obj-m := uaccess_test.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
clean:
	rm -f *.mod.c *.ko *.o .*.cmd
	rm -rf .tmp_versions

----------------------------------------------

Instructions:
1. Write a simple C program that will pause, waiting for input, so that 
you can obtain the address of libc to pass into the uaccess_test kernel 
module.  For example:
#include <stdio.h>

int main(void)
{
         printf("Press Enter to continue.\n");
         getchar();

        return 0;
}
--------------
2. Compile C program as 32-bit; then run it.  While the program is 
waiting for input, obtain its PID and do 'cat /proc/<pid>/maps' to get 
the address of where libc is loaded.
3. From the dir where you build the uaccess_test kernel module:
         'insmod ./uaccess_test.ko lib_addr=0x<mem_loc_libc>'
    This should succeed.  dmesg to verify.
4. Unload the module.
5. Recompile your C program with -m64; start it up and obtain the 
address of libc again (now a 64-bit address).
6. Load the uaccess_test kernel module and pass 
'lib_addr=0x<mem_loc_libc>'.  Note that this time, the load fails. 
dmesg to see debug printk's.


Thanks for any light you can shed on this!

-Maynard
> 
> Ben.
> 
> 


[-- Attachment #2: uaccess_test.c --]
[-- Type: text/plain, Size: 1857 bytes --]

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <asm/uaccess.h>

static long lib_addr;
module_param(lib_addr, long, 0);
MODULE_PARM_DESC(lib_addr, "lib_addr");



static unsigned long parse_elf64(unsigned long start_loc)
{
	Elf64_Ehdr * ehdr;
	int ret = 0;

	ehdr = kmalloc(sizeof(Elf64_Ehdr), GFP_KERNEL);
	if (copy_from_user((void *)ehdr, (void *) start_loc, sizeof(Elf64_Ehdr))) {
		printk("cannot get Elf64_Ehdr from "
		       "start_loc %lx\n", start_loc);
			goto out;
	}
	if (ehdr->e_ident[EI_CLASS] != ELFCLASS64) {
		printk("EI_CLASS of Elf64_Hdr is incorrect! %d\n",
		       ehdr->e_ident[EI_CLASS]);
		goto out;
	}
	if (ehdr->e_type != ET_DYN) {
		printk(KERN_INFO "LPA: "
		       "%s, line %d: Unexpected e_type %u parsing ELF\n",
		       __FUNCTION__, __LINE__, ehdr->e_type);
		goto out;
	}
	ret = ehdr->e_ident[EI_CLASS];
	printk(KERN_INFO "Elf class from Ehdr is %d\n", ret);
 out:
	return ret;
}

static unsigned long parse_elf32(unsigned long start_loc)
{
	Elf32_Ehdr ehdr;
	int ret = 0;

	if (copy_from_user(&ehdr, (void *) start_loc, sizeof (ehdr)))
		goto out;
	if (ehdr.e_ident[EI_CLASS] != ELFCLASS32)
		goto out;
	if (ehdr.e_type != ET_DYN) {
		printk(KERN_INFO
		       "%s, line %d: Unexpected e_type %u parsing ELF\n",
		       __FUNCTION__, __LINE__, ehdr.e_type);
		goto out;
	}
	ret = ehdr.e_ident[EI_CLASS];
	printk(KERN_INFO "Elf class from Ehdr is %d\n", ret);
 out:
	return ret;

}

int find_ehdr(unsigned long start_loc)
{
	int ret = 0;
	if (!(ret = parse_elf32(start_loc)))
		ret = parse_elf64(start_loc);
	return ret;
}



int __init init_module(void)
{
	if (!(find_ehdr(lib_addr))) {
		printk(KERN_INFO "uaccess test failed\n");
		return -1;
	}
	    printk(KERN_INFO "uaccess test succeeded\n");
        return 0;
}

void __exit cleanup_module(void)
{
}
MODULE_LICENSE("GPL");

Re: copy_from_user problem

[Nathan Lynch]

Maynard Johnson wrote:
> 
> static long lib_addr;
> module_param(lib_addr, long, 0);
                         ^^^^
Should be unsigned long?

Re: copy_from_user problem

[Nathan Lynch]

Nathan Lynch wrote:
> Maynard Johnson wrote:
> > 
> > static long lib_addr;
> > module_param(lib_addr, long, 0);
>                          ^^^^
> Should be unsigned long?

ulong, rather, but that doesn't fix it.

In any case, lib_addr is a user virtual address; doesn't the kernel
need to do get_user_pages or some such to get at arbitrary process
memory?

Re: copy_from_user problem

[Maynard Johnson]

Nathan Lynch wrote:
> Maynard Johnson wrote:
>> static long lib_addr;
>> module_param(lib_addr, long, 0);
>                          ^^^^
> Should be unsigned long?
Right.  I switched this to 'ulong', but that didn't make a difference in 
my test results.
> 

Re: copy_from_user problem

[Benjamin Herrenschmidt]

On Tue, 2008-02-26 at 08:49 -0600, Maynard Johnson wrote:
> 2. Compile C program as 32-bit; then run it.  While the program is 
> waiting for input, obtain its PID and do 'cat /proc/<pid>/maps' to
> get 
> the address of where libc is loaded.
> 3. From the dir where you build the uaccess_test kernel module:
>          'insmod ./uaccess_test.ko lib_addr=0x<mem_loc_libc>'
>     This should succeed.  dmesg to verify.
> 4. Unload the module.
> 5. Recompile your C program with -m64; start it up and obtain the 
> address of libc again (now a 64-bit address).
> 6. Load the uaccess_test kernel module and pass 
> 'lib_addr=0x<mem_loc_libc>'.  Note that this time, the load fails. 
> dmesg to see debug printk's.

Sounds to me that your kernel module will try to copy_from_user() from
the user context of ... insmod :-)

You need to do your copy_from_user() from within the context of the
program you try to access the memory from !

If you need to access another context than the current one, you then
need to use a different mechanism, such as get_user_pages(), though
beware that you can only do that for memory, not SPE local store or
register mappings.

Ben.

Re: copy_from_user problem

[Maynard Johnson]

Benjamin Herrenschmidt wrote:
> On Tue, 2008-02-26 at 08:49 -0600, Maynard Johnson wrote:
>   
>> 2. Compile C program as 32-bit; then run it.  While the program is 
>> waiting for input, obtain its PID and do 'cat /proc/<pid>/maps' to
>> get 
>> the address of where libc is loaded.
>> 3. From the dir where you build the uaccess_test kernel module:
>>          'insmod ./uaccess_test.ko lib_addr=0x<mem_loc_libc>'
>>     This should succeed.  dmesg to verify.
>> 4. Unload the module.
>> 5. Recompile your C program with -m64; start it up and obtain the 
>> address of libc again (now a 64-bit address).
>> 6. Load the uaccess_test kernel module and pass 
>> 'lib_addr=0x<mem_loc_libc>'.  Note that this time, the load fails. 
>> dmesg to see debug printk's.
>>     
>
> Sounds to me that your kernel module will try to copy_from_user() from
> the user context of ... insmod :-)
>   
Yeah, that's probably the problem (along with my lack of understanding 
how VM works  -- heh).  I guess I was just getting lucky with the 32-bit 
test in that the 32-bit libc was being loaded for my insmod process at 
the same virtual memory address as for my C test program.
> You need to do your copy_from_user() from within the context of the
> program you try to access the memory from !
>   
Can't do that in the "real" code I'm developing, so I guess I'll need to 
use get_user_pages.  Hmmm . . . not quite as simple to use as 
copy_from_user, and I don't see any doc on it.  But at least I've found 
a couple examples in the kernel tree.
> If you need to access another context than the current one, you then
> need to use a different mechanism, such as get_user_pages(), though
> beware that you can only do that for memory, not SPE local store or
> register mappings.
>   
The "real" code I'm developing is targeted at POWER, not Cell.

Thanks, Ben!

-Maynard
> Ben.
>
>
>   

Re: copy_from_user problem

[Arnd Bergmann]

On Wednesday 27 February 2008, Maynard Johnson wrote:
> > Sounds to me that your kernel module will try to copy_from_user() from
> > the user context of ... insmod :-)
> > =A0=20
> Yeah, that's probably the problem (along with my lack of understanding=20
> how VM works =A0-- heh). =A0I guess I was just getting lucky with the 32-=
bit=20
> test in that the 32-bit libc was being loaded for my insmod process at=20
> the same virtual memory address as for my C test program.
> > You need to do your copy_from_user() from within the context of the
> > program you try to access the memory from !
> > =A0=20
> Can't do that in the "real" code I'm developing, so I guess I'll need to=
=20
> use get_user_pages. =A0Hmmm . . . not quite as simple to use as=20
> copy_from_user, and I don't see any doc on it. =A0But at least I've found=
=20
> a couple examples in the kernel tree.

Are you sure that this has to run in kernel space? You may be able to
do the same thing with ptrace() from another user process, which is
normally a lot easier to do, especially if you're not familiar with all
the corner cases in powerpc linux memory management.

> > If you need to access another context than the current one, you then
> > need to use a different mechanism, such as get_user_pages(), though
> > beware that you can only do that for memory, not SPE local store or
> > register mappings.
> > =A0=20
> The "real" code I'm developing is targeted at POWER, not Cell.

Cell systems are compliant to the Power architecture and they run
the same software, so you should at least make sure you have error
handling in place to deal with an access of SPU local store pages
and don't cause random crashes.

	Arnd <><

Re: copy_from_user problem

[Benjamin Herrenschmidt]

On Wed, 2008-02-27 at 06:27 -0600, Maynard Johnson wrote:
> Can't do that in the "real" code I'm developing, so I guess I'll need to 
> use get_user_pages.  Hmmm . . . not quite as simple to use as 
> copy_from_user, and I don't see any doc on it.  But at least I've found 
> a couple examples in the kernel tree.

We can help you if you tell us more about the "real" code.

Ben.