size-differences of long(userspace) / long(kernel)

size-differences of long(userspace) / long(kernel)

[Michael Tautschnig]

Hello!

Is there any generic way in situations, where (pointers 
to) structs are transferred from user- to kernelspace and vice versa? 
Any struct containing a long int or a pointer will have a different 
size in kernel space! This usually happens when doing ioctls ...

I'm not sure, whether it causes any troubles, but, e.g., ifreq contains 
another struct (ifmap) that in turn contains long ints . Thus the size of 
ifreq is 32 byte in userspace and 40 byte in kernelspace. If an 
application reserves sizeof(ifreq) bytes, then lets the kernel initialize 
the struct, which in turn copies it back to userspace - and thus might 
overwrite 8bytes that were not reserved for that struct ... Oops :-)

Any thoughts?

Michael

Re: size-differences of long(userspace) / long(kernel)

[David S. Miller]

See arch/sparc64/kernel/ioctl32.c, we translate all of the
structures on the way in and out of userspace when 64-bit
kernel runs 32-bit applications.

RE: size-differences of long(userspace) / long(kernel)

[Jurzitza, Dieter]

Hi folks,
nevertheless we may run into space issues because structures may grow on their way from userland to kernel-country, thereby kmalloc() calls are subject to earlier failures, as the maximum size of allocable memory for kmalloc() remains the same.

See i. e. linux/include/linux/module.h, what is (harmlessly here ...) used by get_kernel_syms.


Take care



Dieter Jurzitza

-----Original Message-----
From: sparclinux-owner@vger.kernel.org
[mailto:sparclinux-owner@vger.kernel.org]On Behalf Of David S. Miller
Sent: Monday, February 14, 2005 5:13 PM
To: Michael Tautschnig
Cc: sparclinux@vger.kernel.org
Subject: Re: size-differences of long(userspace) / long(kernel)



See arch/sparc64/kernel/ioctl32.c, we translate all of the
structures on the way in and out of userspace when 64-bit
kernel runs 32-bit applications.
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
 
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************

Re: size-differences of long(userspace) / long(kernel)

[Michael Tautschnig]

>
> See arch/sparc64/kernel/ioctl32.c, we translate all of the
> structures on the way in and out of userspace when 64-bit
> kernel runs 32-bit applications.
>
Hmm - I don't really get the point - would you mind explaining a little?

Is it the following lines or did I overlook anything:

#define COMPATIBLE_IOCTL(cmd)   HANDLE_IOCTL((cmd),sys_ioctl)
#define HANDLE_IOCTL(cmd,handler) { (cmd), (ioctl32_handler_t)(handler), 
NULL },
#define IOCTL_TABLE_START \
   struct ioctl_trans ioctl_start[] = {
#define IOCTL_TABLE_END \
   };

and the following table generated using these defines?

Thanks,
Michael

Re: size-differences of long(userspace) / long(kernel)

[David S. Miller]

On Mon, 14 Feb 2005 17:32:07 +0100
"Jurzitza, Dieter" <DJurzitza@harmanbecker.com> wrote:

> nevertheless we may run into space issues because structures may grow on their way from userland to kernel-country, thereby kmalloc() calls are subject to earlier failures, as the maximum size of allocable memory for kmalloc() remains the same.

We don't use kmalloc() always, in fact most often we use alloc_user_space()
(named compat_alloc_user_space()) so that the limits are the same.

Re: size-differences of long(userspace) / long(kernel)

[Ben Collins]

32-bit applications communicating with the kernel using standard calls
like ioctl() pass through a translation layer that converts the 32-bit
information into 64-bit counterparts, processes them, and converts them
back again before passing them back to userspace.

This is pretty common in sparc64, x86-64, ppc64, mips64, ia64, etc.

When binaries on sparc64 are compiled as 64-bit, the translation layer is
not used, and native calls take place within the kernel.

On Mon, Feb 14, 2005 at 04:56:13PM +0100, Michael Tautschnig wrote:
> Hello!
> 
> Is there any generic way in situations, where (pointers 
> to) structs are transferred from user- to kernelspace and vice versa? 
> Any struct containing a long int or a pointer will have a different 
> size in kernel space! This usually happens when doing ioctls ...
> 
> I'm not sure, whether it causes any troubles, but, e.g., ifreq contains 
> another struct (ifmap) that in turn contains long ints . Thus the size of 
> ifreq is 32 byte in userspace and 40 byte in kernelspace. If an 
> application reserves sizeof(ifreq) bytes, then lets the kernel initialize 
> the struct, which in turn copies it back to userspace - and thus might 
> overwrite 8bytes that were not reserved for that struct ... Oops :-)
> 
> Any thoughts?
> 
> Michael
> 
> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

RE: size-differences of long(userspace) / long(kernel)

[Jurzitza, Dieter]

Dear listmembers,
took me some time to come back into track. According to Dave one could replace 

in arch/sparc64/kernel/sys_sparc32.c:
asmlinkage int sys32_get_kernel_syms(struct kernel_sym32 *table)
{
        int len, i;
        struct kernel_sym *tbl;
        mm_segment_t old_fs;   
 
        len = sys_get_kernel_syms(NULL);
        if (!table) return len;
        tbl = kmalloc (len * sizeof (struct kernel_sym), GFP_KERNEL);
		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

by:

        if (!table) return len;
        tbl = compat_alloc_user_space (len * sizeof (strict kernel_sym));


or ist there a caveat because I do not specify GFP_KERNEL to allow sleeping for that?
Many thanks for any inputs,
take care


Dieter Jurzitza

-----Original Message-----
From: sparclinux-owner@vger.kernel.org
[mailto:sparclinux-owner@vger.kernel.org]On Behalf Of David S. Miller
Sent: Monday, February 14, 2005 5:44 PM
To: Jurzitza, Dieter
Cc: sparclinux@vger.kernel.org
Subject: Re: size-differences of long(userspace) / long(kernel)

******
We don't use kmalloc() always, in fact most often we use alloc_user_space()
(named compat_alloc_user_space()) so that the limits are the same.
******


*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
 
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************

size-differences of long(userspace) / long(kernel)

[Jurzitza, Dieter]

Dear listmembers,
one more came to my head,
when doing either kmalloc() or compat_alloc_user_space in arch/sparc64/kernel/sys_sparc32.c, another error stems from the fact that in len * sizeof (struct kernel_syms) the sizeof operator returns 64 Byte (60 char + one long(=4)) whereas in the 64 Bit world it ought to return 72 Byte (60 char + one long(=8) + padding(=4))
How to realize this if not replacing the long by an int in the declaration of struct kernel_syms to avoid the growth in size?
Many thanks
take care



Dieter Jurzitza


-- 
________________________________________________

HARMAN BECKER AUTOMOTIVE SYSTEMS

Dr.-Ing. Dieter Jurzitza
Manager Hardware Systems
   System Development

Industriegebiet Ittersbach
Becker-Göring Str. 16
D-76307 Karlsbad / Germany

Phone: +49 (0)7248 71-1577
Fax:   +49 (0)7248 71-1216
eMail: DJurzitza@harmanbecker.com
Internet: http://www.becker.de
 


*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
 
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************