Re: [ros-svn] [gvg] 19802: Factor out probe and capture code from private ntoskrnl header and put it in

[Alex Ionescu]

gvg(a)svn.reactos.com wrote:

>  Factor out probe and capture code from private ntoskrnl
> header and put it in
> a more public place so other kernelmode components can use it too
>
>
>
> Added files:
> trunk/reactos/include/reactos/probe.h
>
> Updated files:
> trunk/reactos/ntoskrnl/include/internal/ntoskrnl.h
> trunk/reactos/ntoskrnl/include/ntoskrnl.h
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-svn
>
>   
>  
This is incorrect; other kernel-mode components should NOT use these 
macros. They should do it the "long way" and go through ProbeForRead.

Best regards,
Alex Ionescu

[Ge van Geldorp]

>   From: Alex Ionescu
>
>  This is incorrect; other kernel-mode components should NOT 
>  use these macros. They should do it the "long way" and go 
>  through ProbeForRead. 
Why?

[Alex Ionescu]

Ge van Geldorp wrote:

> >  From: Alex
> > Ionescu
> >
> > This is incorrect; other kernel-mode components should NOT 
> > use these macros. They should do it the "long way" and go 
> > through ProbeForRead.
> >     
> >  
> Why?
>
>   
>  
Note that my comment doesn't apply to win32k... it's an internal 
subsystem and as such depends on ntoskrnl and should use those macros, 
but my comments was for drivers. Mostly for two reasons:

1) Drivers shouldn't be getting unsafe parameters from user mode. They 
usually get an entire buffer, which they then ProbeForRead/Write. I've 
never seen a driver have to probe only a handle or large_integer...this 
kind of stuff is simply not done.
2) The macros depend on an undocumented function, RtlRaiseStatus, which 
is not exported in the DDK. Thus this would make every driver use an 
undocumented feature and force them to use the NDK. Addtionally, it uses 
MmUserProbAddress, which is undocumented and its presence in the DDK 
might not be guaranteed (between 2K and XP a lot of similar variables 
disappared in the DDK, since they are not meant to be used).

Note that, again, for win32k, it's perfectly reasonable to use the macros.

Best regards,
Alex Ionescu

[Ge van Geldorp]

>   From: Alex Ionescu
>
>  Note that my comment doesn't apply to win32k... it's an internal 
>  subsystem and as such depends on ntoskrnl and should use 
>  those macros, but my comments was for drivers. 
Ok, understood. Should I add some preprocessor protection like

#if ! defined(_NTOSKRNL_) && ! defined(_WIN32K_)
#error Header intended for use by NTOSKRNL/WIN32K only
#endif

GvG

[Alex Ionescu]

Ge van Geldorp wrote:

>  Ok, understood. Should I add some preprocessor
> protection like
>
> #if ! defined(_NTOSKRNL_) && ! defined(_WIN32K_)
> #error Header intended for use by NTOSKRNL/WIN32K only
> #endif
>
> GvG
>
>   
>  
Hi,

Yeah that would be great to avoid issues!

Best regards,
Alex Ionescu