buffer passing from user to kernel

NTDEV
1

hi all

other problem that i am facing is related with my last query.

what approach shoould be taken for the following:-

—for updating a data structure (literally speaking a complex struct with
pointer items as well as data items) in the kernel
approach 1
–allocate memory for the data structure in the kernel using ExAllocatepool
–when need to update it , pass a copy of this to user via ioctl
–user updates this copy in its own buffer
–user passes this updated buffer to kernel via ioctl which copies it into
its own kernel allocated data structures

is there any approach 2 for the above problem

now the problem with approach 1 is the following:-

suppose a data struct looks like
struct a {
void *abc
int a[10]
struct xyz *a;
} y;

if memory was allocated to this in kernel, then how will i access y.a->u etc

Regards
Mayank

2

Mayank Kumar wrote:

suppose a data struct looks like
struct a {
void *abc
int a[10]
struct xyz *a;
} y;

if memory was allocated to this in kernel, then how will i access y.a->u etc

The answer to this depends on whether you’re going to deploy this driver
in a commercial product or not. If so, I would strongly advise you to
design your interface so that you have a single data blob with internal
*offset* pointers (integers) instead of addresses. The driver should
compulsively verify that every offset truly points within the data
buffer. If you don’t do this, you create an enormous possibility for
mischief.

If this is a one-off driver for private use, an alternative is to build
the data structure in user mode, with user-mode virtual addresses. Pass
the address of this structure in a METHOD_NEITHER operation. You could
adapt this approach to a production driver by using ProbeForRead and
ProbeForWrite to validate all the internal pointers within a
__try/__except block. You would also need to use a __try/__except block
when dereferencing these pointers.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

3

hi walter

thanks for your quick response

You still havent answered my question or probably i havent understood it
correctly.

Firstly what i understood from ur explanation:-
you say that instead of keeping different data items as in the struct keep
something like this:-
struct a{
void *buffer;
int off_abc;
int off_a
}y;

ok point taken. Now what i want to know:-
if this data structure were allocate memory in kernel , then how will i
update it in the user mode, and still have those changes take effect in the
kernel too.
now to add to the complexity , the data structure is some thing like

typedef struct grp {

struct prod_type *prod[10]
struct cons_type *cons[10]
struct svc_type *svces[10]

some more data types …
}Group

each item is a chained hash table which needs to be allocated , its data
items read and updated from the user mode.

for e.g. prod[0] was allocated memory in kernel. now various members of
prod[0] have to be updated in the user mode (they may require updation in
the kernel mode too by the dynamic processing that is occuring using these
data structures)

–if i pass a buffer via an ioctl in which i get the address of the
structure Group allocated in kernel, then will i be able to update various
fields of it.

regards
Mayank

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Walter Oney
Sent: Saturday, May 17, 2003 9:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: buffer passing from user to kernel

Mayank Kumar wrote:

suppose a data struct looks like
struct a {
void *abc
int a[10]
struct xyz *a;
} y;

if memory was allocated to this in kernel, then how will i access y.a->u
etc

The answer to this depends on whether you’re going to deploy this driver
in a commercial product or not. If so, I would strongly advise you to
design your interface so that you have a single data blob with internal
*offset* pointers (integers) instead of addresses. The driver should
compulsively verify that every offset truly points within the data
buffer. If you don’t do this, you create an enormous possibility for
mischief.

If this is a one-off driver for private use, an alternative is to build
the data structure in user mode, with user-mode virtual addresses. Pass
the address of this structure in a METHOD_NEITHER operation. You could
adapt this approach to a production driver by using ProbeForRead and
ProbeForWrite to validate all the internal pointers within a
__try/__except block. You would also need to use a __try/__except block
when dereferencing these pointers.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

You are currently subscribed to ntdev as:
xxxxx@intersolutions.stpn.soft.net
To unsubscribe send a blank email to xxxxx@lists.osr.com